Teams Local Media Optimization

Mit der Funktion "Local Media Optimization" erlaubt Microsoft eine weitere Optimierung der Signalisierung und Media-Ströme. Das Feature wurde früher auch als "Double Media Bypass" bezeichnet und ist seit 7. April 2020 dokumentiert.

Standardeinstellung

Ohne Konfiguration sendet ein Client seine Audio-Daten bei einem PSTN-Call immer an die Transport Relay-Server in der Cloud die diese dann zum konfigurierten SBC übertragen, der dann die Verbindung zum Telefonnetz herstellt.

Es ist sofort ersichtlich, dass der interne Client doch viel besser direkt mit dem SBC sprechen sollte. Dazu müsste aber der SBC schon wissen, dass der Client in der Nähe ist, denn alleine eine private IP-Adresse ist ja noch kein ausreichender Indikator

SBC und User im LAN

Wenn ein Client und der dazugehörige SBC für dessen Rufnummer in der gleichen Site sind, dann wäre folgende RTP-Kommunikation viel besser:

Sie entlastet die Internet-Verbindung, da die Audiodaten nicht den Umweg über das Teams Backend gehen müssen und die geringere Latenzzeit verbessert auch die Qualität. Damit diese Funktion genutzt wird, muss der Teams Administrator aber einige Einstellungen vornehmen und Voraussetzungen erfüllen:

Voraussetzung Check

Statische öffentliche IP-Adresse

Die internen Clients müssen auf ihren Weg zu Teams bei der Anmeldung per HTTPS mit einer festen öffentlichen IP-Adresse ankommen, die in Teams als "TrustedSubnetz" hinterlegt wird. Alleine eine private IP-Adresse ist ja kein sicherer Indikator für den Standort. Auch zuhause, im Hotel oder unterwegs kann ein Client ja eine private Adresse bekommen, die mit dem Firmen-LAN übereinstimmt.

Diese Herausforderung ist bei CloudProxy-Servern (Zscaler etc.) zu beachten, dass dann Teams nicht generell über den Proxy geht, da dann alle Clients intern sind und HomeOffice-User kein LMO nutzen dürfen.

Definition von Sites und Regions

Dann muss der Administrator die interne Topologie mit privaten IP-Adressen, Network Sites und Network Regions pflegen und in Teams hinterlegen. Diese "Siteliste" ist nicht mit Location based Routing oder Emergency Routing zu verwechseln.

SBC-Zuordnung

Weiterhin muss für jede SBC in Teams eine Site zugewiesen und die Bypass-Option konfiguriert werden

SBC-Konfiguration

Auch auf dem SBC auch noch eine Konfiguration erforderlich, damit dieser weiß, welche IP-Adresse für Media von Intern anzubieten ist. Auch könnte eine Firmenfirewall noch die direkte Verbindung blocken. Per SIP bekommt der SBC die Information, dass der Client "intern" ist und nur dann sollte der SBC die private IP-Adresse als STUN-Server anbieten.

Firewalls

SBCs stehen oft in eigenen "TK-Subnetzen". Sie müssen natürlich vom Client erreichbar sein

Kompatibler Client

Natürlich müssen Sie einen Teams Client nutzen, der auch Local Media Optimization unterstützt. Teams in einem Webbrowser gehört nicht dazu, da hier Teams auf WebRTC aufsetzen muss und keinen direkte Zugriff auf den IP-Stack hat

Und selbst dann kann es noch die ein oder anderen "Issues" geben.

User im Firmen WAN mit Internet

Es könnte ja sein, das ihr Anwender auf Dienstreise in einem anderen Standort ist. Wenn der andere Standort einen eigenen Internet Breakout hat, können Sie als Administrator nun entscheiden, ob die Audio-Daten über ihr Firmen-WAN oder doch über das Internet routen sollen.

Normalweise nimmt auch hier Audio den "RTP Default"-Weg. Wenn Se aber den SBC in Site1 auf '-BypassMode "Always"' setzen, dann würde der Weg über das eigene WAN angeboten werden.

User im Firmen WAN ohne Internet

Weiterhin ist der Fall möglich, dass ein Client in einem Standort ist, der selbst kein Internet hat, sondern über einen anderen Standort geht.

Hier kommt es nun erst einmal darauf an, über welche öffentliche IP-Adresse der Client bei Teams aufschlägt. Wenn er über die Site2 geht, dann ist er aus Sicht von Teams in einer anderen Site und wie bei vorherigen Beispiel ist die Konfiguration des "BypassMode" am SBC ausschlaggebend. Wenn der Client aber zufällig über die gleiche Site auf Teams zugreift, in der auch der SBC steht, dann kann er auch mit der Option "-BypassMode OnlyForLocalUsers" eine direkte Verbindung aufbauen.

User im Homeoffice

Nun kommen wir noch zu den Anwendern im Homeoffice. Wenn Sie kein VPN aufbauen, dann verbinden Sie sich mit dem Teams Backend über die öffentliche IP-Adresse ihres Providers. Diese Adressen sind dynamische und sicher nicht im Tenant hinterlegt. Das ist auch besser so, denn die private IP-Adresse des SBC als Gegenstelle könnte vom Client sowieso nicht erreicht werden. Als "Externer Client" sendet Teams seine RTP-Daten zum Teams Backend, welches die Daten dann zum SBC übermittelt.

Dies ist auch besser, Firma und Anwender bei unterschiedlichen Providern sind. Das Peering der Provider zu Microsoft ist meist besser als das direkte Peering zwischen zwei Providern. Dennoch ist es auch hier möglich, eine direkte Verbindung zwischen Client und SBC herzustellen. Dazu muss die öffentlichen IP-Adresse des SBC aber nicht nur von Microsoft sondern aus dem gesamten Internet erreichbar sein.

Dies Funktion heist dann aber aber "Media Bypass" und nicht "Local Media Optimization"

SBC ohne Internet

Es kann noch einen weiteren Fall geben, bei dem eine Optimierung des RTP-Datenstroms interessant ist. Es kann z.B. Sites geben, die keinen Internet-Ausgang haben aber sehr wohl eine Kopplung an das Telefonnetz oder einer lokalen TK-Anlage mit Teams über einen SBC betreiben.

In dem Fall sollte der Client einen Telefonanruf über den lokalen SBC zum Telefonnetz ausführen. Da die Site2 kein Internet hat, kann der Client nur über Site1 im Internet surfen. Der SBC vor Ort hat aber mangels Internet auch keinen direkten SIP-Trunk zu Teams. In dem Fall kann der SBC in Site1 als "ProxySBC konfiguriert werden. Die wenig Bandbreiten der Signalisierung kann wie gewohnt über die Site1 gehen aber die RTP-Verbindung bleibt lokal.

Zscaler, VPN und Public-IP

Beachten Sie bei all den Überlegungen, dass für den Client die öffentliche IP-Adresse der Schlüssel dazu ist, dass diese Optimierung überhaupt funktionieren kann. Da die Verbindung hier aber nicht per UDP sondern HTTPS zum Teams Backend erfolgt, können verschiedene Störfaktoren die Ergebnisse verschlechtern, z.B.

  • Cloud Proxy
    Es gibt Angebote aus er Cloud, über die Firmen ihren Surf-Traffic von einem Dienstleister filtern lassen. In dem Fall würde dann aber die IP-Adresse dieses Dienstleisters als Public-IP bei Microsoft erscheinen. Sie können dies heilen, indem Sie entweder die IP-Adressen des CloudProxy-Service in ihrem Tenant als "Trusted IP" hinterlegen oder Sie richten eine Ausnahme ein, dass der Verkehr zu den Teams-Adressen nicht durch den Cloud Proxy gehen. So einen Bypass sollten Sie auch auf jeden Fall für UDP einrichten.
  • VPN
    Hier kommen die Home-User ins Spiel, die sich mit dem Firmennetzwerk verbinden. Je nach Konfiguration (Split oder Tunnel) geht der HTTPS-Verkehr von Team am VPN vorbei oder über die Firma. Im ersten Fall erkennt Teams, den Anwender als "extern" und nutze keine Local Optimierung aber eventuell Media Bypass. Wenn durch den Tunnel die Trusted-IP der Firma genutzt wird, dann könnte der Client irrtümlich einen Bypass erkennen. Das passiert besonders leicht mit Windows-VPN, wenn der Client eine IP-Adresse aus dem Hauslan (Bridging) statt aus einem eigenen VPN-Subnetz bekommt. Wenn dann RTP auch durch den Tunnel geroutet wird, funktioniert die Verbindung aber die Qualität könnt durch den VPN Overhead und das ungünstige Provider-Routing schlechter sein.
    Wenn der Client aber dennoch per Split-VPN vorbei möchte, dann erreicht er sicher nicht die private IP-Adresse des SBC in der Firma und der Call kommt nicht zustande.

Hier ist eine saubere Konfiguration erforderlich, damit die RTP-Verbindung überhaupt zustande kommt oder einen sinnvollen kurzen Weg geht.

1:1 und Meeting

Die bisherige Beschreibung hat sich ausschließlich auf Telefonie-Anrufe über einen SBC beschränkt. Wenn zwei Personen per Teams miteinander direkt sprechen oder in einem Teams-Meeting mit 3 oder mehr Personen zusammen arbeiten, dann kommen wieder andere Kommunikationswege zum Einsatz. Diese haben aber mit Local Media Optimization nichts zu tun.

Konfiguration

Die Konfiguration von "Local Media Optimization for Direct Routing" erfolgt aktuell über die PowerShell. Wobei sie einige Informationen mittlerweile auch im Teams Admin Portal verwalten können.

Hinweis: Einige Einstellungen sind für Location Based Routing und die Zuordnung von Notrufnummern relevant.

Eine allgemeingültige Konfiguration gibt es hier nicht. Sie müssen schon ihre eigenen Netzwerke und Standorte entsprechend einsammeln. Das geht aber alles über IP-Adressen. Die Konfiguration erfolgt über die Teams Online Powershell komplett in der Cloud.

Beschaffen Sie sich schon einmal eine vollständige Liste der Subnetze, Standorte und Regionen von den Netzwerkern und etablieren Sie einen Prozess, dass Sie von Veränderungen proaktiv unterrichtet werden.

Idealerweise passen Sie die Einstellungen vor der Produktion an, denn erforderliche Änderungen in der Cloud dauern etwas und in der Zeit kann die Telefonie gestört werden, z.B. wenn der SBC schon die internen Kandidaten sendet aber die Cloud damit nicht umgehen kann oder die Cloud schon optimierte Kandidaten erwartet aber der SBC diese noch nicht sendet.

Konfigurationsschritt erledigt

SBC Version prüfen

Ehe Sie die Konfiguration verändern, sollten Sie die Kompatibilität der installierten SBCs prüfen und der erforderliche Einstellung vornehmen.

Firewall und Routing

Beachten Sie, dass die privaten IP-Adressen des SBC durch die Clients erreichbar sein müssen. Diese Freischaltungen zum Media-Realm des SBC muss aktiv sein, ehe der SBC seine internen Kandidaten anbietet.

Natürlich muss auch das IP-Routing passen, damit Clients und SBC sich erreichen können.

Trusted IP

Zuerst müssen Sie ihre öffentlichen IP-Adressen hinterlegen, über die Clients eine Verbindung zu Teams herstellen. Diese Liste nutzt das Teams Backend zur Bestimmung, ob der Client im "Firmen-LAN" oder außerhalb ist. Nur ein Client, der intern ist, kann überhaupt direkt mit einem SBC sprechen, der nicht aus dem Internet erreichbar ist. Damit ist aber auch klar, dass Clients, die über Internetzgänge mit dynamische Adressen arbeiten, nicht als intern angesehen werden können.

Prüfen Sie auch die Funktion bei privaten VPNs, CloudVPNs und dem Einsatz von Cloud-Proxy-Servern.

New-CsTenantTrustedIPAddress `
   -IPAddress 80.66.1.2 `
   -MaskBits 28 `
   -Description "UCLabor Paderborn"
...

Microsoft verwendet in seiner Doku hier 172.16.240.110 als Beispiel. Das ist irreführend. Es muss eine öffentliche IP-Adresse sein.

Netzwerk Region

Der nächste Schritt ist die Definition von Netzwerkregionen. Die meisten Firmen nutzen hier die Kontinente. Wie damals bei CAC - Call Admission Control ist eine Region eine Gruppe von Netzwerken ohne interne Beschränkungen. Klassischen Beispiel sind Firmen mit Standorten in EMEA, US und APAC, die pro Region einen eigenen MPLS-Provider nutzen.

New-CsTenantNetworkRegion `
   -NetworkRegionID EMEA
...

Netzwerk Sites

Dann geht es darum die einzelnen Standorte in der Region zu definieren. Diese werden gebraucht, um dann im folgenden Schritt die Netzwerke dieser Seite zusammen zu fassen.

New-CsTenantNetworkSite `
   -NetworkSiteID "Paderborn" `
   -NetworkRegionID "EMEA"
New-CsTenantNetworkSite `
   -NetworkSiteID "Berlin" `
   -NetworkRegionID "EMEA"

Interne Subnetze addieren

Damit die Teams-Topologie komplett ist, müssen Sie nun alle Subnetze den Sites zuweisen. So kann der Teams Client später erkennen, in welcher Site er ist und darüber dann erkennen, ob die Konfiguration einen "Local Bypass" erlaubt. Wenn Sie schon IPv6 nutzen, müssen Sie natürlich diese Adressen auch eintragen.

New-CsTenantNetworkSubnet `
   -SubnetID 192.168.100.0 `
   -MaskBits 22 `
   -NetworkSiteID “Paderborn”
New-CsTenantNetworkSubnet `
   -SubnetID 192.168.105.0 `
   -MaskBits 24 `
   -NetworkSiteID “Berlin”

SBCs zu Sites zuordnen

Nun fehlt nur noch für die SBCs die Information, zu welcher Site sie gehören und ob der Bypass nur für Client in der gleichen Site oder generell gilt.

Set-CsOnlinePSTNGateway `
   -Identity SBCname `
   -GatewaySiteID "Paderborn" `
   -MediaBypass $true `
   -BypassMode <Always/OnlyForLocalUsers> `
   -ProxySBC  <proxy SBC FQDN or $null>

Pro SBC können sie steuern, ob er Bypass generell erlaubt und wenn, ob die Clients in der gleichen Seite sein müssen oder auch das WAN der Firma für "bypass" nutzen dürften.

SBC Konfiguration anpassen

Der letzte Schritt ist die Anpassung der SBC-Konfiguration, dass er bei einem Call mit der Information, dass es ein interner Nutzer der eigenen Site ist, die internen MediaRealms verwendet, z.B. Ports öffnet und Kandidaten liefert.

Tracing

Ich erspare mir die Mühe eine solche Konfiguration in meinem Lab auch noch per Fiddler und SIP-Logging des SBC nachzustellen. Microsoft hat her ganze Arbeit geleitet und die verschiedenen SIP-Pakete auf der folgenden Seiten ausführlich dokumentiert.

Etwas Verständnis zu SIP ist allerdings erforderlich. Es gibt aber ein paar Dinge, die sie selbst prüfen können:

Prüfpunkt Done

Teams Support File

Zuerst können Sie auf dem Client in den Logfiles prüfen, welche Location der Client erkannt hat. Fordern Sie dazu auf dem Teams Client mit "CTLR-ALT-SHIFT-1" die Diagnosedaten an und kontrollieren sie im Downloadverzeichnis die Datei %download%\MSTeams Diagnostics Log <datum>__<zeit>\web\MSTeams Diagnostics Log <datum>__<zeit>_calling.txt nach "trustedIpMatchInfo".

Hier eine Site, die eine IPv6-Adresse im Homeoffice hat (ohne VPN) und daher die SiteMatchInfo mit der Fritz-box-Adresse auch nicht weiter betrachtet wird.

      "ncsDebugInfo": {
        "trustedIpMatchInfo": {
          "publicIp": "2a00:6020:b007:3200:3c07:c4df:d9f6:882c",
          "reason": "NotMatched"
        },
        "siteMatchInfo": {
          "ipv4": "192.168.178.91",
          "subnetLengthIPv4": "24",
          "ipv6": "2a00:6020:b007:3200:e569:f4df:70eb:442e",
          "subnetLengthIPv6": "64",
          "enableLocationBasedRouting": false,
          "reason": "NotMatched"
        },
        "networkLocationMatchInfo": {
          "reason": "NotMatched"
        }
      },

SBC-Trace: Client Location

Auch beim SBC sollten Sie beim eingehenden Invite von Microsoft Teams die Location im Header sehen:

X-MS-UserLocation: internal 
X-MS-MediaPath: sbc.netatwork.de 
X-MS-UserSite: Paderborn

Diese Informationen muss der SBC gleich auswerten

SBC-Trace: Client RTP Candidates

Auch die RTP-Kandidaten müssen nicht nur die Microsoft TURN-Services enthalten, sondern auch die lokalen IP-Adressen des Clients:

a=candidate:3 1 UDP 2130705407 192.168.10.210 50002 typ host 
a=candidate:3 2 UDP 2130704894 192.168.10.210 50003 typ host 
a=candidate:4 1 tcp-act 2121005054 192.168.10.210 50000 typ host 
a=candidate:4 2 tcp-act 2121005054 192.168.10.210 50000 typ host 
a=candidate:5 1 UDP 1694496767 80.66.18.142 50002 typ srflx raddr 192.168.10.210 rport 50002 
a=candidate:5 2 UDP 1694496254 80.66.18.142 50003 typ srflx raddr 192.168.10.210 rport 50003 
a=candidate:6 1 UDP 1258288639 52.114.93.20 52999 typ relay raddr 80.66.18.142 rport 50002 
a=candidate:6 2 UDP 1258288126 52.114.93.20 53003 typ relay raddr 80.66.18.142 rport 50003 
a=candidate:7 1 tcp-act 1684795902 217.91.247.140 50006 typ srflx raddr 192.168.10.210 rport 50006 
a=candidate:7 2 tcp-act 1684795902 217.91.247.140 50006 typ srflx raddr 192.168.10.210 rport 50006 
a=candidate:8 1 tcp-pass 1248194558 52.114.93.224 59495 typ relay raddr 217.91.247.140 rport 50006 
a=candidate:8 2 tcp-pass 1248194558 52.114.93.224 59495 typ relay raddr 217.91.247.140 rport 50006 
a=candidate:9 1 tcp-act 1248587262 52.114.93.224 59495 typ relay raddr 217.91.247.140 rport 50006 
a=candidate:9 2 tcp-act 1248587262 52.114.93.224 59495 typ relay raddr 217.91.247.140 rport 50006 

Die "Type Host"-Einträge sind hier wichtig.

SBC-Trace: SBC RTP Candidates

Nachdem der SBC das alles verstanden, sollte er den Client als Intern ansehen und in der RINGING-Rückmeldung an den Server ebenfalls lokale Kandidaten des SBC übermitteln:

SIP/2.0 180 Ringing 
a=ice-lite 
a=ptime:20 
a=sendrecv 
a=ice-ufrag:xxxxx 
a=ice-pwd:xxxxxx 
a=candidate:1630614871 1 udp 2130706431 192.168.10.12 8130 typ host 
a=candidate:1630614871 2 udp 2130706430 192.168.10.12 8131 typ host
a=rtpmap:8 PCMA/8000 
a=rtpmap:101 telephone-event/8000 
a=fmtp:101 0-15,16 
a=rtpmap:13 CN/8000 
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:xxxxxxxxx/xxxxx|2^31 

In dem Beispiel sehen Sie aber auch, dass der SBC genau ein Kandidaten-Set zu Microsoft sendet. Der Client "muss" diese interne Verbindung nutzen.

Achtung: Es gibt keinen Fallback auf andere Kandidaten.

ReINVITE des Clients

Zuletzt sollten sie in den Logfiles noch die aktualisierten Kandidaten des Teams Clients sehen:

a=ice-ufrag:xxxxxx 
a=ice-pwd:xxxxxxxx+6Z8/1SOOdn 
a=candidate:3 1 UDP 2130705407 192.168.102.210 50002 typ host 
a=candidate:3 2 UDP 2130704894 192.168.102.210 50003 typ host 
a=remote-candidates:1 192.168.100.112 8130 2 192.168.100.112 8131 
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:jP+xxxxxxxxxxxxxxxx+19h3Ao5gEq|2^31 

 

Wireshark RTP

Nun kennen Sie die beiden Endpunkte und können z.B.: per Wireshark auch die Pakete dazu "finden". Es sind normale UDP-Pakete mit ca. 176 Bytes Payload.

In meinem Beispiel wird einfach der G711-Codec verwendet.

Weitere Links