Lync und analoge Telefone

Erstmals mit Lync 2010 können Sie nun auch einfache Telefone mit einbinden. Darunter zählen nicht die Lync-Telefone wie das Aasta 6721p/6725p oder Polycom Telefon, sondern klassische Telefone, die über einen ATA-Adapter, ein Gateway oder eine SBA angebunden sind.

Da Lync nur Objekte im Active Directory kennt, muss für solche ein analoges Endgerät natürlich ein solches Objekt angelegt werden. Allerdings ist dies kein "User", welcher auch für eine Anmeldung missbraucht werden könnte, sondern einfach ein passender Kontakt, welcher eine SIP-Adresse und Rufnummer hat und Lync den Weg zum Gateway weist.

Die Geräte müssen also an einem Lync-tauglichen Gateway angeschlossen sein, welches auch in Lync definiert ist.

Hinweis:
Es gibt durchaus andere (bessere) Optionen, ein analoges Gerät an Lync anzubinden und dabei z.B. sogar den Status mit zu erhalten. Siehe auch Audiocodes SPS oder Ferrari SIP2Lync.

Anschlussoptionen

Um analoge Endgeräte an Lync zu betreiben gibt es eigentlich nur zwei Möglichkeiten:

  • Anschluss am TK-Gateway
    Verschiedene Gateways und vor allem die SBAs haben auch Anschlüsse für klassische Endgeräte. Das ist ideal für kleinere Umgebungen, bei denen eine SBA die Verbindung zum Amt darstellt und nur wenige Geräte (z.B. Fax und Türsprecheinrichtung) überhaupt noch per Draht angeschlossen werden sollen.
  • Anschluss an einem eigenen Gateway
    Die ist oft der Fall, wenn z.B. ein Fax eben im Büro steht und es außer Ethernet keine Verkabelung gibt oder das Geräte sogar in einem anderen Standort per WAN angebunden ist.
  • Anschluss an einer "fremden TK-Anlage"
    Nicht abgebildet ist die Option, eine ganze TK-Anlage vor oder hinter Lync zu betreiben
  • SIP-Adapter und Geräte ohne Lync
    Es gibt Lösungen, die klassische SIP-Geräte mit Lync verbinden. Teilweise sind die eigene Server (Audiocodes SPS) oder Softwareprodukte (NET DirectSIP) oder Funktionen die vom Gateway bereit gestellt werden. oder eine andere SIP-Software per Trunk anzubinden, die aber auch SIP-Geräte unterstützt, die von Lync von Hause aus ignoriert werden.

Ein einfaches Anschaltbild sieht wie folgt aus:

Je nach Gateway kann es sich dabei um einen analogen "Zweidraht"-Anschluss handelt oder auch um eine ISDN-S0-Leitungen. Es gibt ja auch ISDN-Telefone. Genauso gut können natürlich z.B. DECT-Basisstationen oder Faxgeräte, Alarmgeber und Modems angeschlossen werden.

Allerdings sollten Sie nicht erwarten, dass z.B. mehrere DECT-Stationen von Hause aus ein Handover verstehen und Modems mit maximaler BAUD-Rate sich verbinden. Und einen "Am Telefon"-Status ist erst auch mal nicht vorgesehen.

Analoge Telefondefinition in Lync

Neu ist mit Lync die Integration dieser "analogen Teilnehmer" als "Kontakte". Mit OCS und früher gab es keine Objekte für solche Endgeräte und man konnte mit "Routen" diese Rufnummern zum Gateway lenken.

Achtung:
Jedes Gateway, welche Lync nutzt, muss zunächst in der Lync Topologie auch definiert und "deployed" werden. Gerade der Mediation Dienst braucht oft noch einen Neustart, damit die Änderung sofort aktiv wird.

"Fremde Gateway"
Ich habe auch noch einen HT502 und einen MP102, welche nicht mit Lync harmonieren. Diese kann in Lync zwar definieren, aber werden von Lync nicht genutzt, da Sie den "OPTIONS"-Befehl nicht unterstützen. Solche Gateway kann man aber eventuell direkt an das Gateway (an Lync vorbei) anbinden.

Wenn wir aber "zertifizierte Gateways" haben, dann definieren wird einfach "analoge Telefone" über die PowerShell:

New-CsAnalogDevice `
   -LineUri tel:+495251304680 `
   -DisplayName "Analog 680" `
   -SipAddress "495251304680680@netatwork.de" `
   -DisplayNumber "+495251304680" `
   -RegistrarPool nawlync001.netatwork.de `
   -AnalogFax $false `
   -Gateway mp112.netatwork.de `
   -OU "ou=LyncAccounts,ou=Abteilung,dc=netatwork,dc=de"

Sie sehen hier, dass nicht nur die Rufnummer sondern auch das Gateway hinterlegt ist, an welchem das Endgerät angeschlossen wurde. Technisch legt dieser Befehl einen Kontakt im Active Directory an:

Bedenken Sie, dass Sie zusätzlich nun dem analogen Teilnehmer natürlich wie jedem anderen Lync Benutzer die entsprechenden Policies zuweisen. Der Anrufer wird, da der Call über ein "Vertrauenswürdiges Gateway" kommt, anhand der Rufenden Nummer identifiziert.

  • DialPlan
    Wenn das Gateway noch nicht die Rufnummer als E.164-Nummer erscheint, dann muss Lync die Rufnummer nach E.164 normalisieren. Dies kann nicht an das Kontaktobjekt gebunden werden, sondern erfolgt über einen Dialplan für das PSTN-Gateway. Ist also für alle Endgeräte an dem Gateway identisch.
  • VoicePolicy
    Über die an den Kontakt zugewiesene VoicePolicy wird allerdings kontrolliert, welcher Berechtigungen das Endgerät bezüglich der Ziele hat.

Und nach Abschluss der Replikation ist der "analoge Anwender" wie jeder andere Lync-Teilnehmer im Adressbuch sichtbar und kann angerufen werden.

Allerdings ist der Status bei dieser Art Anbindung immer "offline". Der Client registriert sich ja nicht am Lync Server, sondern das Gateway baut ja nur einen Ruf auf und der Kontakt ist nur ein "Hilfsobjekt", damit Rufe an die Teilnehmer zum passenden Gateway geroutet werden.

Hinweis:
Sie müssen für diese Teilnehmer keine Telefon-"Route" mehr in Lync selbst pflegen. Die Angabe des "Gateway" beim Kontakt ist hinreichend.

Parameter -AnalogFax $true

Vielleicht haben Sie bei der Definition eines "CSAnalogDevice" den Parameter "-AnalogFax $false" gesehen. Über diesen Parameter wird Lync mitgeteilt, dass das analoge Gerät eigentlich ein Faxgerät ist. Dies ist wichtig, da bei analogen Verbindungen die RTP-Daten, d.h. die Audiodaten, über den Mediation Server laufen. Bei einer Fax-Übertragung wird der Codec T.38 verwendet, welcher vom Mediation Server nicht umgesetzt wird. Es muss also sichergestellt sein, dass nicht erst ein Audiokanal über den Lync Mediation Server etabliert wird, der dann beim Erkennen des Faxtones (CNG) aufgrund der Codec-Inkompatibilität scheitert.

Lync nimmt einen externen INVITE an das Faxgerät zwar an, aber leitet ihn immer wieder genau an das Gateway zurück, welches den INVITE gesendet hat. Es passiert also nicht, dass Lync den INVITE an das Gateway leitet, an dem das analoge (Fax-)Gerät angeschlossen ist. Entsprechend muss das eingehende Gateway nun einen passenden Regelsatz haben, um die Wiederkommenden INVITE direkt zum anderen Gateway zu leiten.

Wichtig:
Wenn das Gateway dies nicht berücksichtigt, und den INVITE direkt wieder zu Lync leitet, dann haben Sie eine SIP-Loop gebaut.

Schon aus praktischen Überlegungen können Sie aber die komplette SIP und Audio-Kommunikation eines Faxgerätes direkt an Lync vorbei konfigurieren. Allerdings erscheinen diese "Anrufe" dann nicht in der CDR-Datenbank, d.h. sind auch nicht im Einzelverbindungsnachweis nachvollziehbar.

Verbindung zwischen Lync Client und Lync Analog Phone

In den folgenden Beispielen wird davon ausgegangen, das "Media Bypass" nicht aktiv ist.

Ruf ein Lync Client nun so ein "Analog Device" dann wird der Ruf wie gehabt über die Lync Struktur bis zum passenden Mediation Server gegeben, der einen INVITE zum hinterlegten Gateway sendet. Das Gateway lässt es dann am Telefon klingeln und baut die RTP-Verbindung auf.

Eingehend kann das analoge Telefon auch einfach den Ruf an Lync senden, zumindest solange das Ziel auch "in Lync" ist.

 Eventuell sind hier ein paar Besonderheiten bei der Ermittlung der Rufnummer zu beachten. DTMF als Signalisierung und entsprechende Timeouts und Pausen sind hier auf dem Gateway anzupassen.

Routing der Audiodaten mit PSTN

Analoge Teilnehmer sollen natürlich auch von externen Partnern erreicht werden. Hier hängt es nun etwas vom Gateway ab, wie der Fluss aussieht. Ein pfiffiges Gateway erkennt alleine an seiner Konfiguration, dass an einem der analogen Ports schon das gerufene Ziel konfiguriert ist und leitet den Ruf gleich zum Gateway ohne erst bei Lync nachzufragen.

Wenn das Gateway aber jeden eingehenden Call direkt zu Lync sendet, dann können Sie beobachten, dass Lync den Ruf einfach wieder an das Gateway zurück gibt. Vielleicht kann es ja dann anhand anderer Regeln den Ruf zum analogen Anschluss vermitteln. Idealerweise bleibt der Audio-Strom aber auf dem Gateway. Ich habe bislang nicht gesehen, dass der Mediation Server hier zwei Verbindungen aufbaut und als Relay agiert. (ähnlich einer eines Session Border Controllers)

Umgekehrt funktioniert es natürlich idealerweise auch so, dass das Gateway den Ruf anhand der Nummer als "nicht lokal" ansieht und am besten direkt in das Telefonnetz routet.

Dann hat auch Lync mit dieser Audioverbindung nichts mehr zu tun. Allerdings kann das auch dazu führen, dass der Monitoring Server diese Verbindungen auch nicht mehr sieht.

Relay über Lync mit zwei Gateways

Richtig interessant wird es nun, wenn das analoge Gerät nicht am gleichen Gateway anschlossen ist, wie der eingehende Ruf, d.h. die Verbindung eigentlich durch die Lync-Welt laufen würde. Die SIP-Verbindung kann der Lync ja noch problemlos abwickeln, aber das Routing der RTP-Pakete ist interessant. Hier gibt es ja zwei Optionen

  • Via Mediation Server
    d.h. die Audiodaten gehen von einem Gateway erst zum Mediation Server und der leitet die Daten dann zum anderen Gateway weiter. Der Mediation Server hat also "zwei Verbindungen" und agiert als RTP-Relay.
  • Direkt von Gateway zu Gateway
    Denkbar ist auch, dass über eine entsprechende Konfiguration die Gateways direkt miteinander sprechen und damit Lync komplett umgehen. Theoretisch könnte auch der Lync Mediation Server dies vermitteln, indem er die Endpunkte einfach entsprechend umsetzt. Allerdings weiß Lync ja nicht ob die Gateways sich wirklich erreichen können. Wenn an einer Stelle ein "SIP-Trunk" dabei ist, dann kann das schon schwer sein.

Interessant ist, dass das reale Routing u.a. von der Definition des analogen Telefons in Lync abhängig ist. Nehmen wir zuerst an, dass es sich um ein Telefon handelt:

Set-CsAnalogDevice "anschlussname" -AnalogFax $false

Wenn das "Analog Device" nicht als Fax definiert ist, dann geht nicht nur die Signalisierung über Lync. Auch die RTP-Pakete werden über den beim Mediation Server geleitet, der dann in beide Richtungen eine Verbindung aufbaut:

Damit funktioniert ein "Telefonanruf schon mal problemlos mit den meisten Gateways.

Das hat auch Johann Deutinger (Ferrari Electronic) auf seinem Blog beschrieben:

Lets take a look at a distributed Lync deployment with gateways installed in two sites A and B where both gateways support analog devices. Phone calls from an analog port at site A directed to another analog device at site B would normally take use of WAN infrastructure and VoIP protocols. If site A and B are not connected through a “low-latency network” and are not using media bypass, the RTP stream will be converted to RTAudio by the local Mediation Server and typically converted back to G.711 at the destination. While an adaptive codec like RTAudio is great für voice calls, it fails on modem communications.
Quelle: Analog devices in Lync 2010 http://ucblog.deutinger.de/?p=6

Wird aber das "CSAnalogPhone" als "Analog Fax" deklariert, dann greift eine andere Logik. Mit FAX (und speziell dem Codes T.38, welcher schon das Fax digitalisiert überträgt) kann Lync nichts anfangen und möchte diese RTP-Ströme auch nicht verarbeiten.

Set-CsAnalogDevice "anschlussname" -AnalogFax $true

Die Logik ist auch im Lync Planungsdokument angedeutet:

When Lync Server detects that a direct inward dial (DID) number is associated with a fax machine, the Mediation Server does not terminate media. Rather, Lync Server routes the call to the destination fax machine, bypassing the Mediation Server. You can use centralized call detail recording and policy management functionality für these types of calls because the signaling für fax machine calls flows through a Front End pool or a Standard Edition server

Quelle: Planning to Deploy Analog Devices
http://technet.microsoft.com/en-us/library/gg398314.aspx

Sollte in diesem Fall der "INVITE" vom Gateway tatsächlich bei Lync aufkommen, dann sendet Lync den INVITE direkt wieder zum Gateway zurück.

Das Gateway bekommt den INVITE und muss anhand seiner eigenen Routingtabelle, die vom Administrator natürlich zu pflegen ist, den Ruf weiter vermitteln. Wenn hier dann ein Weg zu dem zweiten Gateway mit dem Faxgerät gepflegt ist, dann sprechen letztlich die Gateways direkt miteinander.

Die Idee dabei ist, dass gerade die "kritischen" FAX-Daten (T.38) nicht durch den Mediation Server umcodiert werden, da T.38 ja schon digitalisierte Bits darstellen und Lync damit nicht wirklich etwas anfangen kann.

Interessanterweise gibt Lync den INVITE an den Mediation Server immer an genau das Gateway wieder zurück, von dem der INVITE gekommen ist. Es passiert also nicht, dass Lync das im Bild rechte Gateway mit einem INVITE einlädt und ihm als RTP-Endpunkte das andere Gateway anbietet.

Media Bypass

Alle oben gemachten Aussagen zum RTP-Datenstrom sind natürlich nur gültig, solange Media Bypass nicht aktiviert ist. Lync 2010 kann in Verbindung mit dem passenden Gateways auch den Mediation Server entlasten, indem die Clients direkt mit dem kompatiblen Gateway kommunizieren..

Siehe dazu auch MediaBypass

Ich habe mal ein paar Tests mit einem Gateway (M1000) zum Amt und einem Fax/Telefon an einem Audiocodes Media Pack 112 gemacht.

Achtung:
Das dürfte nur gelten, wenn das Gateway zum Telefonnetz und das Gateway zu den AB-Anschlüssen unterschiedliche Systeme sind. Wenn eine SBA die Verbindung zum Amt und Analogteilnehme übernimmt, dann wird das Zurückrouten an das Gateway natürlich funktionieren.

Die Tests gelten nur für die damals verwendete Konfiguration, den Firmwarestand und die Lync Version und müssen nicht zwingend mit anderen Versionen nachvollziehbar sein.

Die Tabelle gilt für eingehende Rufe auf das CSAnalogDevice. Hinter dem Begriff "Route = Ja" steht die Einstellung im M1000, Rufe für diese Nummer per SIP zum MP112 zu lenken.

Route MediaBypass AnalogFax Status Audiodaten

Nein

False

False

Ring

Audio geht über den Mediation Server

Nein

False

True

Busy

Mediation Server sendet einen INVITE und ohne die Route haben einen Loop gebaut.

Nein

True

False

Busy

Dank "Media bypass" wird der Mediation Server eben nicht als Relay arbeiten. Eine Verbindung kommt nicht zustande.

Nein

True

True

Busy

Mediation Server sendet einen INVITE und ohne die Route haben einen Loop gebaut.

Ja

False

False

Ring

Audio geht über den Mediation Server

Ja

False

True

Busy

Mediation Server sendet einen INVITE anhand der "Routen" und wir haben einen Loop gebaut

Ja

True

False

Ring

Trotz MediaBypass konnte ich sehen, dass Audio über den Mediation Server geroutet wurde.

Ja

True

True

Busy

Mediation Server sendet einen INVITE anhand der "Routen" und wir haben einen Loop gebaut

Wenn das Analoggerät "raus ruft", dann hängt es am Gateway, welches natürlich auch "Faxtöne (CNG)" erkennen kann und dann den Codes auf T.38 umstellt und einen Re-INVITE zum Lync sendet.

Routen in Lync ?

Aus reiner Neugier habe ich mal versucht, in Lync selbst die beiden analogen Nebenstellen als "Route" im "Voice Routing" einzutragen und auch ohne die Definition als "Analog Device" gearbeitet"

Ein Lync Teilnehmer konnte dann natürlich diese Teilnehmer anrufen aber Lync hat sich standhaft geweigert, Rufe aus dem Festnetz als Relay weiter zu geben. Es erfolgt dann auch kein INVITE zurück zum Gateway. Über Routen in Lync kann daher die Funktion nicht verbessert werden.

Kompatible Gateways und Adapter

Nun glauben Sie zwar zu wissen, was Sie in Lync mit den "Analog Devices" alles anfangen können, aber ein Gateway zur Umsetzung von TCP/IP und SIP auf dem Ethernet zu einem 2-Draht Telefon müssen Sie erst einmal kaufen. Wie auf dem Bild oben zu sehen gibt es eigentlich nur zwei Optionen:

  • Gateway mit Analoganschluss
    Gateways wie das Audiocodes Media Pack 112 sind mögliche Kandidaten, um analoge Geräte im "Feld" mit Lync zu betreiben
  • SBA mit Analoganschluss
    Wer eine "Survivable Branch Appliance" einsetzt, wird auch dort analoge Anschlüsse finden. Angeblich schreibt Microsoft solche Anschlüsse sogar vor.

Die Einrichtung ist dann jedoch überschaubar und einfach.

Achtung
Es gibt ATA-Gateways auch für kleines Geld, teilweise <50 Euro. Prüfen Sie genau, welche Codecs diese Systeme unterstützen. Wird z.B. eine Modem-Übertragung gewünscht (z.B. Portomaschine), dann muss das Gateway auch V.34 unterstützen. Es geht dabei um den parallelen Empfang und Versand (Vollduplex) von Daten mit sehr geringen Latenzzeiten. Dies ist eine ganz andere Anforderung als z.B. FAX, welches eher eine unidirektionale Verbindung (Halbduplex) ist mit ganz wenig relativ unkritischem Rückkanal.

Analog-Phone an einem "nicht" kompatiblen Gateway

Nun ist es ja so, dass es zwar eine Menge von kompatiblen Gateways gibt aber VoIP-Gateways eine längere Lebensdauer als klassische PCs haben. So haben wir bei Net at Work sowohl ein Audiocodes MP102, welche 2006 das letzte Mal verkauft wurde und mit einer H.323-Firmware an einer Swyx wunderbar einen Faxserver bedient hat. Zum Glück gab es für das Gateway noch eine SIP-Firmware, wenngleich die Version 4.6 schon "sehr alt" ist und diese weder für Lync zertifiziert ist noch den SIP Options-Befehl unterstützt. Zudem habe ich noch ein "billiges" Grandstream HT502, welches auch ein einfaches SIP-Gateway ist.

"Offiziell" lassen sich solche Gateways natürlich nicht mit Lync betreiben. Aber diverse Gateways können mit mehreren IP-Gegenstellen kommunizieren und nirgendwo steht geschrieben, dass ein Lync Gateway jeden Ruf aus dem Festnetz exklusiv zum Lync Mediation Server routen muss. Auch umgekehrt kann so ein Gateway fast immer auch SIP-Verbindungen von anderen Endpunkten annehmen und ins Festnetz routen. Und so kann auch ein solches Gateway in den meisten Fällen mit einem Lync-Gateway verbunden werden.

Das nicht kompatible Gateway tritt gegenüber Lync gar nicht in Erscheinung, sondern versteckt sich "hinter" dem zertifizierten Gateway.

Die Verbindung von einem Lync Client per IP zum Gateway und dann weiter per IP zum "nicht kompatiblen Gateway" ist oft eine Lizenzfrage des ersten Gateways. Eine IP zu IP-Funktion kostet je nach Hersteller Geld. Denn der RTP-Strom vom Lync Client muss quasi über den Mediation Server zum Lync-zertifizierten Gateway, welches dann die Daten als Relay an das andere Gateway routet.

Da mein Mediant 1000 bei Net at Work solch eine SIP2SIP-Lizenz nicht hat, habe ich mir damit beholfen, zwei freie ISDN-Anschlüsse per Loopback-Kabel zu verbinden und damit einen Anruf von Lync erst über einen S0-Anschluss als "IP zu TEL"-Umsetzung zu routen

Der Ruf kommt dann auf dem zweiten S0-Anschluss wieder herein und wird dann quasi wie ein externer Ruf angenommen und dann wieder als "TEL2IP" zu dem nicht zertifizierten Gateway zu routen. Aber das ist wohl eher eine "kleine" Not-Lösung. Siehe auch AC M1000 unter "Loopback für VoIP2VoIP".

Weitere Links