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 gewändert, 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

  • Entlastung des Mediation Servers
    Dadurch kann man Server komplett einsparen oder die Mediation Server Rolle als "Collocation" auf dem Frontend mit betreiben
  • Weniger "Hop" im Audiokanal
    d.h. weniger Latenzzeit und damit verbesserte Qualität und vor allem weniger Ausfälle
  • Weniger umcodierung
    Das Übertragen von Audiodaten der beiden verlustbehafteten Codes RTAUDIO in G711 hat die Qualität sicher nicht verbessert.
  • Optimierte WAN-Nutzung
    z.B. kann ein Client remote auf einem Gateway remote arbeiten und dennoch sich am zentralen Lync Server anmelden.

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 für 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.

  • Lync Clients zum Gateway
    Es ist klar, dass Bypass nur funktionieren kann, wenn der Client direkt mit dem Gateway sprechen kann. Da können Leitwege aber auch Firewalls auf dem Weg oder sogar auf dem Gateway Verbindungen blockieren.
  • Encryption
    Per Default nutzt der Communicator G711 per SRTP, d.h. verschlüsselt. Diese "Forderung" kann man aber abschwächen, so dass auch ein Gateway ohne SRTP mitspielen darf.
  • Gateway Feature
    Das wichtigste Feature ist aber, dass das Gateway mehrere "Early Dialogs" mit "multiple forked responses" unterstützen muss. Was auch immer das im Detail bedeuten mag, habe ich selbst nicht ermittelt.

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.

  • Signalisierung per SIP
  • Audioübertragung per RTP/SRTP

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.

Wann kommt MediaBypass überhaupt zum Einsatz ?

Lync Clients im gleichen Verbundnetzwerk, die sich direkt erreichen können, nutzen ja schon immer "Media Bypass", weil sich die Clients über ICE und Kandidaten direkt erreichen können und mit mit RTAudio ein effektiver Codec zur Verfügung steht.

MediaBypass bezieht sich aber um die Umgebung des Mediation Servers, damit die Endpunkte, also das Gateway und der Lync Client Audio direkt miteinander austauschen. Dazu müssen Sie wissen, dass der Mediation Server weiterhin bei der Signalisierung einbezogen ist und nur RTP dran vorbei gehen kann. Und das passiert auch nicht in allen Fällen:

TnA TnB Bypass Codec Beschreibung

Lync

Lync

Direkt

RTAudio

Wenn zwei Lync Clients miteinander P2P kommunizieren, dann erfolgt dies per RTAudio.

Lync

Konferenz

Direkt

G722, Siren

Ein Lync Client verbindet sich immer direkt mit der AVMCU über G722

TK

Lync

SameSite

G711

Wenn der Lync Endpunkt und das Gateway in der gleichen Site sind (Feld: X-bypassID), dann kann Audio vorbei gehen. Ansonsten geht G.711 zum Mediationserver, der dann RTAudio zum entfernten Client spricht.

TK

Konferenz

Nein

G722

Die AV MCU unterstützt aktuell kein Media Bypass. Telefonteilnehmer laufen immer über den Mediation Server, der aus G711 dann G722 macht.

TK

ResponseGroup

Nein

G711

Ein Anrufer vom Gateway wird per G711 zum RGS-Service geroutet. Es kommt kein Media Bypass zum Tragen.

TK

Edge

Nein

RTAudio

Wann immer ein Edge-Server enthalten ist, kommt Media Bypass nicht zum Einsatz. Ursache ist, dass der Edge Server die Bypass ID filtert. Zudem habe ich noch kein Gateway gesehen, welches STUN/TURN mit dem Lync Edge Server direkt macht. Da ist also auch die Mediation Rolle immer noch mit in der Kette

Wenn aber zwei Lync Teilnehmer per Edge die Signalisierung austauschen aber per ICE eine direkte Verbindung erreichen können, dann nutzen Sie natürlich diesen Kanal.

Die Frage zu Media Bypass stellt sich also nur für Verbindungen, die über den Mediation Server laufen. Damit sind Verbindungen von Lync Clients zu Lync Diensten, egal ob diese nun intern sind oder über einen Edge-Server umgesetzt werden, gar nicht im Fokus.

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.:

  • Anbindung per SIP-Trunks
    Hier kann es passieren, dass der Client mit RTAUDIO über das WAN zum Mediation Server geht, damit dieser die Daten dann per G711 zum SIPTrunk weiter gibt. Wenn der SIP-Trunk-Provider aber Media Bypass unterstützt, dann versucht der Client natürlich direkt die Gegenstelle zu erreichen, was dann wieder IP-Routing und Firewall-Fragen aufwirft.
  • Call Admission Control
    Wenn in mehreren Standorten Gateways verbaut sind, dann kann Lync bei Überlastung des LAN/WAN die Sprachverbindung auch über die Telefonschiene aufbauen.
  • Andere IP-PBX im Haus
    Wenn es weiterhin Anwender gibt, die an einer anderen VoIP-Anlage arbeiten, dann wird hier der Mediation Server in den meisten Fällen auch die Umsetzung vornehmen.

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 für inbound call.
$$END-MEDIATIONSERVER

Wichtig ist am Ende das "Media Bypass selected für 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 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. Beachten Sie, dass "Media Security" per Default nicht eingeschaltet ist.

Beachten Sie bitte, dass Sie auch "Preferable - Single Media" aktivieren und als Master Key Identifier (MKI) den Wert "1" eintragen.

Beim Einsatz als SBC müssen Sie beachten, dass Sie in jede Richtung z.B. über eine IP-Group steuern sollten, ob SRTP genutzt werden.

Media Bypass und Encryption mit Ferrari

Auch auf dem Ferrari Gateway sollte Sie diese Option aktivieren, wenn Sie MediaBypass

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