SIP-Trunk mit Swyx

Die Seite ist noch nicht komplett. Einige Fragen sind noch offen. Die Anbindung ist noch nicht von Microsoft zertifiziert. Zudem gibt es noch die ein oder andere Einstellung zu optimieren.

Bei Net at Work haben wir schon lange eine VoIP-Vermittlungsstelle. Wir nutzen dazu schon viele Jahre eine Swyx PBX mit einer HSTS S2M-ISDN-Karte zum Amt und ein paar internen S0-Anschlüssen. Mit der Version 6.20 unterstützt die Swyx auch SIP-Trunks zu Exchange 2007 und OCS. Auch wenn diese Anbindung noch nicht offizielle von Microsoft zertifiziert ist, so ist es für mich eine elegante Lösung, viele OCS-Anwender direkt anzubinden und nicht erst die Anrufe aus dem ISDN S2m wieder auf die internen ISDN-S0-Anschlüsse und ein Gateway und Mediation-Server zum Client zu bringen.

SIPTunk mit Swyx

Der Amtsanschluss ist weiterhin ein primärmultiplex-Anschluss über eine ISDN-Karte. Intern hingegen sind alle Telefone per IP angebunden und über einen SIP-Trunk wird die Verbindung zum Mediation Server hergestellt.

Die Einrichtung wurde mit Exchange 2007 SP2, OCS2007 R2 und Swyx 6.20.0240 durchgeführt.

Kurzfassung

Die Installation auf der Swyx Verwaltungsoberfläche wird durch Assistenten unterstützt und wird sicher auch von Swyx immer weiter dokumentiert. Ich beschränke mich daher hier auf eine Aufzählung als Kurzfassung und nachfolgend ein paar Screen Captures, die die Konfiguration zeigen

Um OCS über einen SIP-Trunk mit Swyx zu verbinden, sind folgende Schritt erforderlich

Tätigkeit Erledigt

OCS/Exchange 2007 Custom Profile anlegen für TCP

 

Trunkgroup anlegen

 

Trunk mit Rufnummern anlegen

 

Mediation Server einrichten.

 

Optional: OCS RoutingUser anlegen

 

Schauen wir uns die Einstellungen im einzelnen an:

OCS/Exchange 2007 Custom Profile anlegen für TCP

Über eine XML-Datei, welche auf dem Swyx-Server angelegt werden muss, wird überhaupt erst einmal ein Profil für die Anbindung von OCS und Exchange UM bereitet. Ansonsten würde die Swyx nur SIP/UDP sprechen.

Die Datei liegt meist auf c:\Programme\SwyxWare\CustomProviderProfiles.config bzw. muss dort angelegt werden und enthält neben vielen Daten auch die IP-Adresse und Port des OCS Mediation Servers. Hier ein Beispiel: (Bitte die zur Lesbarkeit addierten Zeilenumbrüche wieder entfernen, damit es eine XML-konforme Datei wird

<?xml version="1.0" encoding="utf-8"?>
<sp:ProviderProfiles xmlns:sp="http://www.lanphone.de/ProviderProfiles" allowcustom="false">
  <sp:SIPProviderProfile
       id="OCS"
       name="OCSLink"
       proxy="192.168.100.61:5060"
       DtmfMode="Rfc2833_Event"
       CallingPartyNumberPosition="FromHeaderSIPURI"
       TransportType="TCP"
       Useregistration="False">
  <sp:NumberFormats
       outbound_called="Transparent"
       outbound_calling="CanonicalWithoutPlus"
       inbound_called="PbxUser"
       inbound_calling="Transparent" />
  </sp:SIPProviderProfile>
</sp:ProviderProfiles>

Wichtig: In dieser XML-Datei wird auch der Servername und der Port des ExchangeUM oder OCS-Mediation Server hinterlegt. Auch wenn die GUI später die Pflege anbietet (Version 6.20), so werden die Änderungen nicht übernommen. Nach der Pflege ist ein Neustart des LinkServers und des Swyx Service.

Trunkgruppe anlegen

Der Prozess beginnt mit der Einrichtung der Trunkgruppe als Container für später anzulegende Trunks. Beim Anlegen der Trunk-Gruppe kann dann dieses neue Profil ausgewählt werden.

OCSLink als Profil auswählen

Hier dann die weiteren Details des SIP-Trunk, die bei mir konfiguriert waren. Auf der Karteikarte "Allgemein" habe ich den Auswahlpräfix für diesen Trunk entfernt, da ich nicht mit Weiterleitungen auf eine Spezialnummer wie "#7xxx" arbeite. Solche eine Konfiguration ist z.B. für die Anbindung von Exchange 2007 als Voicemail geeignet, wenn ich meine 613 dann auf #7613 weiterleiten möchte und keine Rufnummern aus meinem Pool hergeben möchte. Bei der Anbindung von OCS hingegen ist dies weniger sinnvoll.

Bei der Rufnummer-Konvertierung können Sie etwas spielen bzw. müssen die Rufnummern auf ihre Normalisierungsregeln in OCS abstellen. Mittels SIP-Trace und NetMon 3 habe ich gesehen, dass die Swyx mit immer nur die "interne kurze" Nummer meldet, also 713@192.168.100.61. Der Mediation Server normalisiert diese Nummer aber dann doch wieder, so dass ich in OCS als TEL-URL doe E164-Nummer verwenden kann

 

Allerdings habe ich als Sonderfall eine Normierungsregel für die CallingID bei ausgehenden Rufen eingetragen. Wenn ich per OCS Telefoniere, würde nach extern normalerweise meine Durchwahl 713 mit übermittelt. Das verhinder ich, indem ich genau diese Rufnummern ersetzen lasse. Das funktioniert natürlich nur elegant, wenn man eine solche 1:1 Beziehung der Rufnummern hat. Man könnte über den Weg natürlich auch eingehende Rufe wieder von 7xx auf 6xx umschreiben, so dass man intern in OCS auch die 6xx Nummern verwenden kann. Allerdings kann ich von OCs dann natürlich nicht explizit das "alte Telefon" anrufen, außer ich würde auch hier wieder eine Schattennummer anlegen und das Ziel umschreiben. Das erinnert doch stark an NAT zwischen Netzwerken.

Auf der Karteikarte "SIP" sollten Sie aber nichts ändern. Auch wenn es den Anschein hat man könne hier etwas ändern, so sind die Änderungen nur temporär, da die Einstellungen aus dem Profil gezogen werden.

Wichtig sind hier die Eintragungen bezüglich der Rufnummern, die zu diesem Tunk gehen. Meine Eintragungen sind recht einfach, weil der ganze 7er Nummernblock dorthin geleitet wird. Die Liste kann aber auch länger werden.

Die beiden weiteren Karteikarten sind nicht mehr spektakulär, da hier nichts eingestellt wird. Beschränkungen für Wählverbindungen sind besser in OCS pro Benutzer zu steuern.

Bei der Einrichtung der Trunkgruppe wird auch ein Weiterleitungseintrag angelegt. In der Swyx Doku steht, dass dieser Eintrag gelöscht werden soll. Das stimmt aber wohl nur, wenn man mit auf der Trunkgruppe mit einem Auswahlpräfix arbeitet.

Trunk mit Rufnummern anlegen

Nach der Trunkgruppe ist auch der Trunk in dieser Gruppe anzulegen. Der Assistent erfragt die Trunkgruppe und andere Einstellungen ab, die dann in den Eigenschaften erscheinen.

Unter Allgemein sind wieder nur der Name, eine Beschreibung, der Server, die Verbindung zur Trunk-Gruppe hinterlegt. Achten Sie darauf, dass der Trunk auch aktiv ist.

Auf den beiden nächsten Karteikarten gibt es nichts einzutragen:

Auch die letzten beiden Karteikarten sind wenig spektakulär:

Auf der letzten Karteikarte habe ich die Unterstützung für FAX entfernt, da OCS damit nicht viel anfangen kann und die Faxfunktion von Exchange 2007 nutzt genutzt wird. Da Swyx auch nach Kanälen lizenziert wird, habe ich die Anzahl der parallelen Verbindungen gedrosselt. Damit ist die Einstellung in Swyx erfolgt und alle Rufe an 7* werden zum SIP-Trunk geroutet.

Mediation Server einrichten

Im Mediation Server müssen Sie natürlich auch eintragen, wie er sich mit der Swyx verbindet. Hier muss der Port des Swyx Link Managers und nicht 5060 oder 5061 eingetragen werden. Die Swyx lauscht zwar auf 5060 und nimmt die Anfragen auch an, aber antwortet mit einem "404 not found". Der Swyx Link Manager lauscht auf Port 65002 per Default, so dass der Mediation Server seine Anfragen dort hin senden muss.

Damit ist die eigentliche Konfiguration im Mediation Server zur Telefonanlage ebenfalls erfolgt. Allerdings gibt es in OCS noch sehr viele andere Stelle, an denen Sie für Enterprise Voice noch konfigurieren müssen.

Swyx "Routing"-Benutzer anlegen

Damit die TK-Anlage aber nun auch weiß, welche Rufnummern "gültig" sind, ist noch ein entsprechender Benutzer anzulegen. Das macht der Assistenten eigentlich ganz einfach. Achten Sie darauf, dass dieser Routingbenutzer nicht im Adressbuch auftaucht und bei der Auswahl der Endgeräte der Eintrag "Call Routing"-Benutzer ausgewählt wird.

Danach sollte der Benutzer noch einmal geöffnet werden und alle Rufnummern des Trunks eingetragen werden:

Danach erscheint der Eintrag in der Liste der Benutzer:

Nun "kennt" die Swyx die entsprechenden Durchwahlen und weiß, wie lange eine Rufnummer sein muss.

Anwender, die weiterhin mit Swyx arbeiten nutzen natürlich das Swyx Telefonbuch. Benutzer, die "nur noch OCS" verwenden, sollten nicht Bestandteil dieses Sammelkontos sein, sondern eigenständige Einträge mit der OCS-Nummer erhalten.

Feintuning

Bei eingehenden Rufen aus dem Festnetz oder Swyx-Teilnehmern zum OCS-Trunk konnten wir immer eine Verzögerung von ca. 4-5 Sekunden bemerken, d.h. der "Call" wurde per ISDN schon gemeldet, aber erst viele Sekunden später per SIP an den Mediation Server gemeldet. Unsere Swyx schreibt ausführliche Trace-Logs mit. In der Datei "SwyxLinkManager-20091027-215901.log" habe ich dann folgende Zeile gefunden:

Inf3 SwSIP  SwSIPCall::ActionOnDial  Restarting FSM dialing timer für 4 seconds in state Idle and wait für further digits.

Also haben wir hier das übliche Problem, wenn die TK-Anlage eine Zeit wartet, bis die Rufnummer anscheinend "komplett" ist. Das konnte ich aber über den Weg lösen, dass man den entsprechenden RoutingUser anlegt, der dann alle Rufnummern (z.B.: 700-799) auf den Trunk routet. Dann weiß die Swyx auch, wann eine Rufnummer komplett ist und signalisiert ohne Verzögerung weiter.

Funktionalität

Es ist erstaunlich, wie einfach die Funktion schon damit gegeben ist. Wenn ich mein bisheriges Telefon auf OCS umleite (also 613 -> 713) dann werden alle Rufe natürlich in OCS signalisiert. Hier gibt es aktuell noch eine Verzögerung von 3-5 Sekunden, weil die TK-Anlage den Ruf einfach nicht früher an den Trunk meldet. Gleiches gilt beim Abrechen einer Verbindung aus der Swyx-Welt zum OCS. Auch hier kommt der SIP-CANCEL erst mit ein paar Sekunden Verzögerung beim Mediation Server an.(Ursache noch unbekannt). Die Verbindung kommt aber sehr wohl zustande. OCs erhält auch die komplette E164-Nummer und löst den Anrufer entsprechend auf.

In der Gegenrichtung kann ich wunderbar ohne Verzögerung Verbindungen zu allen Teilnehmern aufnehmen. Die Sprachqualität ist in Ordnung, wobei das wieder eher vom Audioequipment abhängt. Wer hier spart, spart an der falschen Stelle. Natürlich funktionieren auch die anderen Features wie Parallelruf, Weiterleiten auf die Exchange 2007 Mailbox etc. Ich kann sie gar nicht alle aufzählen.

So sind mir zwei Dinge aufgefallen, die aber bei der Art meiner Konfiguration nicht funktionieren:

  • Status zwischen Swyx und OCS
    Da es keine Kopplung der TK-Anlage mit RemoteCallControl gibt, ändert sich der Status eine Anwender, der mit Swyx telefoniert natürlich nicht in OCS. Umgekehrt kann ich in OCS zwar telefonieren, aber der Status meiner Swyx-Accounts (der weitergeleitet ist), ist ebenfalls grün.
  • Anruf der Mailbox vom Swyx-Telefon
    Wenn ein OCS-Anwender den Exchange UM-Server anruft, erkennt Exchange anhand der SIP-URI, welcher Benutzer dies ist und verbindet ihn direkt mit seiner Mailbox. Da ich in der Exchange/OCS-Welt mit der 7xx-Nummer hantiere und der Ruf vom Swyx-Telefon mit der 6xx kommt, kann Exchange natürlich kein "Autologin" machen. Ich muss also den System Attendant anrufen und mit mit Durchwahl und PIN anmelden, wie ich das von Extern auch gewohnt bin. Das könnte man natürlich tricksen, indem man in der OCS/Exchange-Welt die gleichen Nummern verwendet wie in der Swyx-Umgebung. Dies hat aber andere Effekte zur folge

Leider ist die Anbindung der Swyx mit OCS leider nicht von Microsoft zertifiziert, so dass viele Firmen hier erst mal zögern. Vielleicht wird dies später noch nachgeholt oder vielleicht unterstützt Swyx zukünftig doch einmal CSTA, so dass Firmen beide Systeme sinnvoll parallel nutzen können. Aber ich hoffe damit gezeigt zu haben, dass auch andere kleinere Hersteller durchaus mit OCS sprechen können (und nicht immer nur die Großen wie Siemens, Avaya, Alcatel, Cisco).

Zusammenfassung

Auch wenn die Anbindung per DirectSIP an die Swyx (noch) nicht auf der offiziellen Microsoft Zertifizierungsliste aufgeführt wird, so ist es durchaus eine interessante Option, OCS und Swyx derart zu verbinden. Allerdings sollten Sie dann keine gemischten Teams betreiben, denn eine enge Kopplung der Swyx mit OCS stellt dies nicht dar. Hier ein paar Beispiele

  • Status und Präsenz
    Auch Swyx zeigt in seinem Soft-Client einen Status an. Leider ist aktuell noch keine Verbindung mit dem OCS-Status möglich, d.h. wenn ein Anwender mit Swyx telefoniert, ist sein OCS-Status nicht "am Telefon". Ein OCS-Telefonie-Benutzer ändert nur seinen Status in OCS aber bleibt für die Swyx-Anwender "unsichtbar".
    Ich hoffe, dass hier vielleicht bald eine Möglichkeit geschaffen wird, indem ich z.B. die OCS-Telefonie-Benutzer in Swyx als "Routing Kontakt" anlegen kann und die Swyx vielleicht aus den aktiven Verbindungen einfach den Status dieser Platzhalter aktualisiert.
  • RCC mit Swyx Endgeräten
    Auch fehlt eine Telefonie-Steuerung wie dies mit RemoteCallControl möglich wäre, d.h. wenn ich per Swyx telefoniere und Rufe annehme, dann sehe ich in OCS keine eingehenden Rufe. Ich kann auch nicht über den OCS-Client die Swyx anweisen, eine Verbindung her zustellen. Selbst Drittlösung wie das Estos RCC Gateway helfen hier noch nicht, da die Swyx-TAPI anscheinend nicht mehrere Monitorpunkte unterstützt. (Hier muss ich mich auf Aussagen von Estos verlassen)

Dies beiden Einschränkungen führen wohl dann doch dazu, dass eine Firma aktuell eher nicht parallel mit SWYX telefoniert und mit OCS Präsenz nutzt. Vielleicht gibt es zukünftig hier ja mal eine Lösung hierfür.

Ein Mittelweg ist z.B. über SNOM Telefone möglich. Diese können z.B.: als Endgeräte an einer SWYX-IP-PBX konfiguriert werden und über die zweite Identität auch den OCS-Status ändern, z.B. Telefonie erfolgt allein über Swyx und nebenbei sehen auch die OCS-Anwender, dass der Anwender gerade telefoniert.

Weitere Links