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.

Warum ist das interessant?

Über die Funktion "Local Media Optimization for Direct Routing" ist es möglich dass Sie einen Session Border Controller in einer Niederlassung installieren und lokale Clients die RTP-Pakete direkt zu diesem SBC senden, obwohl dieser keinen Direct Routing Trunk to Office 365 hat.

  • Keine statische öffentlichen IP-Adresse erforderlich
  • Kein öffentliches Zertifikat erforderlich
  • Entlastung der Internet-Verbindung für Telefonie
  • Routing der Signalisierung über den zentralen SBC
  • Einbindung einer lokalen TK-Anlage ohne Umweg über die Zentrale

Diese Erweiterung erhöht aber nicht die Verfügbarkeit bei einem Ausfall des Firmen-WAN, d.h. darf nicht mit der OnPremises SBA - Survivable Branch Appliance / SBS Survivable Branch Server Lösung verwechselt werden.

Klassisch Direct Routing

Wer heute nur einen Standort hat, der sowohl PSTN/Amts-Verbindung als auch Internet-Zugriff bereit stellt, hat recht einfache Kommunikationswege.

  • Der Carrier oder die TK-Anlage spricht mit dem SBC
  • Der SBC spricht mit Teams Backend
  • Der Client spricht mit Teams
  • Der Client kann Audio auch mit der Public-IP des SBCs austauschen (Direct Routing und Media Bypass)

Die Umgebung funktioniert so natürlich nur, wenn Sie...

  • Eine öffentliche IP für den SBC haben
  • Die öffentliche IP für die Clients (mit privater IP) per "IP-Routing" erreichbar ist
  • Die Clients (mit privater IP) vom SBC erreichbar sind

Gerade die letzten beiden Punkte sind für Firewall-Administratoren und Security durchaus eine Herausforderung, da oft eine Durchgängigkeit zwischen privaten und öffentlichen Adressen doch arg beschränkt sind.

Einschränkungen

Die klassische Anbindung der Direct Routing Konfiguration erfordert einen SIP-Trunk und mindestens eine öffentliche IP-Adresse, einen dazugehörigen DNS-Namen und ein passendes Zertifikat. Der SIP-Trunk wird in beide Richtungen aufgebaut. Eine Firma mit einem Standort kann diese Technik problemlos bereitstellen aber wenn sie mehrere Standorte mit unterschiedlicher Anschlusstechnik haben, kann dies schon zu Mehrkosten führen, die man eigentlich sparen will. In vielen Firmen gibt es zudem schon Niederlassungen mit TK-Anlagen, die nicht sofort abgelöst werden sollen und dennoch sollen "interne" Gespräche auch intern bleiben. Ich habe dazu folgendes Bild skizziert:

  • Hauptstelle
    Der mittlere Standort hat eine klassische Anbindung ans Internet mit Firewall und fester IP-Adresse und kann mit dem SBC auch mit dem Teams Backend kommunizieren. Die Signalisierung ist direkt und der SBC kann entsprechende Kandidaten für die Audio-Daten aus der öffentlichen Adresse ableiten. Damit funktioniert Audio mit Teams und auch die internen Clients können mit dem SBC kommunizieren.
  • Standort ohne eigenes Internet
    Der linke Standort gibt es sicher noch bei den ein oder anderen Firmen, die früher schon einen zentralen Internetzugang über das eigene WAN bereit gestellt haben. Damit sparte man sich die lokale Firewall und Zugangsprovider. Für Office 365 ist so eine Topologie natürlich suboptimal.
  • Standort mit "einfachem" Internet
    Es hat sich sicher schon rumgesprochen, dass für die Nutzung mit Office 365 ein direkter Internetzugang die beste Lösung ist. Das kann aber auch ein DSL-Anschluss mit dynamischer IP-Adresse sein, der nach extern mit einer einfachen Firewall z.B. nur NAT macht. Hier kann natürlich kein SIP-Trunk zu Teams aufgebaut werden, da die Cloud eine Verbindung zum SBC aufbaut. Eine dynamische IP-Adresse ist dafür keine gute Basis.

Alle drei Standorte haben aber schon heute eine TK-Anlage oder zumindest einen lokalen Telefonanschluss. Wenn die Rufnummern nicht zu Microsoft portiert werden können und auch ein Umzug zur Hauptstelle unmöglich ist, könnte ein SBC vor Ort ja die Verbindung zur TK-Anlage liefert. Das Problem dabei ist aber, dass der SBC dann nur mit privaten Adressen hantiert und diese von Teams abgeschnitten werden. Zudem kann der SBC vor Ort auch nicht sauber mit dem Microsoft Teams Backend sprechen, da er ja nicht erreichbar ist.

Lösung

Genau dieses Problem löst Microsoft durch die neue Funktion, bei der lokale SBCs eine Verbindung zu einer TK-Anlage ermöglichen und private IP-Adresse als RTP-Kandidaten bereitstellen. Damit können PCs im gleichen internen LAN dann direkt mit dem SBC die RTP-Pakete austauschen und Gespräche zwischen TK-Teilnehmern und internen Teams-Anwendern bleiben intern genauso wie Amtsgespräche der internen Teams-Teilnehmer.

Das bedeutet aber auch, dass der SBC irgendwie doch mit mit der "Vermittlung", d.h. dem Teams Backend kommunizieren muss. Hinzu kommt. dass in dem Moment noch gar nicht bekannt ist, wo der Anwender letztlich ist. Er könnte sich ja auch im HomeOffice befinden oder offline sein, so dass die Cloud Voice Mail dien Ruf annehmen muss. Daher routet der SBC in der Niederlassung die SIP-Pakete über den SBC in der Zentrale. Dieser SBC kann nun die SDP-Kandidaten um Kandidaten der eigenen öffentlichen IP-Adresse erweitern und so auch eine externe Erreichbarkeit sicherstellen. Wir haben also

  • Eine zentrale Signalisierung über den Haupt-SBC
  • RTP-Kandidaten des zentralen SBC
    Damit auch Dienste in Teams (Call Queues, Cloud Voice Mail etc.) und Anwender außerhalb des Netzwerks RTP nutzen können
  • RTP-Kandidaten des lokalen SBC
    Damit interne Clients gar nicht erst über Umwege mit dem Teams Edge-Servern kommunizieren müssen

Wenn ein Client in einer anderen Site ist, dann können Sie per Konfiguration bestimmen, ob er sich zu "seinem" SBC per RTP verbindet oder die Daten besser über den zentralen Hub-SBC oder sogar das Internet gehen.

Szenario: Niederlassung ohne Internet

Interessant wird es, wenn Sie eine Niederlassung ohne externe Internetanbindung haben. Es ist ja klar, dass der Client alle Office 365 Dienste dann erst einmal über das firmeneigene WAN zum nächsten Breakout nutzt. Auch die Signalisierung mit Teams läuft diesen Weg und hier gibt es auch keine Optimierung.

Wenn es aber nun in der Niederlassung immer noch einen Telefonanschluss gibt, dann ist eine lokale Audio-Verbindung wünschenswert um das WAN oder das Internet zu entlasten und vor allem die Qualität einfacher bereitstellen zu können. Das gilt umso mehr, wenn hier kein "Teams only"-Deployment ansteht sondern es vor Ort immer noch eine Vermittlungsstelle mit Telefonen gibt und nur ein Teil der Anwender mit Teams arbeitet.

In beiden Fällen kann ein SBC vor Ort installiert werden, um die Audio-Daten zwischen dem Teams-Client und einer lokalen Vermittlungsstelle oder dem Amtsanschluss auch lokal zu halten.

Szenario: Niederlassung mit Internet ohne SIP-Trunk

Um die Office 365 Performance zu verbessern installieren viele Firmen auch in den Niederlassungen einen lokalen Internet Breakout. Das ist auch ohne komplexe Firewalls möglich, wenn Sie z.B. nur die IP-Adressen von Office 365 über diesen lokalen Ausgang routen und alle andere "gefährlichen Webseiten" weiterhin über die zentralen Dienste, Firewalls und Proxy-Server leiten.

In vielen Fällen tut es da schon ein DSL 50/100 Anschluss, der aber oft keine statische IP-Adresse hat. Mit einer dynamischen IP-Adresse können Sie hier aber nicht arbeiten, denn Sie müssen ja die Teams Site in der Konfiguration anhand der öffentlichen IP-Adresse hinterlegen. Wenn die Anwender aber jeden Tag von einer anderen IP-Adresse auf Teams in der Cloud zugreifen, dann behandelt Teams diese Anwender als "Externe".

Damit ist klar, dass eine eine dynamische IP-Adresse für Teams zwar generell geeignet wäre aber hier die Funktion "Local Media Optimization for Direct Routing" nicht konfiguriert werden kann. Sie können natürlich dafür sorgen, dass die Teams-Zugriffe nun weiter über die Zentrale gehen und nur noch Outlook, Exchange, SharePoint, OneDrive und andere Cloud-Dienste den lokalen Breakout mit dynamischer IP-Adresse verwenden. Dann funktioniert die Konstellation wieder.

Die private Adresse ist ja weltweit nicht eindeutig. Schade, dass Teams hier nicht mit einem "network location server" oder der MAC-Adresse des Default Gateways o.ä. arbeitet, um einen "internen Client" zu erkennen.

Konfiguration

Die Konfiguration von "Local Media Optimization for Direct Routing" erfolgt aktuell über die PowerShell.

Vorher sollten Sie aber sicherstellen, dass ihr SBC auch in der Liste der supporteten Geräte geführt wird UND die verwendete Firmware die erforderliche Mindestversion hat

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.

Konfigurationsschritt erledgit

SBC Version prüfen

Ehe Sie die Konfiguration verändern, sollten Sie die Kompatibilität der installierten SBCs prüfen und derforderliche 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.

New-CsTenantNetworkRegion -NetworkRegionID EMEA
...

Netzwerk Sites

DDann 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

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

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