Planen der Medienumgehung mit direktem Routing
Konfigurieren der Medienumgehung mit direktem Routing
Mit der Medienumgehung können Sie den Pfad des Medienverkehrs verkürzen und die Anzahl der Transit-Sprünge reduzieren, um die Leistung zu verbessern. Um eine bessere Leistung zu erzielen, werden Medien zwischen dem Session Border Controller (SBC) und dem Client behalten, anstatt sie über Microsoft Teams Telefon zu senden. Um die Medienumgehung zu konfigurieren, müssen sich der SBC und der Client am selben Standort oder im selben Netzwerk befinden.
Sie können die Medienumgehung für jeden SBC steuern, indem Sie den Befehl Set-CSOnlinePSTNGateway verwenden, wobei der Parameter -MediaBypass auf true oder false festgelegt ist. Wenn Sie die Medienumgehung aktivieren, bedeutet dies nicht, dass der gesamte Mediendatenverkehr innerhalb des Unternehmensnetzwerks verbleibt. Dieser Artikel beschreibt den Anrufablauf in verschiedenen Szenarien.
Die folgenden Diagramme veranschaulichen den Unterschied im Anruffluss mit und ohne Medienumgehung.
Wenn ein Client einen Anruf tätigen oder empfängt, wird ohne Medienumgehung sowohl der Signal- als auch der Medienfluss zwischen dem SBC, dem Microsoft Teams Telefon-System und dem Teams-Client durchgeführt, wie im folgenden Diagramm dargestellt:
Aber nehmen wir an, dass sich ein Benutzer im selben Gebäude oder Netzwerk wie der SBC befindet. Nehmen wir an, ein Benutzer, der sich in einem Gebäude in Frankfurt befindet, führt einen Anruf an einen PSTN-Benutzer:
Ohne Medienumgehung fließen die Medien entweder über Amsterdam oder Dublin (wo Microsoft-Rechenzentren eingerichtet sind) und zurück zum SBC in Frankfurt.
Das Rechenzentrum in Europa wird ausgewählt, weil sich der SBC in Europa befindet und Microsoft das Rechenzentrum verwendet, das dem SBC am nächsten liegt. Dieser Ansatz beeinträchtigt zwar nicht die Gesprächsqualität, da der Datenverkehr innerhalb der Microsoft-Netzwerke in den meisten Regionen optimiert wird, aber der Datenverkehr hat eine unnötige Schleife.
Mit Medienumgehung werden die Medien direkt zwischen dem Teams-Benutzer und dem SBC gehalten, wie in der folgenden Abbildung dargestellt:
Die Medienumgehung verwendet Protokolle namens Interactive Connectivity Establishment (ICE) auf dem Teams-Client und ICE lite auf dem SBC. Mit diesen Protokollen kann Direct Routing den direktesten Medienpfad für optimale Qualität nutzen. ICE und ICE Lite sind WebRTC-Standards. Ausführliche Informationen zu diesen Protokollen finden Sie in RFC 5245.
Planung des Anrufflusses und der Firewall
Die Planung des Anrufflusses und der Firewall hängt davon ab, ob der Benutzer direkten Zugang zur öffentlichen IP-Adresse des SBC hat und ob er sich innerhalb oder außerhalb des Netzes befindet.
Anruffluss, wenn der Benutzer direkten Zugang zur öffentlichen IP-Adresse des SBC hat
Wenn der Benutzer direkten Zugriff auf die öffentliche IP-Adresse des SBC hat, sieht der Anrufablauf wie folgt aus:
Für die Medienumgehung muss der Teams-Client auch von einem internen Netz aus Zugriff auf die öffentliche IP-Adresse des SBC haben. Wenn keine direkten Medien gewünscht sind, können die Medien über Transportrelais fließen.
Dieser Ablauf ist die empfohlene Lösung, wenn sich ein Benutzer im selben Gebäude und/oder Netzwerk wie der SBC befindet – entfernen Sie Microsoft Cloud-Komponenten aus dem Medienpfad.
Die Signalisierung erfolgt immer über die Microsoft-Cloud.
Das folgende Diagramm zeigt den Anruffluss, wenn die Medienumgehung aktiviert ist, der Client intern ist und der Client die öffentliche IP-Adresse des SBC erreichen kann (direkte Medien):
Die Pfeile und numerischen Werte der Pfade entsprechen den Microsoft Teams Call Flows.
Die SIP-Signalisierung erfolgt immer über die Pfade 4 und 4' (abhängig von der Richtung des Datenverkehrs). Die Medien bleiben vor Ort und nehmen den Weg 5b.
Anrufablauf, wenn der Benutzer keinen Zugriff auf die öffentliche IP-Adresse des SBC hat
Das folgende Szenario beschreibt den Anruffluss, wenn der Benutzer keinen Zugriff auf die öffentliche IP-Adresse des SBC hat.
Angenommen, es handelt sich um einen externen Benutzer, und der Mandantenadministrator hat beschlossen, die öffentliche IP-Adresse des SBC nicht für alle Internetnutzer, sondern nur für die Microsoft Cloud zu öffnen. Die internen Komponenten des Verkehrs können über die Teams Transport Relays fließen. Berücksichtigen Sie dabei Folgendes:
Teams Transport Staffeln werden verwendet.
Für die Medienumgehung verwendet Microsoft eine Version von Transport Relays, bei der die Ports 50 000 bis 59 999 zwischen den Teams Transport Relays und dem SBC geöffnet werden müssen (in Zukunft planen wir den Wechsel zu einer Version, die die Ports 3478-3481 erfordert).
Das folgende Diagramm zeigt den Anruffluss, wenn die Medienumgehung aktiviert ist, der Client extern ist und der Client die öffentliche IP-Adresse des Session Border Controllers nicht erreichen kann (die Medien werden von Teams Transport Relay weitergeleitet).
Die Pfeile und numerischen Werte der Pfade entsprechen den Microsoft Teams Call Flows.
Die Medien werden über die Pfade 3, 3', 4 und 4' weitergeleitet.
Anrufablauf, wenn sich ein Benutzer außerhalb des Netzes befindet und Zugriff auf die öffentliche IP des SBC hat
Hinweis
Dies ist keine empfohlene Konfiguration, da sie die Vorteile von Teams Transport Relays nicht nutzt. Stattdessen sollten Sie das vorherige Szenario in Betracht ziehen, bei dem der Benutzer keinen Zugriff auf die öffentliche IP-Adresse des SBC hat.
Das folgende Diagramm zeigt den Anruffluss, wenn die Medienumgehung aktiviert ist, der Client extern ist und der Client die öffentliche IP-Adresse des SBC erreichen kann (direkte Medien).
Die Pfeile und numerischen Werte der Pfade entsprechen dem Artikel Microsoft Teams call flows.
Die SIP-Signalisierung erfolgt immer über die Pfade 3 und 3' (abhängig von der Richtung des Datenverkehrs). Medienströme über Pfad 2.
Einsatz von Medienprozessoren und Transportrelais
In der Microsoft Cloud gibt es zwei Komponenten, die sich im Pfad des Medienverkehrs befinden können: Medienprozessoren und Transport-Relais.
Der Medienprozessor ist eine öffentlich zugängliche Komponente, die Medien in Nichtumgehungs-Fällen und Medien für Sprachanwendungen verarbeitet.
Medienprozessoren befinden sich immer im Pfad für nicht umgangene Endbenutzeranrufe, aber nie im Pfad für umgangene Anrufe. Medienprozessoren befinden sich immer im Pfad für alle Sprachanwendungen wie Call Park, Organizational Auto Attendant und Call Queues.
Das Transportrelais wird verwendet, um eine Verbindung zum nächstgelegenen Transportdienst herzustellen, um den Datenverkehr in Echtzeit zu senden.
Je nachdem, wo sich der Benutzer befindet und wie das Netz konfiguriert ist, können sich Transport-Relais im Pfad für umgangene Anrufe befinden, die von Endbenutzern ausgehen oder für diese bestimmt sind, oder auch nicht.
Das folgende Diagramm zeigt zwei Anrufströme – einen mit aktivierter Medienumgehung und den zweiten mit deaktivierter Medienumgehung.
Hinweis
Das Diagramm zeigt nur den Verkehr, der von Endnutzern ausgeht oder für sie bestimmt ist.
Der Media Controller ist ein Microservice in Azure, der Medienprozessoren zuweist und SDP-Angebote (Session Description Protocol) erstellt.
Der SIP-Proxy ist eine Komponente, die die in Teams verwendete HTTP-REST-Signalisierung in SIP übersetzt.
In der folgenden Tabelle sind die Unterschiede zwischen Medienprozessoren und Transportrelais zusammengefasst.
| Medienprozessoren | Transport-Relais | |
|---|---|---|
| Im Medienpfad für nicht umgangene Anrufe für Endnutzer | Immer | Wenn der Client den Medienprozessor nicht direkt erreichen kann |
| Im Medienpfad für umgangene Anrufe für Endnutzer | Niemals | Wenn der Client den SBC nicht über die öffentliche IP-Adresse erreichen kann |
| Im Medienpfad für Sprachanwendungen | Immer | Niemals |
| Kann Transkodierung durchführen (B2BUA)* | Ja | Nein, leitet nur Audio zwischen Endpunkten weiter |
Die IP-Bereiche sind:
- 52.112.0.0/14 (IP-Adressen von 52.112.0.0 bis 52.115.255.255)
- 52.120.0.0/14 (IP-Adressen von 52.120.0.0 bis 52.123.255.255)
Hinweis
Die in diesem Dokument vorgestellten IP-Bereiche sind spezifisch für Direct Routing und können sich von denen unterscheiden, die für Teams Client empfohlen werden.
* Erklärung zur Transkodierung:
Der Medienprozessor ist B2BUA, d. h. er kann Codecs wechseln (z. B. SILK vom Teams-Client zum MP und G.711 zwischen MP und SBC).
Transportrelais sind keine B2BUA, d. h. der Codec wird nie zwischen dem Client und dem SBC geändert, selbst wenn der Verkehr über Relays fließt.
Verwendung von Teams Medienprozessoren, wenn der Trunk für Medienumgehung konfiguriert ist
Teams Medienprozessoren werden in den folgenden Szenarien immer in den Medienpfad eingefügt:
- Anruf wird von 1:1 zu einem Gruppenanruf eskaliert
- Der Anruf geht an einen föderierten Teams-Benutzer
- Anruf wird an einen Skype for Business-Benutzer weitergeleitet oder übergeben
Stellen Sie sicher, dass Ihr SBC Zugriff auf die Bereiche Medienprozessoren und Transportrelais hat, wie unten beschrieben.
SIP-Signalisierung: FQDNs
Für die SIP-Signalisierung gelten die gleichen FQDN- und Firewall-Anforderungen wie für die nicht umgangenen Fälle.
Direct Routing wird in den folgenden Microsoft 365- oder Office 365-Umgebungen angeboten:
- Microsoft 365 oder Office 365
- Office 365 GCC
- Office 365 GCC Hoch
- Office 365 DoD
Erfahren Sie mehr über Office 365 und US-Regierungsumgebungen wie GCC, GCC High und DoD.
Microsoft 365-, Office 365- und Office 365 GCC-Umgebungen
Die Verbindungspunkte für Direct Routing sind die folgenden drei FQDNs:
sip.pstnhub.microsoft.com – Globaler FQDN – muss zuerst ausprobiert werden. Wenn der SBC eine Anforderung zur Auflösung dieses Namens sendet, geben die Microsoft Azure DNS-Server eine IP-Adresse zurück, die auf das dem SBC zugewiesene primäre Azure-Rechenzentrum verweist. Die Zuweisung erfolgt auf der Grundlage von Leistungskennzahlen der Rechenzentren und der geografischen Nähe zum SBC. Die zurückgegebene IP-Adresse entspricht dem primären FQDN.
sip2.pstnhub.microsoft.com – Sekundärer FQDN – wird geografisch der zweiten Prioritätsregion zugeordnet.
sip3.pstnhub.microsoft.com – Tertiärer FQDN – wird geografisch der dritten Prioritätsregion zugeordnet.
Sie müssen diese drei FQDNs angeben, um:
Optimale Erfahrung (weniger belastet und am nächsten zum SBC-Rechenzentrum, das durch Abfrage des ersten FQDN zugewiesen wird).
Bietet Failover, wenn eine Verbindung von einem SBC zu einem Rechenzentrum hergestellt wird, in dem vorübergehend ein Problem auftritt. Weitere Informationen finden Sie unter Failover-Mechanismus weiter unten.
Die FQDNs sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com und sip3.pstnhub.microsoft.com werden in IP-Adressen aus den folgenden Subnetzen aufgelöst:
- 52.112.0.0/14
- 52.120.0.0/14
Sie müssen für alle diese IP-Bereiche in Ihrer Firewall Ports öffnen, um den ein- und ausgehenden Datenverkehr zu und von den Adressen für die Signalisierung zuzulassen.
Office 365 GCC DoD-Umgebung
Der Verbindungspunkt für Direct Routing ist der folgende FQDN:
sip.pstnhub.dod.teams.microsoft.us – globaler FQDN. Da die Office 365 DoD-Umgebung nur in den US-Rechenzentren existiert, gibt es keine sekundären und tertiären FQDNs.
Der FQDN sip.pstnhub.dod.teams.microsoft.us wird in eine IP-Adresse aus dem folgenden Teilnetz aufgelöst:
- 52.127.64.0/21
Sie müssen für alle diese IP-Bereiche in Ihrer Firewall Ports öffnen, um den ein- und ausgehenden Datenverkehr zu und von den Adressen für die Signalisierung zuzulassen. Wenn Ihre Firewall DNS-Namen unterstützt, wird der FQDN sip.pstnhub.dod.teams.microsoft.us in alle diese IP-Subnetze aufgelöst.
Office 365 GCC Hohe Umgebung
Der Verbindungspunkt für Direct Routing ist der folgende FQDN:
sip.pstnhub.gov.teams.microsoft.us - Globaler FQDN. Da die GCC High-Umgebung nur in den US-Rechenzentren existiert, gibt es keine sekundären und tertiären FQDNs.
Der FQDN sip.pstnhub.gov.teams.microsoft.us wird in eine IP-Adresse aus dem folgenden Teilnetz aufgelöst:
- 52.127.88.0/21
Sie müssen für alle diese IP-Bereiche in Ihrer Firewall Ports öffnen, um den ein- und ausgehenden Datenverkehr zu und von den Adressen für die Signalisierung zuzulassen. Wenn Ihre Firewall DNS-Namen unterstützt, wird der FQDN sip.pstnhub.gov.teams.microsoft.us in alle diese IP-Subnetze aufgelöst.
SIP-Signalisierung: Ports
Die Portanforderungen sind für alle Office 365-Umgebungen, in denen Direct Routing angeboten wird, gleich:
- Microsoft 365 oder Office 365
- Office 365 GCC
- Office 365 GCC Hoch
- Office 365 DoD
Sie müssen die folgenden Ports verwenden:
| Verkehr | Von | Bis | Quellport | Zielport |
|---|---|---|---|---|
| SIP/TLS | SIP-Proxy | SBC | 1024 - 65535 | Definiert auf dem SBC |
| SIP/TLS | SBC | SIP-Proxy | Definiert auf dem SBC | 5061 |
Medienverkehr: IP- und Portbereiche
Der Medienverkehr fließt zwischen dem SBC und dem Teams-Client, wenn direkte Konnektivität verfügbar ist, oder über Teams Transport Relays, wenn der Client den SBC nicht über die öffentliche IP-Adresse erreichen kann.
Anforderungen für direkten Medienverkehr (zwischen dem Teams-Client und dem SBC)
Der Client muss auf der öffentlichen IP-Adresse des SBC Zugriff auf die angegebenen Ports (siehe Tabelle) haben.
Hinweis
Befindet sich der Client in einem internen Netzwerk, fließen die Medien an die öffentliche IP-Adresse des SBC. Sie können Hair Pinning auf Ihrem NAT-Gerät so konfigurieren, dass der Datenverkehr das Unternehmensnetzwerk nicht verlässt.
| Verkehr | Von | Bis | Quellport | Zielport |
|---|---|---|---|---|
| UDP/SRTP | Client | SBC | 50000-50019 | Definiert auf dem SBC |
| UDP/SRTP | SBC | Client | Definiert auf dem SBC | 50000-50019 |
Hinweis
Wenn Sie ein Netzwerkgerät haben, das die Quellports des Clients übersetzt, stellen Sie bitte sicher, dass die übersetzten Ports zwischen dem Netzwerkgerät und dem SBC geöffnet sind.
Voraussetzungen für die Verwendung von Transportrelais
Transportrelais liegen im gleichen Bereich wie Medienprozessoren (für Nichtumgehungs-Fälle):
Microsoft 365-, Office 365- und Office 365 GCC-Umgebungen
- 52.112.0.0 /14 (IP-Adressen von 52.112.0.1 bis 52.115.255.254)
Office 365 GCC DoD-Umgebung
- 52.127.64.0/21
Office 365 GCC Hohe Umgebung
- 52.127.88.0/21
Der Anschlussbereich der Teams Transport Relays (gilt für alle Umgebungen) ist in der folgenden Tabelle aufgeführt:
| Verkehr | Von | Bis | Quellport | Zielport |
|---|---|---|---|---|
| UDP/SRTP | Transport-Relais | SBC | 50000–59999 | Definiert auf dem SBC |
| UDP/SRTP | SBC | Transport-Relais | Definiert auf dem SBC | 50000-59999, 3478-3481 |
Hinweis
Microsoft empfiehlt mindestens zwei Ports pro gleichzeitigem Anruf auf dem SBC. Da Microsoft zwei Versionen von Transport Relays anbietet, sind folgende Voraussetzungen erforderlich:
v4, die nur mit dem Portbereich 50000 bis 59999 arbeiten kann
v6, die mit dem Portbereich 3478 bis 3481 arbeitet
Voraussetzungen für die Verwendung von Medienprozessoren
Medienprozessoren befinden sich immer im Medienpfad für Sprachanwendungen und für Webclients (z. B. Teams-Clients in Microsoft Edge oder Google Chrome). Die Anforderungen sind dieselben wie bei der Konfiguration ohne Umgehung.
Der IP-Bereich für den Medienverkehr ist:
Office 365 und Office 365 GCC Umgebungen
- 52.112.0.0 /14 (IP-Adressen von 52.112.0.1 bis 52.115.255.254)
Office 365 GCC DoD-Umgebung
- 52.127.64.0/21
Office 365 GCC Hohe Umgebung
- 52.127.88.0/21
Der Anschlussbereich der Medienprozessoren (gilt für alle Umgebungen) ist in der folgenden Tabelle aufgeführt:
| Verkehr | Von | Bis | Quellport | Zielport |
|---|---|---|---|---|
| UDP/SRTP | Medienprozessor | SBC | 3478-3481 und 49152-53247 | Definiert auf dem SBC |
| UDP/SRTP | SBC | Medienprozessor | Definiert auf dem SBC | 3478-3481 und 49152-53247 |
Konfigurieren Sie separate Trunks für Medienumgehung und Nicht-Medienumgehung
Wenn Sie von einer Nicht-Medienumgehung auf eine Medienumgehung migrieren und die Funktionalität bestätigen möchten, bevor Sie die gesamte Nutzung auf die Medienumgehung migrieren, können Sie einen separaten Trunk und eine separate Online-Sprachrouting-Richtlinie erstellen, um zum Medienumgehungs-Trunk zu leiten und bestimmten Benutzern zuzuweisen.
Hochrangige Konfigurationsschritte:
Identifizieren Sie die Benutzer, die die Medienumgehung testen sollen.
Erstellen Sie zwei separate Trunks mit unterschiedlichen FQDNs: eine ist für die Medienumgehung aktiviert, die andere nicht.
Beide Trunks zeigen auf denselben SBC. Die Ports für die TLS-SIP-Signalisierung müssen unterschiedlich sein. Die Anschlüsse für die Medien müssen identisch sein.
Erstellen Sie eine neue Online-Voice-Routing-Richtlinie und ordnen Sie den Mediaumgehungs-Trunk den entsprechenden Routen zu, die mit der PSTN-Nutzung für diese Richtlinie verbunden sind.
Weisen Sie die neue Online-Voice-Routing-Richtlinie den Benutzern zu, die Sie zum Testen der Medienumgehung ermittelt haben.
Das folgende Beispiel veranschaulicht diese Logik.
| Gruppe von Benutzern | Anzahl der Benutzer | In OVRP zugewiesener Trunk-FQDN | Medienumgehung aktiviert |
|---|---|---|---|
| Benutzer mit Nicht-Medienumgehungs-Trunk | 980 | sbc1.contoso.com:5061 | false |
| Benutzer mit Medienumgehungs-Trunk | 20 | sbc2.contoso.com:5060 | True |
Beide Trunks können auf denselben SBC mit derselben öffentlichen IP-Adresse verweisen. Die TLS-Signalisierungsports auf dem SBC müssen unterschiedlich sein, wie im folgenden Diagramm dargestellt. Beachten Sie, dass Sie sicherstellen müssen, dass Ihr Zertifikat beide Trunks unterstützt. Im SAN benötigen Sie zwei Namen (sbc1.contoso.com und sbc2.contoso.com) oder ein Wildcard-Zertifikat.
Informationen über die Konfiguration von zwei Trunks auf demselben SBC finden Sie in der Dokumentation Ihres SBC-Herstellers:
- AudioCodes Einsatzdokumentation
- Oracle-Bereitstellungsdokumentation
- Ribbon Communications Einsatzdokumentation
- TE-Systems (anynode) Einsatzdokumentation
Unterstützte Client-Endpunkte mit Medienumgehung
Die Medienumgehung wird von allen eigenständigen Teams Desktop-Clients, Android- und iOS-Clients sowie Teams Telefon-Geräte unterstützt.
Bei allen anderen Endpunkten, die keine Medienumgehung unterstützen, wird der Anruf in eine Nichtumgehung umgewandelt, selbst wenn er als Umgehungsanruf begonnen hat. Diese Konvertierung erfolgt automatisch und erfordert keine Maßnahmen seitens des Administrators. Dazu gehören Skype for Business 3PIP-Telefone und Teams Web Clients, die Direct Routing-Anrufe unterstützen (WebRTC-basierte Clients, die auf Microsoft Edge, Google Chrome und Mozilla Firefox laufen).