Direct Routing und Media Bypass

Die erste Version von Direct Routing hat alle RTP-Daten immer über die Cloud geroutet. Mitterlweile können Sie auch Media Bypass aktivieren, so dass die lokalen Kandidaten durchgereicht werden. Diese Seite beschreibt die verschiedenen Optionen der RTP-Ströme mit Audio/Telefonie.

19. Mrz 2019 Media Bypass released
https://techcommunity.microsoft.com/t5/Microsoft-Teams-Blog/What-s-new-in-Microsoft-Teams-the-Enterprise-Connect-feature/ba-p/376255

Achtung:
Die SfB Online zertifizierten IP-Phones, die über das Interop-Gateway sich an Teams anmelden, unterstützen aktuell kein Media Bypass.

Beachte dazu auch die Seite Teams Local Media Optimization

Die Zeit vor Media Bypass

Bislang war es immer so, dass sowohl der Session Border Controller bzw. das Gateway per SIP mit dem Teams Backend gesprochen hat. Der Client hingegen hat schon immer HTTP genutzt und bei der Übermittlung der Kandidaten hat das Teams Backend als Relay agiert.

Die Audio-Pakete sind zweimal über das Internet gelaufen. Neben der Bandbreite ist hier eher die Latenzzeit das Problem.

Media Bypass aktiv

Mit der Freischaltung von Media Bypass auf dem SIP-Trunk ersetzt das Teams-Backend nicht mehr die Kandidaten, die vom lokalen SBC übermittelt werden, sondern reicht diese, ergänzt um die eigenen Kandidaten weiter. Wenn sich nun der SBC und der Client direkt erreichen können, dann bauen Sie auch eine direkte RTP-Verbindung auf.

Die Audio-Pakete (gelb) bleiben hier im LAN. Die Qualität sollte auf jeden Fall besser sein und die Komponente Firewall und Internet sind in dem Fall entfallen.

Die SBC "richtigen Kandidaten"

Damit stellt sich natürlich die Frage nach den "richtigen" Kandidaten. Technisch wird die so realisiert, dass der SBC beim INVITE zur Office 365 seine öffentliche IP-Adressen als SDP-Kandidaten mit übermittelt. Ein SDB könnte theoretisch auch private Adressen mit übermitteln. Da aber der SBC nicht weiß, wo sich der Client befindet und die privaten Adressen daher eher stören könnten, schreibt Microsoft hier vor die öffentlichen Adressen zu nutzen.

Wenn Sie sich z.B. den Header einer SMTP-Mail in Exchange Online anschauen, dann sehen Sie anhand der IP-Adressen, dass auch Microsoft intern mit "privaten Adressen" 10.x.x.x/8" und anderen arbeitet. Da würden all die RTP-Handshakes nur ein Störfeuer sein.

Das bedeutet aber auch, dass selbst die internen Clients auch die öffentlichen IP-Adressen und Ports des SBC erreichen müssen. Wer also den SBC hinter einem NAT-Router verwendet, muss Zugriff von intern durch den NAT-Router nach extern auf die öffentliche Adresse wieder nach innen zurück durchlassen. Das Problem wird gerne als "Hairpinning" beschrieben und ist dem Skype for Business Administrator schon mit Edge-Servern bekannt.

Die Signalisierung geht weiterhin über den Teams Service, der nun den INVITE von ihrem SBC bekommt. Hier müssen Sie über eine Konfiguration einstellen, dass "Media Bypass" erlaubt ist. Nur dann leitet das PSTN-Gateway in Teams auch die Kandidaten des SBC weiter. Er ersetzt ist also nicht sondern erweitert sie um die Kandidaten des Media Relay in der Cloud.

Sie brauchen dazu die Skype for Business Online PowerShell und verbinden sich mit Office 365 um das Gateway anzupassen.

PS C:\> Set-CsOnlinePSTNGateway sipgw.uclabor.de -MediaBypass $true
PS C:\> Get-CsOnlinePSTNGateway

Identity              : sipgw.uclabor.de
Fqdn                  : sipgw.uclabor.de
SipSignallingPort     : 5067
FailoverTimeSeconds   : 10
ForwardCallHistory    : True
ForwardPai            : True
SendSipOptions        : True
MaxConcurrentSessions : 5
Enabled               : True
MediaBypass           : True
GatewaySiteId         :
GatewaySiteLbrEnabled : False
FailoverResponseCodes : 408,503,504

Mehr ist eigentlich nicht erforderlich. Es kann aber einige Zeit dauern, bis diese Änderung aktiv ist.

Sie können im SBC den SIP-Trace nutzen, um die SDP-Kandidaten im Anruf zu prüfen. Solange als SDP-Kandidaten der Gegenseite nur Adressen aus 52.112.0.0/14 erscheinen, setzt Office 365 die Kandidaten des Clients für den SBC noch um. Erst wenn Sie hier z.B. interne Adressen oder andere öffentliche Adressen des Clients sehen, hat die Konfiguration gegriffen.

Ich habe hier mal einen INVITE von einem DirectRouting Benutzer in Auszügen dokumentiert. Der Client steht in einem Fritz!Box Gäste-LAN und baut über Office 365 eine Verbindung zum SBC auf, um dann eine meiner Rufnummern zuhause zu erreichen. (Die Rufnummer ist verkürzt)

INVITE sip:+4952579388xxx@sipgw.uclabor.de:5067;user=phone;transport=tls SIP/2.0
FROM: DirectCallUser1<sip:+495251304xxx@sip.pstnhub.microsoft.com:5061;user=phone>;tag=c2a40aeeba3746bea57ce6cfdcca03a4
TO: <sip:+4952579388xxx@sipgw.uclabor.de:5067;user=phone>
CSEQ: 1 INVITE
CALL-ID: efaf39ab525a5fde8a35d90976cab345
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 52.114.75.24:5061;branch=z9hG4bK7347648
RECORD-ROUTE: <sip:sip-du-a-eu.pstnhub.microsoft.com:5061;transport=tls;lr>
CONTACT: <sip:api-du-b-euwe.pstnhub.microsoft.com:8000;transport=tls;x-i=00464b2f-30b4-4c74-9611-fca596098d34;x-c=/v1/ngc/call/xx/d/8/xx>
CONTENT-LENGTH: 4158
USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2019.2.22.8 i.EUWE.4
CONTENT-TYPE: application/sdp
ALLOW: INVITE
ALLOW: ACK
ALLOW: OPTIONS
ALLOW: CANCEL
ALLOW: BYE
ALLOW: NOTIFY
P-ASSERTED-IDENTITY: <tel:+495251304xxx>,<sip:druser@uclabor.de>
PRIVACY: id

v=0
o=- 0 0 IN IP4 192.168.179.25
s=session
c=IN IP4 192.168.179.25
b=CT:99980
t=0 0
m=audio 51042 RTP/SAVP 104 111 0 8 103 97 13 118 101
a=rtcp:51043
a=ice-ufrag:DCix
a=ice-pwd:W3ORsXVHdds6e1mNRFWj1/4d
a=rtcp-mux
a=candidate:1 1 UDP 2130706431192.168.179.25 51042 typ host
a=candidate:1 2 UDP 2130705918 192.168.179.25 51043 typ host
a=candidate:2 1 UDP 2130705919 192.168.137.1 60414 typ host
a=candidate:2 2 UDP 2130705406 192.168.137.1 60415 typ host
a=candidate:3 1 UDP 184548351 52.114.124.252 53773 typ relay raddr 91.48.117.241 rport 56360
a=candidate:3 2 UDP 184547838 52.114.124.252 53497 typ relay raddr 91.48.117.241 rport 56361
a=candidate:4 1 tcp-pass 174455295 52.114.124.168 57682 typ relay raddr 91.48.117.241 rport 53588
a=candidate:4 2 tcp-pass 174454782 52.114.124.168 57682 typ relay raddr 91.48.117.241 rport 53588
a=candidate:5 1 UDP 1694234623 91.48.117.241 56360 typ srflx raddr 192.168.179.25 rport 56360
a=candidate:5 2 UDP 1694234110 91.48.117.241 56361 typ srflx raddr 192.168.179.25 rport 56361
a=candidate:6 1 tcp-act 174847487 52.114.124.168 57682 typ relay raddr 91.48.117.241 rport 53588
a=candidate:6 2 tcp-act 174846974 52.114.124.168 57682 typ relay raddr 91.48.117.241 rport 53588
a=candidate:9 1 tcp-act 1684795391 91.48.117.241 53588 typ srflx raddr 192.168.179.25 rport 52865
a=candidate:9 2 tcp-act 1684794878 91.48.117.241 53588 typ srflx raddr 192.168.179.25 rport 52865
a=candidate:7 1 tcp-pass 1744537592603:1027:0:8049::3 57682 typ relay raddr 91.48.117.241 rport 53588
a=candidate:7 2 tcp-pass 174453246 2603:1027:0:8049::3 57682 typ relay raddr 91.48.117.241 rport 53588
a=candidate:8 1 tcp-act 174846463 2603:1027:0:8049::3 57682 typ relay raddr 91.48.117.241 rport 53588
a=candidate:8 2 tcp-act 174845950 2603:1027:0:8049::3 57682 typ relay raddr 91.48.117.241 rport 53588
a=mid:m0
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:rBWUwdpAmH4ZAS8d89V+Cc12UXSGS1K40Rfsr/8b|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:ytXmGsTPRnL3wODUTE0SZeBMGOMwNpwczs2MX++T|2^31
a=sendrecv
a=rtpmap:104 SILK/16000
a=rtpmap:111 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:103 SILK/8000
a=rtpmap:97 RED/8000
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
m=video 59034 RTP/SAVP 122 107 99 123
a=ssrc-group:FID 489955479 489955529
a=rtcp:59035
a=ice-ufrag:6WCi
a=ice-pwd:/MPinQnQ95B5Vj8td8LpB8IQ
a=rtcp-mux
a=candidate:1 1 UDP 2130706431 192.168.179.25 59034 typ host
a=candidate:1 2 UDP 2130705918 192.168.179.25 59035 typ host
a=candidate:2 1 UDP 2130705919 192.168.137.1 58044 typ host
a=candidate:2 2 UDP 2130705406 192.168.137.1 58045 typ host
a=candidate:3 1 UDP 184548351 52.114.124.113 54537 typ relay raddr 91.48.117.241 rport 57884
a=candidate:3 2 UDP 184547838 52.114.124.113 54535 typ relay raddr 91.48.117.241 rport 57885
a=candidate:4 1 tcp-pass 174455295 52.114.124.113 51162 typ relay raddr 91.48.117.241 rport 62589
a=candidate:4 2 tcp-pass 174454782 52.114.124.113 51162 typ relay raddr 91.48.117.241 rport 62589
a=candidate:5 1 UDP 1694234623 91.48.117.241 57884 typ srflx raddr 192.168.179.25 rport 57884
a=candidate:5 2 UDP 1694234110 91.48.117.241 57885 typ srflx raddr 192.168.179.25 rport 57885
a=candidate:6 1 tcp-act 174847487 52.114.124.113 51162 typ relay raddr 91.48.117.241 rport 62589
a=candidate:6 2 tcp-act 174846974 52.114.124.113 51162 typ relay raddr 91.48.117.241 rport 62589
a=candidate:7 1 tcp-act 1684796415 91.48.117.241 62589 typ srflx raddr 192.168.179.25 rport 64456
a=candidate:7 2 tcp-act 1684795902 91.48.117.241 62589 typ srflx raddr 192.168.179.25 rport 64456
a=mid:m1
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:rBWUwdpAmH4ZAS8d89V+Cc12UXSGS1K40Rfsr/8b|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:ytXmGsTPRnL3wODUTE0SZeBMGOMwNpwczs2MX++T|2^31
a=inactive
a=rtpmap:122 X-H264UC/90000
a=fmtp:122 packetization-mode=1;mst-mode=NI-TC
a=rtpmap:107 H264/90000
a=fmtp:107 profile-level-id=42C02A;packetization-mode=1;max-fs=1200;max-mbps=67500;max-fps=3000
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=107
a=rtpmap:123 x-ulpfecuc/90000

Sie können hier schön die vier SDP-Kandidaten vom Typ "host" sehen. 192.168.179.25 war die interne IP-Adresse im WLAN und 192.168137.1 ist eine zweite interne Verbindung. Sie sehen aber auch die Angebot der Media Relay Server 52.114.124.113, die dann auf die 91.48.117.241 weiter gegeben werden. Die 91.48.117.241 ist die öffentliche IP-Adresse der Fritz!Box. Soweit ganz normale Funktionsweise von ICE und TURN

Client im Internet

Media Bypass ist darauf ausgerichtet, dass Anwender im LAN mit dem SBC kommunizieren, damit die Vielzahl der Telefonverbindungen nicht zweimal über das Internet und das Microsoft Media Relay übertragen werden müssen. Wenn ein Anwender aber gar nicht im LAN ist, sondern im Internet, (Homeoffice Hotel etc.) unterwegs ist, dann kann er ja den SBC erst einmal nicht erreichen. Zumindest dann nicht, wenn Sie der Konfigurationsempfehlung von Microsoft folgen und den SBC nicht aus dem Internet erreichbar machen. Warum das so ist, beschreibe ich in den nächsten Abschnitten. Wenn das so ist, dann wird der Client wie bisher über das Media Relay in Office 365 gehen

Hinweis:
Anders als bei Skype for Business kann ein Teams Client nicht zwischen "Internet" und "Extern" unterscheiden. Bei Skype erkennt der Clients dies über DNS-Anfragen (_sipinternaltls und lyncdiscover). Dies gibt es bei Teams nicht. Ein Teams Client ist auch Sicht der Office 365 Services immer "Extern".

Der Client spricht wie bekannt per HTTPS mit dem Teams Service und nutzt auch das Teams Media Relay.

Die Aushandlung der SDP-Kandidaten erfolgt klassisch per ICE und da der direkte Weg nicht möglich ist, wird auch Audio über das Media Relays von Office 365 geleitet.

Achtung:
Beim ICE-Handshake werden die Kandidaten zwischen dem Internet-Client und dem SBC nicht ausgefiltert. Wenn ihre Firewall vor dem SBC eine direkte Verbindung des Clients über das Internet erlaubt, dann wird die auch genutzt. Das ist aber unschön, wenn die RTP-Daten z.B. über ein schlechtes Peering zwischen den Providern laufen anstatt über das Microsoft Backend.

Media Bypass im WAN

Betrachten wir uns den Fall, dass ihre Netzwerk mehrere Standorte hat, die mit einem eigenen WAN, z.B. MPLS oder VPN, verbunden sind. Wenn der SBC per Leitweg die Richtung "nach intern" kennt und der Client über sein Default Gateway sogar den SBC aus einer Niederlassung erreichen kann, dann wird der RTP-Datenstrom über ihr WAN laufen.

Das kann gut sein, wenn ihr WAN ausreichend dimensioniert ist und sie mittels QoS auch die RTP-Pakete entsprechend priorisiere. Wenn von alledem aber nichts vorhanden ist, dann ist das Routing von Sprache über ihre eigene WAN-Verbindung nicht ratsam. Das gilt insbesondere wenn Sie Meetings nutzen.

Dann sollten Sie überlegen, ob der entfernte Standort vielleicht einen eigenen Internet-Breakout hat. Wenn Sie dann den Weg zum SBC versperren, dann muss der Client wieder über das Media Relay in Office 365 gehen. Ohne lokalen Internet Breakout ist das natürlich keine Option.

Sie haben dabei zwei Optionen die RTP-Pakete zu blockieren

  • WAN-Link zwischen den Standorten
    Damit verhindern Sie, dass die Teilnehmer nicht nur zum PSTN den direkten Weg gehen sondern auch gleich den internen 1:1 Audiocall. Wenn Ein Anwender im Standort A mit einem anderen Anwender in Standort B direkt kommunizieren will, dann gehen auch beide Teilnehmer über das Microsoft Netzwerk. Das entlastet ihr WAN aber belastet natürlich das Internet. Manchmal ist aber interessant zu sehen, dass die Verbindung über Office 365 als Relay und Internet schneller ist als das eigene WAN. Sie können es leider nicht direkt messen sondern nur indirekt über das Call Quality Dashboard ermitteln
  • SBC-IP-Routing und Firewall
    Der andere Weg ist eine Filterung der RTP-Erreichbarkeit auf dem SBC oder einer Firewall, die dem SBC vorgeschaltet ist und die öffentlichen IP-Adressen umsetzt. Wird hier der Zugriff nur den Standorten erlaubt, die per Media Bypass mit dem SBC kommunizieren dürfen, dann müssen die anderen Standorte eben über das Office 365 Media Relay gehen. Beachten Sie aber, dass RTP bidirektional arbeitet und sie daher in der Regel mehrere Regeln anlegen müssen

SBC aus dem Internet erreichbar

Microsoft rät davon ab und aus technischer Sicht macht es keinen Sinn den SBC über das Internet erreichbar zu machen. Zum einen steht die Sicherheit dagegen, denn jeder erreichbare Port kann ggfls. auch ein Einfallstor sein.

 

Viel störender ist aber die Verschlechterung der Qualität, da der Client und ihre SBC in der Regel sich nicht den gleichen Internet-Provider teilen und daher die Pakete über mehrere Provider und entsprechende Peerings laufen, auf die Sie als Kunde aber auch Microsoft keinen Einfluss haben.

Sorgen Sie bitte dafür dass ihre SBCs über RTP nur von den IP-Adressen der Office 365 Media Relays erreicht werden kann. Microsoft hat dazu den Bereich "52.112.0.0/14" reserviert.

RTP durch VPN

Sie können ja nun auf die Idee kommen dass der SBC, der nicht direkt aus dem Internet erreichbar sein sollte, dennoch für mobile Benutzer über ein VPN erreichbar sein kann. Denkbar ist das ja um das Relay in Office 365 zu umgehen. Davon rät Microsoft aber ganz deutlich ab.

VPN Network: It is strongly not recommended for media traffic (i.e., flow 2'). VPN client SHOULD use split VPN and route media traffic like any external non-VPN user, as specified in https://blogs.technet.microsoft.com/nexthop/2011/11/14/enabling-lync-media-to-bypass-a-vpn-tunnel/ Note: Although the title is Lync, it is applicable to Teams as well. Packet Shapers: Any kind of packet snippers, packet inspection, or packet shaper devices are strongly not recommended and may degrade quality significantly.
Quelle: https://docs.microsoft.com/en-us/microsoftteams/microsoft-teams-online-call-flows

Die Argumentation ist auch richtig, denn überlegen Sie mal, welchen Weg ihr VPN-User auf dem Weg zu ihrem SBC eventuell zurücklegt. Der Client ist mit einem beliebigen Internet-Provider verbunden, der über verschiedene Peerings und das öffentliche Internet die Paket zu ihrem VPN-Zugang routet. Der ganze Weg ist nicht wirklich bezüglich der Performance abgesichert.

Wenn Sie RTP aber nicht durch das VPN senden, dann nutzt der Client im Internet das nächstliegende Media-Relay von Microsoft um von dort über das MGN - Microsoft Global Network den Weg zu ihrem SBC herzustellen.

Der Client ist mit seinem Internet-Provider vermutlich sehr viel besser mit Office 365 verbunden und ihr SBC hat ebenfalls eine gute Verbindung zu Office 365. Hier ist meist nur ein Provider involviert, den Sie auch noch  bezahlen. Das Rückgrat der Kommunikation ist dann aber das Microsoft Netzwerk und hier hat Microsoft ein Interesse an "guter Performance" für seine zahlenden Kunden. Es spricht also schon technisch alles über einen RTP-Umweg über die Cloud.

Sobald mit Teams dann aber noch eine 3er Konferenz einleiten oder das Gespräch aufzeichnen o.ä., dann müssen die Daten eh über Office 365 als MCU laufen. Spätestens dann sollten Sie dafür sorgen, dass RTP nicht noch durch das VPN gequetscht wird.

Daher eine ganz klare Aussage: RTP nie durch eine VPN leiten und den Client selbst den besten Weg finden lassen.

SIP Fehlermeldungen

Je nach Konfiguration gibt es natürlich auch die ein oder anderen SIP-Fehlermeldungen, die beim INVITE von meinem lokalen SBC zur Microsoft SIP-Gegenstelle auftreten können. Hier eine kleine Sammlung:

SIP/2.0 488 Not Acceptable Here
CALL-ID: 18976529122732019222943@sipgw.uclabor.de
REASON: Q.850;cause=65;text="6b5bcbd4-6132-4cde-9a35-24cb07215fff;BackToBackSessionTerminated"
SIP/2.0 415 Unsupported Media Type
CALL-ID: 6360531832732019222953@sipgw.uclabor.de
REASON: Q.850;cause=65;text="5ec00329-3b48-4dbc-ad7f-49dd94ebad91;Peer's B2BBypassSession was terminated"
SIP/2.0 415 Unsupported Media Type
CALL-ID: 1590877899273201922308@sipgw.uclabor.de
<Kein REASON angegeben>
SIP/2.0 488 Not Acceptable Here
CALL-ID: 17974315782732019223010@sipgw.uclabor.de
REASON: Q.850;cause=65;text="d51d3245-056a-4057-9889-4d0e5c708855;There are no ICE candidates in the SDP. Non-ice endpoints cannot use bypass."
SSIP/2.0 488 Not Acceptable Here
CALL-ID: 17055782462732019223012@sipgw.uclabor.de
REASON: Q.850;cause=65;text="105aed12-344b-45d5-9db8-3e3301d2c4c7;IceCandidatesAbsent"

Die meisten Meldungen hier beziehen sich auf falsche INVITEs ohne entsprechende SDPs. Das Gateway "MUSS" ICE-Lite unterstützen.

BRK4016 - Understanding Media Flows in Microsoft Teams
https://myignite.techcommunity.microsoft.com/sessions/65521

BRK4014 - Deep dive on Office 365 Direct Routing
https://myignite.techcommunity.microsoft.com/sessions/65540

Weitere Links

Direct Routing for Microsoft Teams
https://gallery.technet.microsoft.com/lync/Direct-Routing-fro-Review-1-a3f492e8