Teilen über

Planen von direktem Routing

  • Artikel
  • Gilt für:
    Microsoft Teams

Mit Direct Routing können Sie einen unterstützten, vom Kunden bereitgestellten Session Border Controller (SBC) mit Microsoft Teams Phone verbinden. Mit dieser Funktion können Sie die lokale PSTN-Konnektivität (Public Switched Telephone Network) mit Teams konfigurieren, wie im folgenden Diagramm dargestellt:

Diagramm, das die Konfiguration der lokalen PSTN-Konnektivität zeigt.

Die Planung Ihrer Bereitstellung von Direct Routing ist der Schlüssel für eine erfolgreiche Implementierung. In diesem Artikel werden die Infrastruktur- und Lizenzierungsanforderungen beschrieben und Informationen zur SBC-Konnektivität bereitgestellt. Lesen Sie diesen Artikel, bevor Sie mit der Konfiguration beginnen. Dies wird unter Konfigurieren von Direct Routing beschrieben.

Mit Direct Routing können Sie Ihren SBC mit fast jedem Telefonie-Trunk oder mit PSTN-Geräten von Drittanbietern verbinden. Direct Routing ermöglicht Folgendes:

  • Verwenden Sie praktisch jeden PSTN-Trunk mit Teams Phone.

  • Konfigurieren sie die Interoperabilität zwischen kundeneigenen Telefoniegeräten, z. B. einer Nebenstellenanlage (Private Branch Exchange, PBX) eines Drittanbieters, analogen Geräten und Teams.

Microsoft bietet auch All-in-the-Cloud-VoIP-Lösungen an, z. B. Microsoft-Anrufplan. Direct Routing eignet sich jedoch möglicherweise am besten für Ihre Organisation, wenn:

  • Der Microsoft-Anrufplan ist in Ihrem Land/Ihrer Region nicht verfügbar.

  • Ihre Organisation benötigt eine Verbindung mit analogen Drittanbietergeräten, Callcentern usw.

  • Ihre Organisation verfügt über einen bestehenden Vertrag mit einem PSTN-Netzbetreiber.

Weitere Informationen zu Sprachlösungen finden Sie unter Planen Ihrer Teams-Sprachlösung.

Wenn Benutzer bei Direct Routing an einer geplanten Besprechung teilnehmen, wird die Einwahlnummer vom Microsoft-Audiokonferenzdienst bereitgestellt, der eine ordnungsgemäße Lizenzierung erfordert. Beim Auswählen führt Audiokonferenzen den Anruf mithilfe von Onlineanruffunktionen durch, die eine ordnungsgemäße Lizenzierung erfordern. Wenn ein Benutzer nicht über eine Microsoft-Audiokonferenzlizenz verfügt, wird der Anruf über Direct Routing weitergeleitet. Weitere Informationen finden Sie unter Direct Routing mit Audiokonferenzen.

Direct Routing unterstützt auch Benutzer, die über eine andere Lizenz für Den Microsoft-Anrufplan verfügen. Weitere Informationen finden Sie unter Direct Routing mit Anrufplan und Operator Connect.

Infrastrukturanforderungen

Die Infrastrukturanforderungen für die unterstützten SBCs, Domänen und andere Netzwerkkonnektivitätsanforderungen für die Bereitstellung von Direct Routing sind in der folgenden Tabelle aufgeführt:

Infrastrukturanforderung Sie benötigen Folgendes:
Session Border Controller (SBC) Ein unterstützter SBC. Weitere Informationen finden Sie unter Unterstützte SBCs.
Mit dem SBC verbundene Telefonie-Trunks Mindestens ein Telefonie-Trunk, der mit dem SBC verbunden ist. Auf einer Seite stellt der SBC über Direct Routing eine Verbindung mit Teams Phone her. Der SBC kann auch eine Verbindung mit Telefonieentitäten von Drittanbietern herstellen, z. B. Nebenstellenanlagen, analoge Telefonieadapter usw. Alle PSTN-Konnektivitätsoptionen, die mit dem SBC verbunden sind, funktionieren. (Informationen zur Konfiguration der PSTN-Trunks für den SBC finden Sie bei den SBC-Anbietern oder Trunkanbietern.)
Microsoft 365-Organisation Eine Microsoft 365-Organisation, die Sie verwenden, um Ihre Microsoft Teams-Benutzer zu hosten, sowie die Konfiguration und Verbindung mit dem SBC.
Benutzerregistrierungsstelle Der Benutzer muss in Microsoft 365 homed sein.
Wenn Ihr Unternehmen über eine lokale Skype for Business-Umgebung mit Hybridkonnektivität mit Microsoft 365 verfügt, können Sie die Spracheingabe in Teams nicht für einen lokal verwalteten Benutzer aktivieren.

Verwenden Sie das folgende Teams PowerShell-Cmdlet, um die Registrierungsstelle eines Benutzers zu überprüfen:
Get-CsOnlineUser -Identity <user> | fl HostingProvider

Die Ausgabe des Cmdlets sollte Folgendes anzeigen:
HostingProvider : sipfed.online.lync.com
Domänen Eine oder mehrere Domänen, die Ihren Microsoft 365- oder Office 365-Organisationen hinzugefügt wurden.

Sie können nicht die Standarddomäne *.onmicrosoft.com verwenden, die automatisch für Ihren Mandanten erstellt wird.

Zum Anzeigen der Domänen können Sie das folgende Teams PowerShell-Cmdlet verwenden:
Get-CsTenant | fl Domains

Weitere Informationen zu Domänen und Microsoft 365- oder Office 365-Organisationen finden Sie unter Häufig gestellte Fragen zu Domänen.
Öffentliche IP-Adresse für den SBC Eine öffentliche IP-Adresse, die zum Herstellen einer Verbindung mit dem SBC verwendet werden kann. Basierend auf dem Typ des SBC kann der SBC NAT verwenden.
Vollqualifizierter Domänenname (FQDN) für den SBC Ein FQDN für den SBC, bei dem der Domänenteil des FQDN eine der registrierten Domänen in Ihrer Microsoft 365- oder Office 365-Organisation ist. Weitere Informationen finden Sie unter SBC-Domänennamen.
Öffentlicher DNS-Eintrag für den SBC Ein öffentlicher DNS-Eintrag, der den SBC-FQDN der öffentlichen IP-Adresse zuzuordnen.
Öffentliches vertrauenswürdiges Zertifikat für den SBC Ein Zertifikat für den SBC, das für die gesamte Kommunikation mit Direct Routing verwendet werden soll. Weitere Informationen finden Sie unter Öffentliches vertrauenswürdiges Zertifikat für den SBC.
Verbindungspunkte für Direct Routing Die Verbindungspunkte für Direct Routing sind die folgenden drei FQDNs:

sip.pstnhub.microsoft.com – Globaler FQDN, muss zuerst versucht werden.
sip2.pstnhub.microsoft.com – Sekundärer FQDN, geografisch der zweiten Prioritätsregion zugeordnet.
sip3.pstnhub.microsoft.com – Tertiärer FQDN, geografisch der dritten Prioritätsregion zugeordnet.

Informationen zu konfigurationsanforderungen finden Sie unter SIP-Signalisierung: FQDNs.
Firewall-IP-Adressen und -Ports für Direct Routing-Medien Der SBC kommuniziert mit den folgenden Diensten in der Cloud:

– SIP-Proxy, der die Signalisierung übernimmt
– Medienprozessor, der Medien verarbeitet – außer wenn die Medienumgehung aktiviert ist

Diese beiden Dienste verfügen über separate IP-Adressen in Microsoft Cloud, die weiter unten in diesem Dokument beschrieben werden.

Weitere Informationen finden Sie im Microsoft Teams-Abschnitt unter URLs und IP-Adressbereiche.
Medientransportprofil TCP/RTP/SAVP
UDP/RTP/SAVP

Lizenzierung und andere Anforderungen

Direct Routing-Benutzern müssen die folgenden Lizenzen in Microsoft 365 zugewiesen sein:

  • Teams Telefon
  • Microsoft Teams

Informationen dazu, wann eine Audiokonferenzlizenz erforderlich ist, finden Sie unter Direct Routing mit Audiokonferenzen.

Direct Routing unterstützt auch Benutzer, die für Microsoft-Anrufplan lizenziert sind. Weitere Informationen finden Sie unter Direct Routing mit Anrufplan und Operator Connect.

Weitere Informationen zur Lizenzierung finden Sie unter Microsoft Teams-Lizenzierung und Microsoft Teams-Add-On-Lizenzierung.

Hinweis: Direct Routing wird im Inselmodus nicht unterstützt.

Direct Routing mit Audiokonferenzen

In diesem Abschnitt werden die Anforderungen und Überlegungen bei der Verwendung von Direct Routing und Audiokonferenzen beschrieben.

  • Benutzern von GCC High und DoD G5 empfiehlt Microsoft, die in G5 enthaltene Audiokonferenzkomponente zu deaktivieren, bis Sie Direct Routing konfigurieren und dem Mandanten Ihrer Organisation Audiokonferenznummern hinzugefügt haben.

  • Für GCC High- und DoD G3-Benutzer empfiehlt Microsoft, dass Sie das Audiokonferenz-Lizenz-Add-On erst zuweisen, wenn Sie Direct Routing konfigurieren und Audiokonferenznummern zum Mandanten Ihrer Organisation hinzugefügt haben.

Weitere Informationen finden Sie unter Audiokonferenzen mit Direct Routing für GCC High und DoD.

Lizenz für ungeplante Anrufausweitung und Audiokonferenz

Ein Teams-Benutzer kann einen 1:1-Teams-zu-PSTN- oder Teams-zu-Teams-Anruf starten und einen PSTN-Teilnehmer hinzufügen. Der Pfad, den der Anruf einnimmt, hängt davon ab, ob dem Benutzer, der den Anruf eskaliert, eine Microsoft-Audiokonferenzlizenz zugewiesen wurde oder nicht:

  • Wenn dem Teams-Benutzer, der den Anruf eskaliert, eine Microsoft-Audiokonferenzlizenz zugewiesen ist, erfolgt die Eskalation über den Microsoft-Audiokonferenzdienst. Der Zum vorhandenen Anruf eingeladene PstN-Remoteteilnehmer erhält eine Benachrichtigung über den eingehenden Anruf und sieht die Nummer der Microsoft-Brücke, die dem Teams-Benutzer zugewiesen ist, der die Eskalation initiiert hat.

  • Wenn dem Teams-Benutzer, der den Anruf eskaliert, nicht die Microsoft Audio Conferencing-Lizenz zugewiesen ist, erfolgt die Eskalation über einen Session Border Controller, der mit der Direct Routing-Schnittstelle verbunden ist. Der zum Anruf eingeladene PstN-Remoteteilnehmer erhält eine Benachrichtigung über den eingehenden Anruf und sieht die Nummer des Teams-Benutzers, der die Eskalation initiiert hat. Der spezifische SBC, der für die Eskalation verwendet wird, wird durch die Routingrichtlinie des Benutzers definiert.

Sie müssen Folgendes sicherstellen:

  • CsOnlineVoiceRoutingPolicy wird dem Benutzer zugewiesen.

  • Private Anrufe zulassen ist auf Mandantenebene für Microsoft Teams aktiviert.

Direct Routing mit Anrufplänen und Operator Connect

Direct Routing unterstützt auch Benutzer, die für Microsoft-Anrufplan lizenziert sind oder eine Operator Connect-Telefonnummer zugewiesen haben. Teams Telefon mit Anrufplan oder Operator Connect aktivierte Benutzer können einige Anrufe über die Direct Routing-Schnittstelle weiterleiten.

Das Kombinieren von Anrufplan- oder Operator Connect- und Direct Routing-Konnektivität für denselben Benutzer ist optional, kann aber nützlich sein. Beispielsweise, wenn dem Benutzer ein Microsoft-Anrufplan oder eine Operator Connect-Nummer zugewiesen ist, aber einige Anrufe mithilfe des SBC weiterleiten möchte.

Eines der häufigsten Szenarien sind Aufrufe von Nebenstellenanlagen von Drittanbietern. Mit dieser Konfiguration werden Anrufe an die Telefone, die mit der Nebenstellenanlage eines Drittanbieters verbunden sind, über Direct Routing weitergeleitet und verbleiben daher innerhalb des Unternehmensnetzwerks und nicht im PSTN. In der Zwischenzeit werden alle anderen Aufrufe basierend auf der vom Benutzer zugewiesenen PSTN-Konnektivitätsmethode an das PSTN weitergeleitet: Microsoft Calling Plan oder Operator Connect.

Weitere Informationen zur Microsoft Teams Phone-Lizenzierung finden Sie unter Microsoft Teams-Add-On-Lizenzierung.

Unterstützte Endpunkte

Sie können Folgendes als Endpunkt verwenden:

SBC-Domänennamen

Der SBC-Domänenname muss aus einem der Namen stammen, die in Domänen des Mandanten registriert sind.

Die folgende Tabelle enthält Beispiele für DNS-Namen, die für den Mandanten registriert sind, ob der Name als FQDN für den SBC verwendet werden kann, und Beispiele für gültige FQDN-Namen. Beachten Sie, dass Sie den *.onmicrosoft.com-Mandanten nicht für den FQDN-Namen des SBC verwenden können.

DNS-Name Kann für den SBC-FQDN verwendet werden Beispiele für FQDN-Namen
contoso.com Ja Gültige Namen:
sbc1.contoso.com
ssbcs15.contoso.com
europe.contoso.com
contoso.onmicrosoft.com Nein Die Verwendung von *.onmicrosoft.com-Domänen wird für SBC-Namen nicht unterstützt.

Angenommen, Sie möchten einen neuen Domänennamen verwenden. Ihr Mandant hat beispielsweise contoso.com als Domänenname in Ihrem Mandanten registriert, und Sie möchten sbc1.sip.contoso.com verwenden.

Bevor Sie einen SBC mit dem Namen sbc1.sip.contoso.com koppeln können, müssen Sie den Domänennamen sip.contoso.com in Domänen in Ihrem Mandanten registrieren. Wenn Sie versuchen, einen SBC mit sbc1.sip.contoso.com zu koppeln, bevor Sie den Domänennamen registrieren, erhalten Sie die folgende Fehlermeldung: "Die Domäne "sbc1.sip.contoso.com" kann nicht verwendet werden, da sie für diesen Mandanten nicht konfiguriert wurde."

Nachdem Sie den Domänennamen hinzugefügt haben, müssen Sie einen Benutzer mit UPN user@sip.contoso.com erstellen und eine Teams-Lizenz zuweisen. Es kann bis zu 24 Stunden dauern, bis der Domänenname vollständig bereitgestellt wird, nachdem er Domänen Ihres Mandanten hinzugefügt wurde, einen Benutzer mit einem neuen Namen zu erstellen und dem Benutzer eine Lizenz zuzuweisen.

Es ist möglich, dass ein Unternehmen mehrere SIP-Adressräume in einem Mandanten hat. Beispielsweise kann ein Unternehmen contoso.com als SIP-Adressraum und fabrikam.com als zweiten SIP-Adressraum verwenden. Einige Benutzer haben eine Adresse user@contoso.com , und einige Benutzer haben die Adresse user@fabrikam.com.

Der SBC benötigt nur einen FQDN und kann Benutzer aus jedem Adressraum im gekoppelten Mandanten bedienen. Beispielsweise kann ein SBC mit dem Namen sbc1.contoso.com den PSTN-Datenverkehr für Benutzer mit Adressen user@contoso.comuser@fabrikam.com empfangen und senden, solange diese SIP-Adressräume im selben Mandanten registriert sind.

Hinweis

Der SBC-FQDN im direkten Azure Communication Services-Routing muss sich vom SBC-FQDN in Teams Direct Routing unterscheiden.

Öffentliches vertrauenswürdiges Zertifikat für den SBC

Microsoft empfiehlt, das Zertifikat für den SBC anzufordern, indem Sie eine Zertifizierungssignaturanforderung (Certificate Signing Request, CSR) generieren. Spezifische Anweisungen zum Generieren einer CSR für einen SBC finden Sie in den Verbindungsanweisungen oder der Dokumentation, die von Ihren SBC-Anbietern bereitgestellt werden.

Hinweis

Für die meisten Zertifizierungsstellen muss die Größe des privaten Schlüssels mindestens 2048 sein. Beachten Sie dies beim Generieren der CSR.

Das Zertifikat muss über den SBC-FQDN als allgemeinen Namen (Common Name, CN) oder das Feld "Alternativer Antragstellername" (SAN) verfügen.

Alternativ unterstützt Direct Routing einen Wildcard-Wert im CN und/oder SAN, und der Wildcard muss dem RFC-Standard HTTP über TLS entsprechen.

Ein Beispiel wäre die Verwendung von *.contoso.com, die dem SBC-FQDN sbc.contoso.com, aber nicht mit sbc.test.contoso.com übereinstimmt.

Die Direct Routing-SIP-Schnittstelle vertraut nur Zertifikaten, die von Zertifizierungsstellen signiert wurden, die Teil des Microsoft-Programms für vertrauenswürdige Stammzertifikate sind. Stellen Sie sicher, dass eine Zertifizierungsstelle, die Teil des Programms ist, Ihr SBC-Zertifikat signiert. Stellen Sie außerdem sicher, dass die Erweiterung für erweiterte Schlüsselverwendung (Extended Key Usage, EKU) Ihres Zertifikats serverauthentifizierung und Clientauthentifizierung enthält.

Weitere Informationen finden Sie unter Programmanforderungen – Microsoft Trusted Root Program und Liste der eingeschlossenen Zertifizierungsstellenzertifikate.

Hinweis

Ende August 2023 aktualisiert Microsoft 365 seine Dienste für die Verwendung von TLS-Zertifikaten, die von der neuen Zertifizierungsstelle "DigiCert Global Root G2" ausgestellt wurden. Um Fehler zu vermeiden, die sich auf Ihren Dienst auswirken können, müssen Sie den Zertifikatstammspeicher Ihres SBC so aktualisieren, dass er die neue Stammzertifizierungsstelle enthält. Weitere Informationen finden Sie unter Änderung des SIP-Zertifikats an die MSPKI-Zertifizierungsstelle.

Für Direct Routing in Office 365 GCCH- und DoD-Umgebungen muss eine der folgenden Stammzertifizierungsstellen das Zertifikat generieren:

  • DigiCert Globale Stammzertifizierungsstelle
  • DigiCert High Assurance EV Root CA

Hinweis

Wenn die Unterstützung für gegenseitiges TLS (MTLS) für die Teams-Verbindung auf dem SBC aktiviert ist, müssen Sie die Zertifikate Baltimore CyberTrust Root und DigiCert Global Root G2 im SBC Trusted Root Store des Teams TLS-Kontexts installieren. (Dies liegt daran, dass die Microsoft-Dienstzertifikate eines dieser beiden Stammzertifikate verwenden.) Informationen zum Herunterladen dieser Stammzertifikate finden Sie unter Microsoft 365-Verschlüsselungsketten. Weitere Informationen finden Sie unter Office TLS-Zertifikatänderungen.

Um zu überprüfen, ob die MTLS-Verbindung aus der Teams-Infrastruktur stammt, sollte der SBC so konfiguriert werden, dass die folgenden Überprüfungen für das serverseitige Microsoft Teams-Zertifikat implementiert werden:

  • Überprüfen Sie, ob die Zertifikatausstellungskette von einer der folgenden Stammzertifizierungsstellen stammt:

  • Überprüfen Sie, ob das Zertifikat "Alternativer Antragstellername" "sip.pstnhub.microsoft.com" enthält.

SIP-Signalisierung: FQDNs, Ports, Failovermechanismus

Direct Routing wird in den folgenden Umgebungen angeboten:

  • Microsoft 365 oder Office 365
  • Office 365 GCC
  • Office 365 GCC High
  • Office 365 DoD

Weitere Informationen zu Regierungsumgebungen wie GCC, GCC High und DoD finden Sie unter Office 365- und US-Behördenumgebungen.

In den folgenden Abschnitten werden Informationen zu FQDNs, Ports und Failovermechanismen beschrieben.

SIP-Signalisierung: FQDNs

In den folgenden Abschnitten werden die FQDN-Verbindungspunkte für verschiedene Microsoft-Cloudumgebungen beschrieben.

Microsoft 365-, Office 365- und Office 365 GCC-Umgebungen

In diesen Umgebungen sind die Verbindungspunkte für Direct Routing die folgenden drei FQDNs:

  • sip.pstnhub.microsoft.com – globaler FQDN – muss zuerst versucht werden. Wenn der SBC eine Anforderung zum Auflösen dieses Namens sendet, geben die Microsoft Azure DNS-Server eine IP-Adresse zurück, die auf das primäre Azure-Rechenzentrum verweist, das dem SBC zugewiesen ist. Die Zuweisung basiert auf Leistungsmetriken 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.

Die Platzierung dieser drei FQDNs in der Reihenfolge ist für Folgendes erforderlich:

  • Optimale Benutzererfahrung (weniger geladen und dem zugewiesenen SBC-Rechenzentrum durch Abfragen des ersten FQDNs am nächsten)

  • Stellen Sie ein Failover bereit, wenn eine Verbindung von einem SBC mit einem Rechenzentrum hergestellt wird, bei dem ein temporäres Problem auftritt. Weitere Informationen finden Sie unter Failovermechanismus.

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.122.0.0/15

Sie müssen Ports für alle diese IP-Adressbereiche in Ihrer Firewall öffnen, um eingehenden und ausgehenden Datenverkehr zu und von den Adressen für die Signalisierung zuzulassen.

Hinweis: Eingehender SIP-Datenverkehr an die SBCs von Teams SIP-Endpunkten kann von allen IP-Adressen in diesen Subnetzen stammen– nicht nur von IP-Adressen, die aus den zuvor erwähnten FQDNs aufgelöst werden. Weitere Informationen zum Einrichten von SIP-Peering finden Sie in der SBC-Dokumentation.

Office GCC DoD-Umgebung

In der Office GCC DoD-Umgebung ist der Verbindungspunkt für Direct Routing der folgende FQDN:

sip.pstnhub.dod.teams.microsoft.us : Globaler FQDN. Da die Office 365 DoD-Umgebung nur in den US-Rechenzentren vorhanden ist, 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 Subnetz aufgelöst: 52.127.64.0/21

Um eingehenden und ausgehenden Datenverkehr zu und von den Adressen für die Signalisierung zuzulassen, müssen Sie Ports für alle diese IP-Adressen in Ihrer Firewall öffnen.

Office 365 GCC High-Umgebung

In der Office 365 GCC High-Umgebung ist der Verbindungspunkt für Direct Routing der folgende FQDN:

sip.pstnhub.gov.teams.microsoft.us : Globaler FQDN. Da die GCC High-Umgebung nur in den US-Rechenzentren vorhanden ist, 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 Subnetz aufgelöst: 52.127.88.0/21

Um eingehenden und ausgehenden Datenverkehr zu und von den Adressen für die Signalisierung zuzulassen, müssen Sie Ports für alle diese IP-Adressen in Ihrer Firewall öffnen.

SIP-Signalisierung: Ports

Sie müssen die folgenden Ports für Microsoft 365- oder Office 365-Umgebungen verwenden, in denen Direct Routing angeboten wird:

Verkehr Von Bis Quellport Zielport
SIP/TLS SIP-Proxy SBC 1024 – 65535 Definiert auf dem SBC (für Office 365 GCC High/DoD muss nur Port 5061 verwendet werden)
SIP/TLS SBC SIP-Proxy Definiert auf dem SBC 5061

SIP-Signalisierung: Failovermechanismus

Um sip.pstnhub.microsoft.com aufzulösen, führt der SBC eine DNS-Abfrage aus. Basierend auf dem SBC-Standort und den Leistungsmetriken des Rechenzentrums wird das primäre Rechenzentrum ausgewählt.

Wenn im primären Rechenzentrum ein Problem besteht, versucht der SBC, sip2.pstnhub.microsoft.com, die in das zweite zugewiesene Rechenzentrum aufgelöst wird. In dem seltenen Fall, dass Rechenzentren in zwei Regionen nicht verfügbar sind, wiederholt der SBC den letzten FQDN (sip3.pstnhub.microsoft.com), der die IP-Adresse des tertiären Rechenzentrums bereitstellt.

In der folgenden Tabelle sind die Beziehungen zwischen primären, sekundären und tertiären Rechenzentren zusammengefasst:

Wenn das primäre Rechenzentrum ist EMEA NOAM ASIEN
Das sekundäre Rechenzentrum (sip2.pstnhub.microsoft.com) US EU US
Das tertiäre Rechenzentrum (sip3.pstnhub.microsoft.com) ASIEN ASIEN EU

Mediendatenverkehr: Portbereiche, Medienprozessoren, CODECS

Mediendatenverkehr: Portbereiche

Wenn Sie Direct Routing ohne Medienumgehung bereitstellen möchten, gelten die folgenden Anforderungen. Informationen zu Firewallanforderungen für die Medienumgehung finden Sie unter Planen der Medienumgehung mit Direct Routing.

Der Mediendatenverkehr fließt zu und von einem separaten Dienst in der Microsoft Cloud. Die IP-Adressbereiche für Den Mediendatenverkehr sind wie folgt.

Hinweis

Die in diesem Dokument vorgestellten IP-Adressbereiche sind spezifisch für Direct Routing und können sich von denen unterscheiden, die für den Teams-Client empfohlen werden.

Microsoft 365-, Office 365- und Office 365 GCC-Umgebungen

In den Microsoft 365-, Office 365- und Office 365 GCC-Umgebungen sind die IP-Adressbereiche:

  • 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)

Office 365 DoD-Umgebung

In der Office 365 DoD-Umgebung sind die IP-Adressbereiche:

  • 52.127.64.0/21

Office 365 GCC High-Umgebung

In der Office 365 GCC High-Umgebung sind die IP-Adressbereiche:

  • 52.127.88.0/21

Alle Umgebungen

Die Portbereiche der Medienprozessoren sind 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

Hinweis

Microsoft empfiehlt mindestens zwei Ports pro gleichzeitigem Aufruf auf dem SBC.

Mediendatenverkehr: Geografie der Prozessoren

Der Mediendatenverkehr fließt über Komponenten, die als Medienprozessoren bezeichnet werden. Medienprozessoren werden wie folgt in den gleichen Rechenzentren wie SIP-Proxys platziert:

  • NOAM (USA, Süden-Mitte, zwei rechenzentren in den Rechenzentren "USA, Westen" und "USA, Osten")
  • Europa (Rechenzentren vereinigtes Königreich, Süden, Frankreich, Mitte, Amsterdam und Dublin)
  • Asien (Rechenzentrum Singapur)
  • Japan (JP-Rechenzentren , Osten und Westen)
  • Australien (Rechenzentren in der REGION, Osten und Südosten)
  • LATAM (Brasilien, Süden)

Mediendatenverkehr: Codecs

In den folgenden Abschnitten werden die Codecs für den Mediendatenverkehr beschrieben.

Wechsel zwischen SBC und Cloud Media Processor oder Microsoft Teams-Client

Gilt sowohl für Medienumgehungsfälle als auch für Fälle ohne Umgehung.

Die Direct Routing-Schnittstelle zwischen dem Session Border Controller und dem Cloud Media Processor (ohne Medienumgehung) oder zwischen dem Teams-Client und dem SBC (wenn die Medienumgehung aktiviert ist) kann die folgenden Codecs verwenden:

  • Nicht-Medienumgehung (SBC zu Cloud-Medienprozessor): SILK, G.711, G.722, G.729
  • Medienumgehung (SBC zu Teams-Client): SILK, G.711, G.722, G.729

Sie können die Verwendung des bestimmten Codecs auf dem Session Border Controller erzwingen, indem Sie unerwünschte Codecs aus dem Angebot ausschließen.

Verbindung zwischen Dem Microsoft Teams-Client und dem Cloudmedienprozessor

Gilt nur für Nicht-Medienumgehungsfälle. Bei der Medienumgehung fließen die Medien direkt zwischen dem Teams-Client und dem SBC.

Auf dem Bein zwischen dem Cloud-Medienprozessor und dem Teams-Client wird entweder SILK oder G.722 verwendet. Die Codec-Auswahl auf diesem Bein basiert auf Microsoft-Algorithmen, die mehrere Parameter berücksichtigen.

Hinweis

Die erneute Ausrichtung von Medien wird nicht unterstützt. Wenn während eines Anrufs direct routing SBC SIP re-Invite (Offer) eine neue Medien-IP-Adresse, einen Port oder einen Transport enthält, werden keine Medien vom PSTN-Hub an das neue Ziel gesendet. Gemäß RFC 3264 8.3.1 ist die Unterstützung von Medienzielen optional (nicht erforderlich).

Unterstützte Session Border Controller (SBCs)

Microsoft unterstützt nur zertifizierte SBCs für die Kopplung mit Direct Routing. Da Enterprise Voice für Unternehmen von entscheidender Bedeutung ist, führt Microsoft intensive Tests mit den ausgewählten SBCs durch und arbeitet mit den SBC-Anbietern zusammen, um sicherzustellen, dass die beiden Systeme kompatibel sind.

Geräte, die überprüft werden, werden als Zertifiziert für Teams Direct Routing aufgeführt. Die zertifizierten Geräte funktionieren garantiert in allen Szenarien.

Weitere Informationen zu unterstützten SBCs finden Sie unter Für Direct Routing zertifizierte Session Border Controller.

Supportgrenzen

Microsoft unterstützt Teams Phone nur mit Direct Routing, wenn es mit zertifizierten Geräten verwendet wird. Wenn Probleme auftreten, müssen Sie sich zuerst an den Kundensupport Ihres SBC-Anbieters wenden. Bei Bedarf eskaliert der SBC-Anbieter das Problem über interne Kanäle an Microsoft. Microsoft behält sich das Recht vor, Supportfälle abzulehnen, in denen ein nicht zertifiziertes Gerät über Direct Routing mit Teams Phone verbunden ist. Wenn Microsoft feststellt, dass das Direct Routing-Problem eines Kunden mit dem SBC-Gerät eines Anbieters liegt, muss der Kunde den SBC-Anbieter erneut an den Support binden.

Siehe auch