Planen von direktem Routing

  • Artikel
  • 16 Minuten Lesedauer
  • Gilt für:
    Microsoft Teams

Tipp

Sehen Sie sich die folgende Sitzung an, um mehr über die Vorteile von Direct Routing zu erfahren, wie Sie es planen und wie Sie es bereitstellen: Direct Routing in Microsoft Teams

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

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

Hinweis

mit Skype for Business Online können Sie auch einen vom Kunden bereitgestellten SBC koppeln. Dies erfordert jedoch eine lokale Skype for Business Server-Bereitstellung oder eine spezielle Edition von Skype for Business namens Cloud Connector zwischen dem SBC und der Microsoft Cloud. Dieses Szenario wird als hybride Stimme bezeichnet. Im Gegensatz dazu ermöglicht Direct Routing eine direkte Verbindung zwischen dem unterstützten SBC und der Microsoft Cloud.

Wichtig

Cloud Connector Edition wird am 31. Juli 2021 zusammen mit Skype for Business Online eingestellt. Nachdem Ihre Organisation ein Upgrade auf Teams durchgeführt hat, erfahren Sie, wie Sie Ihr lokales Telefonienetzwerk mithilfe von Direct Routing mit Teams verbinden.

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

  • 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, z. B. Anrufplan. Eine Hybrid-VoIP-Lösung eignet sich jedoch möglicherweise am besten für Ihre Organisation, wenn:

  • Der Microsoft-Anrufplan ist in Ihrem Land 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.

Direct Routing unterstützt auch Benutzer, die über die zusätzliche Lizenz für den Microsoft-Anrufplan verfügen. Weitere Informationen hierzu finden Sie in Telefonsystem und Anrufpläne.

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

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:

Ausführliche Informationen zum Konfigurieren von Direct Routing finden Sie unter Konfigurieren von Direct Routing.

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 dem Telefonsystem 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- oder Lync-Umgebung mit Hybridkonnektivität mit Microsoft 365 verfügt, können Sie die Spracheingabe in Teams nicht für einen lokal verwalteten Benutzer aktivieren.

Um die Registrierungsstelle eines Benutzers zu überprüfen, verwenden Sie das folgende Skype for Business Online PowerShell-Cmdlet:
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.

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

Zum Anzeigen der Domänen können Sie das folgende Skype for Business Online 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 SBC-Typ 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 verarbeitet
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
Firewall-IP-Adressen und -Ports für Microsoft Teams-Medien Weitere Informationen finden Sie unter URLs und IP-Adressbereiche.

Lizenzierung und andere Anforderungen

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

  • Microsoft-Telefonsystem
  • Microsoft Teams + Skype for Business Plan 2, sofern in der Lizenzierung enthalten
  • Microsoft-Audiokonferenzen (Lesen Sie die Hinweise und den folgenden Absatz, um spezifische Beispiele dafür zu finden, wann diese Lizenz erforderlich ist.)

Hinweis

Skype for Business Plan sollte nicht aus einem Lizenzvertrag entfernt werden, in dem er enthalten ist.

Wichtig

GCC High- und DoD-Benutzer sollten alle in G5 enthaltenen Audiokonferenzlizenzen deaktivieren und warten, bis Direct Routing vollständig konfiguriert ist. Benutzer sollten Einwahlnummern und eine funktionierende Wähltastatur konfiguriert haben, bevor Sie Audiokonferenzlizenzen aktivieren. Weitere Informationen finden Sie unter Audiokonferenzen mit Direct Routing für GCC High und DoD .

Wichtig

Wenn Sie externe Teilnehmer zu geplanten Besprechungen hinzufügen möchten, indem Sie diese anrufen oder die Einwahlnummer angeben, ist die Lizenz für Audiokonferenzen erforderlich. Weisen Sie für GCC High und DoD keine Audiokonferenzlizenz für G5-Benutzer zu. Weisen Sie G3-Benutzern erst dann eine Lizenz für Audiokonferenzen zu, wenn Direct Routing vollständig konfiguriert ist und der Benutzer über eine funktionierende Wähltastatur verfügt.

Lizenz für Ad-hoc-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. Dieses Szenario wird als Ad-hoc-Konferenz bezeichnet. 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-Audiokonferenzlizenz 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 unterstützt auch Benutzer, die für Microsoft-Anrufplan lizenziert sind. Das Telefonsystem mit Anrufplan kann einige Anrufe über die Direct Routing-Schnittstelle weiterleiten. Die Telefonnummern der Benutzer müssen jedoch entweder online abgerufen oder zu Microsoft portiert werden.

Das Kombinieren von Anrufplan- und Direct Routing-Konnektivität für denselben Benutzer ist optional, kann aber nützlich sein. Beispielsweise, wenn dem Benutzer ein Microsoft-Anrufplan zugewiesen ist, er aber einige Anrufe mithilfe des SBC weiterleiten möchte. Eines der häufigsten Szenarien sind Aufrufe von Nebenstellenanlagen von Drittanbietern. Bei Nebenstellenanlagen von Drittanbietern werden alle Anrufe mit Ausnahme von Anrufen, die mit dieser Nebenstellenanlage verbunden sind, mithilfe des Microsoft-Anrufplans weitergeleitet, aber Anrufe an die Telefone, die mit Nebenstellenanlagen von Drittanbietern verbunden sind, gehen an den SBC und bleiben daher innerhalb des Unternehmensnetzwerks und nicht im PSTN.

Weitere Informationen zur Telefonsystemlizenzierung finden Sie unter Optimale Verwendung von Office - und Planoptionen und Microsoft Teams-Add-On-Lizenzierung.

Unterstützte Endpunkte

Sie können als Endpunkt verwenden:

SBC-Domänennamen

Der SBC-Domänenname muss aus einem der Namen stammen, die in Domänen des Mandanten registriert sind. Sie können den *.onmicrosoft.com-Mandanten nicht für den FQDN-Namen des SBC verwenden.

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, sowie Beispiele für gültige FQDN-Namen:

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 nicht für diesen Mandanten konfiguriert wurde."

Nachdem Sie den Domänennamen hinzugefügt haben, müssen Sie auch 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 wurde, nachdem er domänen ihres Mandanten hinzugefügt wurde, ein Benutzer mit einem neuen Namen erstellt und dem Benutzer eine Lizenz zugewiesen wurde.

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 in Azure Communication Services direct 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

Die meisten Zertifizierungsstellen erfordern, dass die Größe des privaten Schlüssels mindestens 2048 beträgt. 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, das 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 Ihr SBC-Zertifikat von einer Zertifizierungsstelle signiert ist, die Teil des Programms ist, und dass die Erweiterung für erweiterte Schlüsselverwendung (Extended Key Usage, EKU) Ihres Zertifikats die Serverauthentifizierung enthält. Weitere Informationen: Programmanforderungen – Microsoft Trusted Root Program

Liste der eingeschlossenen Zertifizierungsstellenzertifikate

Für Direct Routing in Office 365 GCCH- und DoD-Umgebungen muss das Zertifikat von einer der folgenden Stammzertifizierungsstellen generiert werden:

  • 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 vertrauenswürdigen SBC-Stammspeicher 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 Office 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: Baltimore CyberTrust Root -- DigiCert Global Root G2
  • Überprüfen Sie, ob das Zertifikat "Alternativer Antragstellername" "sip.pstnhub.microsoft.com" enthält.

SIP-Signalisierung: FQDNs

Direct Routing wird in den folgenden Umgebungen angeboten:

  • Microsoft 365 oder Office 365
  • Office 365 GCC
  • Office 365 GCC High
  • 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 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 weiter unten 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.120.0.0/14

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.

Office 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 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

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

Office 365 GCC High-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 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

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

SIP-Signalisierung: Ports

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

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

Failovermechanismus für SIP-Signalisierung

Der SBC führt eine DNS-Abfrage aus, um sip.pstnhub.microsoft.com aufzulösen. Basierend auf dem SBC-Standort und den Leistungsmetriken des Rechenzentrums wird das primäre Rechenzentrum ausgewählt. Wenn beim primären Rechenzentrum ein Problem auftritt, versucht der SBC den sip2.pstnhub.microsoft.com, der in das zweite zugewiesene Rechenzentrum aufgelöst wird. In seltenen Fällen, in denen 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

Beachten Sie, dass die folgenden Anforderungen gelten, wenn Sie Direct Routing ohne Medienumgehung bereitstellen möchten. Informationen zu den 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 Mediendatenverkehr sind wie folgt.

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

  • 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-Adressbereiche sind spezifisch für Direct Routing und können sich von denen unterscheiden, die für den Teams-Client empfohlen werden.

Office 365 DoD-Umgebung

  • 52.127.64.0/21

Office 365 GCC High-Umgebung

  • 52.127.88.0/21

Portbereich (gilt für alle Umgebungen)

Der Portbereich der Medienprozessoren wird in der folgenden Tabelle angezeigt:

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 Medienprozessoren

Der Mediendatenverkehr fließt über Komponenten, die als Medienprozessoren bezeichnet werden. Medienprozessoren befinden sich in denselben Rechenzentren wie SIP-Proxys:

  • 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

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

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

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

  • Nicht-Medienumgehung (SBC zu Cloud Media Processor): 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 spezifischen Codecs auf dem Session Border Controller erzwingen, indem Sie unerwünschte Codecs aus dem Angebot ausschließen.

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 Microsoft 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

Erneute Medienadressierung wird nicht unterstützt. Wenn der SBC während eines Direct Routing-Anrufs eine neue Medien-IP an Teams Direct Routing sendet, obwohl diese in der SIP-Signalisierung ausgehandelt wird, werden die Medien nie von Teams Direct Routing an die neue IP-Adresse gesendet.

Unterstützte Session Border Controller (SBCs)

Microsoft unterstützt nur zertifizierte SBCs für die Kopplung mit Direct Routing. Da Enterprise-VoIP für Unternehmen wichtig 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 wurden, 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 das Telefonsystem mit Direct Routing nur, wenn es mit zertifizierten Geräten verwendet wird. Bei Problemen müssen Sie sich zuerst an den Kundensupport Ihres SBC-Lieferanten wenden. Bei Bedarf wird der SBC-Lieferant das Problem über interne Kanäle an Microsoft eskalieren. Microsoft behält sich das Recht vor, Supportfälle abzulehnen, in denen ein nicht zertifiziertes Gerät über Direct Routing mit dem Telefonsystem verbunden ist. Wenn Microsoft feststellt, dass das Direct Routing-Problem eines Kunden mit dem SBC-Gerät eines Lieferanten zusammenhängt, muss der Kunde den SBC-Anbieter erneut engagieren, um Support zu erhalten.

Siehe auch

Konfigurieren von direktem Routing