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.

  • 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.
  • Definition von Sites und Regions
    Dann muss der Administrator die interne Topologie mit privaten IP-Adressen, Network Sites und Network Regions pflegen
  • SBC-Zuordnung
    Zuletzt muss für jede SBC in Teams eine Site zugewiesen und die Bypass-Option konfiguriert werden.
  • SBC-Konfiguration
    Eventuell ist 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.

Danach sollte der Client RTP direkt zum SBC senden. Nun gibt es aber noch einige weitere Fälle.

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 PublicIP

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 PublicIP 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 WindowsVPN, 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.

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.

Trusted IP

Zuerst müssen Sie ihre öffentlichen IP-Adressen, über die Clients eine Verbindung zu Teams herstellen, hinterlegen. 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.

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

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

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.

Weitere Links