Lync Mediabypass

Media Bypass funktioniert nur innerhalb der gleichen Lync Site, also Subnetze, die "gut" miteinander verbunden sind und sollte nicht über WAN genutzt werden. Hier ist es besser, wenn der Clients RTAudio mit dem Mediation Server spricht und dieser dann umcodiert.

Zwischen dem G.711/G722 Codecs der Telefonwelt und dem Microsoft RTP-Codes gibt es nicht nur qualitative Unterschiede, sondern sie sind auch einfach nicht miteinander kompatible. Das führt dazu, dass die Audio-Daten zwischen zwei Kommunikationspartnern auf dem Weg umgesetzt werden. Das ist etwa so als ob ein Anwender eben nur "ZIP"-Dateien lesen und schreiben kann und der andere Partner vielleicht nur mit RAR-Dateien umgehen kann.

Die Rolle des Umsetzers übernahm bei OCS der "Mediation Server". Diese Funktion gibt es bei Lync auch noch und ist nun mit auf dem Standard/Frontend-Server gewandert, so dass zumindest eine zusätzliche Hardware in vielen Fällen nicht mehr erforderlich ist. Aber auch dann  muss der Datenstrom zwischen Anwender und Telefonwelt durch einige Stationen, was sich natürlich in der Qualität (Laufzeit), der Belastung (CPU und Netzwerk) und der Verfügbarkeit niederschlägt.

Mit Lync 2010 wurde der Weg für die Audiodaten weiter optimiert. Bis zum Office Communication Server 2007 R2 wurden Audiodaten vom Communicator zur Telefonwelt immer über den Mediation Server geleitet, welcher aus dem RTAudio-Codec die Daten in G711 codiert hat. Der Lync 2010 Communicator beherrscht aber auch (endlich) G711 und wenn der Trunk auf dem Mediation Server entsprechend eingestellt ist und das Gateway dies unterstützt, dann kann der Client direkt mit Gateway sprechen. Das hat mehrere Vorteile

Prüfen Sie aber, ob ihr Gateway oder Provider auch "zertifiziert" ist. Auch wenn es nicht zwingend erforderlich erscheint und es vielleicht auch ohne "geht", so sprechen wir hier über "Telefonie" und entsprechenden Verfügbarkeiten und Stabilitäten.

Media bypass will not interoperate with every PSTN gateway, IP-PBX, and SBC. Microsoft has tested a set of PSTN gateways with certified partners and has done some testing with Cisco IP-PBXs. Certification for SBCs is underway. Media bypass is supported only with products and versions listed on Unified Communications Open Interoperability Program – Lync Server at http://go.microsoft.com/fwlink/?LinkId=214406.
Quelle: Configure Media Bypass (http://technet.microsoft.com/en-us/library/gg413028.aspx)

Anforderungen

Damit ist natürlich auch klar, dass das Gateway oder Trunk-Provider bestimmte Voraussetzungen erfüllen muss, z.B.

Eine Aufgabe einer "Zertifizierung" ist die Prüfung der Interoperabilität mit Lync in unterschiedlichen Umgebungen und mit verschiedenen Testfällen. Insofern kann ich nur dazu raten, die zertifizierten Gateways zu verwenden. Wir sprechen bei den Gateways ja nicht von überteuerten Preisen oder Luxusartikeln.

Funktionsprinzip

Eine Sprachverbindung per SIP nutzt immer zwei Kommunikationswege.

Für Media Bypass ist nur der zweite Verkehr von Belang. Ohne Mediabypass ist der MediationServer immer in der Verantwortung die Audiodaten des Clients anzunehmen (Codec:RTAudio) und dann nach G711 umzusetzen und an das Gateway weiter zu geben. Bei Mediabypass, wird der Mediation Server einfach Umgangen. Eine vereinfachte Abbildung soll die Funktion zeigen. Die SIP-Pakete als Ablaufdiagramm sind stark vereinfacht.

Wichtig ist, dass Sie in dem INVITE und dem 200 OK (und den hier weggelassenen Zwischenpaketen) mal einen Blick in den SDP-Anteil werfen. Dort teilen die Endgeräte nämlich mit, auf welcher IP:Port-Kombination sie auf Daten warten. Und hier kann man beim Durchgang durch den Mediation Server sehen, dass er ohne Media Bypass seine eignen Adressen einsetzt und damit sich "einschaltet". Ist hingegen MediaBypass aktiv, dann werden die IP-Adressen der beiden Endpunkte unverändert durchgereicht. In dem Beispiel werden der PC und das Gateway dann direkt miteinander sprechen.

Szenarien

Insofern ist diese Funktion schon wichtig und wünschenswert. Es gibt eine ganze Reihe von Konstellationen die bei Media Bypass von belang sind. ich habe hier erst mal nur die beiden Varianten vorgestellt, die bei einer Anbindung per Gateway an die Telefonwelt zum Tragen kommen:

Szenario Beschreibung
Lync über Gateway zum Amt

Das ist sicher der häufigste Fall: Ein Lync-Anwender im LAN möchte mit einem Teilnehmer im klassischen TK-Netz telefonieren. Der Client meldet sich per SIP weiter am Standard Server an.

Wenn aber eine Audioverbindung kommt, dann wird er nicht an den Mediation Server geschickt, sondern bekommt das Gateway als möglichen SDP-Endpunkt und baut direkt eine Verbindung zum Gateway auf.

Allerdings muss das Gateway dann natürlich auch die Anfragen des Client direkt erhalten können und in der Konfiguration entsprechend den Client auch zulassen.

Dann aber kommuniziert der Client direkt per G711 mit dem Gateway, welches die Audio-Daten weiter gibt.

Das gleiche geht natürlich auch eingehend.
Lync über remote Gateway zum Amt

Interessant wird dies auch, wenn Sie mit Niederlassungen arbeiten, bei denen vor Ort entsprechende Gateways installiert sind.

In der OCS-Welt mussten Sie vor Ort immer einen Server mit der Mediation-Rolle betreiben. Wenn nun das Gateway auch Media-Bypass-fähig ist, dann kann der Anwender nun direkt mit dem Gateway vor Ort sprechen, obwohl er sich natürlich immer noch mit dem Frontend-Server in der Zentrale verbindet. Sie sparen sich also den Server vor Ort.

Um unabhängig von der WAN-Leitung zu sein, können Sie vor Ort sogar einen SBA installieren. Das ist zwar doch wieder ein Windows Server, der aber nur als "Backup" dient, damit auch beim Ausfall des WAN weiterhin telefoniert werden kann.

Zusätzlich gibt es natürlich noch weitere Szenarien, z.B.:

Die folgenden Webseiten haben weitere Szenarien publiziert

Anzeige im Snooper

Ehe Sie nun an die Konfiguration gehen, sollten Sie einfach mal sehen, ob ihr Gateway diese Funktion vielleicht schon aktiviert hat. Hier sehen Sie einen "eingehenden Call", welcher aus dem Telefonnetz über einen Audiocodes Mediant 1000 an den Lync 2010 Mediation Server zugeleitet wurde. Sie können schön sehen, dass "ms-bypass" supportet" ist.

Dies hier ist aber die Anzeige eines INVITE, welches der Mediation Server an den Frontend zur Weiterleitung gesendet hat. Insofern ist diese Information nur bedingt interessant, da sie nur dokumentiert, was wir sowieso zwischen Lync Komponenten als selbstverständlich voraussetzen.

Und wer noch etwas tiefer in das Log schau, wird auch folgendes auf dem Mediation Server finden können:

$$START-MEDIATIONSERVER
MediationCall: 9de391e95604477798ebc3767e66a3dc
CallId: 5cb09870-c6ed-402e-ae02-532fcc46e268
From: sip:+49160xxxxxxxx@netatwork.de;user=phone
To: sip:+495251304613@netatwork.de;user=phone
Direction: Inbound
Start-Line: Receive Answer from Proxy, Final(True), SDP is: v=0
o=- 0 0 IN IP4 192.168.103.17
s=session
c=IN IP4 192.168.103.17
b=CT:99980
t=0 0
m=audio 15006 RTP/AVP 8 0 13 101
a=maxptime:200
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:13 CN/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=x-bypass
$$END-MEDIATIONSERVER


$$START-MEDIATIONSERVER
MediationCall: 9de391e95604477798ebc3767e66a3dc
CallId: 5cb09870-c6ed-402e-ae02-532fcc46e268
From: sip:+49160xxxxxxxx@netatwork.de;user=phone
To: sip:+495251304613@netatwork.de;user=phone
Direction: Inbound
Start-Line: Processing Proxy SDP Answer. bypass (False).
$$END-MEDIATIONSERVER


$$START-MEDIATIONSERVER
MediationCall: 9de391e9560767e66a3dc
CallId: 5cb09870-c6ed-402e-ae02-532fcc46e268
From: sip:+49xxxxxxxxxxx@netatwork.de;user=phone
To: sip:+495251304613@netatwork.de;user=phone
Direction: Inbound
Start-Line: Media Bypass selected for inbound call.
$$END-MEDIATIONSERVER

Wichtig ist am Ende das "Media Bypass selected for inbound call" und dass als nächstes als SDP die IP-Adresse des Clients bzw. Gateways und nicht eine IP-Adresse des Mediation Servers gemeldet wird.

Media Bypass und Encryption mit dem Gateway (Beispiel Audiocodes)

Diese Einstellung ist erforderlich, wenn Sie den Lync Default "RequireEncryption" nicht auf "SupportEncryption" umgestellt haben.

Mal abgesehen davon, dass das Gateway die entsprechenden Codecs (G711) unterstützen muss, gibt es auf dem Gateway in der Regel sonst keine Einstellungen. Es spricht ja auch nicht direkt per SIP mit dem Clients sondern die IP-Adressen der Endpunkte werden im SDP-Datenteil mit übermittelt, so dass Lync-Client und Gateway dann einfach die Audioverbindung miteinander aufnehmen.

Wenn Sie die Verschlüsselung auf Lync nicht von "Required" auf "Supported" gesetzt haben, dann muss das Gateway aber ein Zertifikat bekommen, damit es SRTP anbieten kann. Hier am Beispiel eines Mediant 1000:

Auch auf dem Ferrari Gateway sollte diese Option aktiviert werden:

Sollte das Gateway SRTP nicht unterstützen, dann können Sie für die Lync Umgebung auch den Zwang zur Verschlüsselung auf eine optionale Verschlüsselung setzen

# Abschwächen der Encryption von Required auf Supportet
set-csmediaconfiguration -identity global -encryptionlevel supportencryption

Oft ist diese Einstellung auch für andere Systeme erforderlich, d.h. Polycom Konferenzsysteme. Trotzdem sollten sie erst bewerten, ob der Verzicht auf die Verschlüsselung des Audiokanals und das damit dann einfachere Abhören ein Problem in ihrem Netzwerk ist. Übrigens: Analoge, ISDN und Anlagentelefone arbeiten bislang auch unverschlüsselt. Allerdings ist es vielleicht etwas schwerer, an einen analogen Anschluss zu kommen bzw. das Anzapfen ist einfacher zu erkennen also die Umleitung von TCP-Paketen im gleichen Subnetz per ARP-Spoofing.

Einstellung im Trunk

Auf dem Lync Server gibt es an mehreren Stellen die Möglichkeit, die Verwendung von Media Bypass zu aktivieren oder zu sperren. In einer kleinen Umgebung ist das recht einfach einmal global möglich.

Analog dazu den Powershell Befehl: 

PS C:\> Get-CsTrunkConfiguration | ft identity,Enable*

Identity    EnableBypas EnableMobil EnableRefe EnableSess EnableSign EnablePIDF
                      s eTrunkSuppo   rSupport   ionTimer    alBoost  LOSupport
                                 rt
--------    ----------- ----------- ---------- ---------- ---------- ----------
Global             True       False       True      False      False      False

In verteilten Umgebungen hingegen sollten Sie die die Möglichkeit prüfen, über die Definition von Links, Regionen, Subnetzen und Call Admission Control etc. die Nutzung zu steuern.

Einstellung in der Network Configuration

Zudem wird in der Voice Policy konfiguriert, ob MediaBypass generell erlaubt sein soll, oder zusätzlich noch die Einstellungen der Sites und Regionen berücksichtigt werden sollten.

Auf die Einstellungen in den Sites und Regions gehe ich hier nicht weiter ein, da Sie schon ein weitergehendes Verständnis über die Netzwerkstruktur, die Standorte der Gateways und verschiedenen Bandbreiten und Anbindungen und erfordern.

Kontrolle

Es gibt zwei Möglichkeiten, die Funktion der Einstellungen zu überprüfen. Eine Möglichkeit auf dem Frontend Server die Funktion zu analysieren, ist die Betrachtung der SIP-Pakete mit Snooper. Interessant sind hier Endpunkte, welche im Payload angeboten werden.

Hier erscheinen bei aktiviertem MediaBypass auch die IP-Adressen des Gateways. Alternativ können Sie auf dem Client ein Logging aktivieren und auch hier die SIP-Meldungen auf Endpunkte überprüfen.

Das ist aber kein Garant dafür, dass MediaBypass auch tatsächlich genutzt wird, denn es ist immer noch eine Frage, ob sich die beiden Endpunkte auch erreichen können. Firewalls, IP-Routing etc. können hier bestimmte Paarungen unterbinden.

Ob MediaBypass tatsächlich angewendet wird, können Sie auf dem Client oder auf dem Web zum Gateway mit einem Netzwerkmonitor wie Netmon sehen. Netmon zeigt die Prozesse und deren Verbindungen an. Ein Blick auf den "Communicator" des Clients (192.168.103.25) zeigt natürlich, das dieser per SIP mit den Frontend Server (192.168.100.100) spricht, aber die Audiodaten direkt zu dem Gateway (192.168.100.107) gehen.

Das ist ein sehr eindeutiger Hinweis auf die gewünschte Verbindung.

Zur Information habe ich hier mal einen INVITE dokumentiert, welcher aus einem "Multipart"-Message besteht, in der zuerst die Endpunkte zum Mediation Server und im zweiten Teil dann die alternativen Endpunkte direkt zum Gateway enthält:

INVITE sip:192.168.103.25:1224;transport=tls;ms-opaque=xxx;ms-received-cid=xxx SIP/2.0
From: <sip:anonymous@netatwork.de;user=phone>;epid=xx;tag=xx
To: <sip:+495251304613@netatwork.de;user=phone>;epid=xx
CSeq: 1455 INVITE
Supported: replaces
Supported: -safe-transfer
Supported: ms-bypass
Supported: ms-dialog-route-set-update
SuSupported: timer
User-Agent: RTCC/4.0.0.0 MediationServer
ms-endpoint-location-data: NetworkScope;ms-media-location-type=intranet
ms-trunking-peer: nawm1000.netatwork.de;User-Agent="Audiocodes-Sip-Gateway-Mediant 1000/v.6.20A.027.012"
Session-Expires: 1800
Allow: CANCEL,BYE,INVITE,REFER,NOTIFY,PRACK,UPDATE

--uYTtCGzPtHyMsCxL4jeKiR1lZ6Ceuii7Content-Type: application/sdp
Content-ID: <5a0e08ee-44a3-464a-9f7c-fc21b26ad030>
Content-Disposition: Session;handling=optional;ms-proxy-2007fallback

v=0
o=- 306 0 IN IP4 192.168.100.100
s=session
c=IN IP4 192.168.100.100
b=CT:30000
t=0 0
m=audio 56548 RTP/AVP 0 8 115 13 118 97 101
c=IN IP4 192.168.100.100
a=rtcp:56549
a=a=candidate:xx/yy 1 zz/ww UDP 0.830 192.168.100.100 56548
a=candidate:xx/yy 2 zz/ww UDP 0.830 192.168.100.100 56549
a=candidate:xx/yy 1 zz/ww TCP 0.150 80.66.20.21 52306
a=candidate:xx/yy 2 zz/ww TCP 0.150 80.66.20.21 52306
a=candidate:xx/yy 1 zz/ww UDP 0.450 80.66.20.21 57272
a=candidate:xx/yy 2 zz/ww UDP 0.450 80.66.20.21 58725
a=candidate:xx 1 zz/ww TCP 0.250 192.168.100.100 55125
a=candidate:xx 2 zz/ww TCP 0.250 192.168.100.100 55125
a=bel:main-audio
a=a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:vvvvv|2^31|1:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:vvvvv|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:vvvvv|2^31
a=rtpmap:0 PCMU/8000a=rtpmap:8 PCMA/8000
a=rtpmap:115 x-msrta/8000
a=fmtp:115 bitrate=11800
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=rtpmap:97 RED/8000
a=rtpmap:101 telephone-event/8000
a=a=fmtp:101 0-16,36

--uYTtCGzPtHyMsCxL4jeKiR1lZ6Ceuii7
Content-Type: application/gw-sdp; x-bypassid=xxx
Content-Disposition: Session;handling=optional

v=0o=AudiocodesGW 1446130277 1446129933 IN IP4 192.168.100.107
s=session
c=IN IP4 192.168.100.107
t=0 0
m=audio 7280 RTP/AVP 8 0 18 13 101
c=IN IP4 192.168.100.107
a=rtcp:7281
a=a=x-bypassid:xxxxxxxx
a=ndrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
aa=ptime:20
aa=x-mediasettings:signalboostunsupported

Weitere Links

Keywords:Lync Media Bypass