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 |
|
Audio geht über den Mediation Server |
Nein |
False |
True |
|
Mediation Server sendet einen INVITE und ohne die Route haben einen Loop gebaut. |
Nein |
True |
False |
|
Dank "Media bypass" wird der Mediation Server eben nicht als Relay arbeiten. Eine Verbindung kommt nicht zustande. |
Nein |
True |
True |
|
Mediation Server sendet einen INVITE und ohne die Route haben einen Loop gebaut. |
Ja |
False |
False |
|
Audio geht über den Mediation Server |
Ja |
False |
True |
|
Mediation Server sendet einen INVITE anhand der "Routen" und wir haben einen Loop gebaut |
Ja |
True |
False |
|
Trotz MediaBypass konnte ich sehen, dass Audio über den Mediation Server geroutet wurde. |
Ja |
True |
True |
|
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.
- Microsoft Lync: The Facts
about Fax
http://www.mylynclab.com/2013/04/microsoft-lync-facts-about-fax.html
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
- MediaBypass
- Audiocodes Mediant 1000
- Audiocodes Media Pack 112
- Türsprechstelle
-
CloudPBX und analoge Geräte
Analoge Telefone mit Office 365 CloudPBX und PSTN Calling? - Planning to Deploy Analog Devices
http://technet.microsoft.com/en-us/library/gg398314.aspx - Support für analog devices in Lync 2010
http://blog.jwdberlin.com/?p=19 - MAPI/CDO
- PowerShell Beispiele
-
Analog devices in Lync 2010
http://ucblog.deutinger.de/?p=6 -
Microsoft Lync: The Facts about Fax
http://www.mylynclab.com/2013/04/microsoft-lync-facts-about-fax.html