Freigeben über

Anforderungen an die Azure Direct Routing-Infrastruktur

  • Artikel

Dieser Artikel enthält ausführliche Informationen zur Infrastruktur, Lizenzierung und SBC-Konnektivität (Session Border Controller), die bei der Planung Ihrer Bereitstellung von direktem Azure-Routing berücksichtigt werden sollten.

Infrastrukturanforderungen

In der folgenden Tabelle sind die Infrastrukturanforderungen für die unterstützten SBCs und Domänen sowie andere Netzwerkkonnektivitätsanforderungen für die Bereitstellung des direkten Azure-Routings aufgeführt:

Infrastrukturanforderung Voraussetzung
Session Border Controller (SBC) Unterstützter SBC. Weitere Informationen finden Sie unter Unterstützte Session Border Controller (SBC).
Mit dem SBC verbundene Telefonie-Trunks Mindestens ein mit dem SBC verbundener Telefonie-Trunk. Auf einer Seite ist der SBC über direktes Routing mit der Azure Communication Services-Instanz verbunden. Der SBC kann auch Verbindungen mit Drittanbieter-Telefonieentitäten wie Nebenstellenanlagen und analogen Telefonieadaptern herstellen. Jede mit dem SBC verbundenen Konnektivitätsoption Public Switched Telephoney Network (PSTN) funktioniert. (Informationen zur Konfiguration der Festnetz-Trunks für den SBC erhalten Sie vom jeweiligen SBC- oder Trunk-Anbieter.)
Azure-Abonnement Ein Azure-Abonnement zum Erstellen der Communication Services-Ressource sowie die Konfiguration und die Verbindung mit dem SBC.
Communication Services-Zugriffstoken Um Anrufe tätigen zu können, benötigen Sie ein gültiges Zugriffstoken mit dem Bereich voip. Weitere Informationen finden Sie unter Zugriffstoken.
Öffentliche IP-Adresse für den SBC Eine öffentliche IP-Adresse, die verwendet werden kann, um eine Verbindung mit dem SBC herzustellen. Basierend auf dem SBC-Typ kann der SBC NAT verwenden.
Vollqualifizierter Domänenname (Fully Qualified Domain Name, FQDN) für den SBC Weitere Informationen finden Sie unter SBC-Zertifikate und Domänennamen.
Öffentlicher DNS-Eintrag für den SBC Ein öffentlicher DNS-Eintrag, der den SBC-FQDN der öffentlichen IP-Adresse zuordnet.
Öffentliches vertrauenswürdiges Zertifikat für den SBC Ein Zertifikat für den SBC, das für die gesamte Kommunikation mit direktem Azure-Routing verwendet wird. Weitere Informationen finden Sie unter SBC-Zertifikate und Domänennamen.
Firewall-IP-Adressen und -Ports für SIP-Signalisierung und Medien Der SBC kommuniziert mit folgenden Diensten in der Cloud:

SIP-Proxy (zur Behandlung der Signalisierung)
Medienprozessor (zur Behandlung von Medien)

Die beiden Dienste verfügen in Microsoft Cloud über unterschiedliche IP-Adressen. Weitere Informationen finden Sie weiter unten in diesem Dokument.

SBC-Zertifikate und Domänennamen

Microsoft empfiehlt, das Zertifikat für den SBC über eine Zertifikatsignieranforderung (Certificate Signing Request, CSR) anzufordern. Eine spezielle Anleitung zum Erstellen einer CSR für einen SBC finden Sie in der Verbindungsanleitung oder in der Dokumentation Ihres SBC-Anbieters.

Hinweis

Bei den meisten Zertifizierungsstellen (Certificate Authorities, CA) muss die Größe des privaten Schlüssels mindestens 2.048 betragen. Beachten Sie dies beim Generieren der CSR.

Für das Zertifikat muss der SBC-FQDN als allgemeiner Name (Common Name, CN) oder als alternativer Antragstellername (Subject Alternative Name, SAN) verwendet werden. Das Zertifikat muss direkt von einer Zertifizierungsstelle ausgestellt werden, nicht von einem Zwischenanbieter.

Alternativ unterstützt das direkte Routing von Communication Services auch einen Platzhalter in CN und/oder SAN. Der Platzhalter muss dem Standard RFC HTTP Over TLS entsprechen.

Kunden, die bereits Office 365 verwenden und eine Domäne in Microsoft 365 Admin Center registriert haben, können den SBC-FQDN aus derselben Domäne verwenden.

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

Hinweis

SBC-FQDN in Azure Communication Services Direct Routing muss sich von SBC-FQDN in Teams Direct Routing unterscheiden.

Communication Services-Zertifikate, die von Zertifizierungsstellen (Certificate Authorities, CAs) signiert wurden und 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 „Erweiterte Schlüsselverwendung“ (Extended Key Usage, EKU) Ihres Zertifikats die Serverauthentifizierung enthält. Weitere Informationen:

Programmanforderungen: Microsoft Trusted Root Program

Enthaltene Zertifizierungsstellenzertifikatliste

Wichtig

Direct Routing von Azure Communication Services unterstützt nur TLS 1.2. Stellen Sie sicher, dass Ihre SBCs zur Unterstützung von TLS1.2 konfiguriert sind und eine Verbindung mit einer der folgenden Suites für SIP-Signalisierung mit Verschlüsselungsverfahren herstellen können, um Auswirkungen auf den Dienst zu vermeiden:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 d. h. ECDHE-RSA-AES256-GCM-SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 d. h. ECDHE-RSA-AES128-GCM-SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 d. h. ECDHE-RSA-AES256-SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 d. h. ECDHE-RSA-AES128-SHA256

Für SRTP-Medien wird nur AES_CM_128_HMAC_SHA1_80 unterstützt.

Die SBC-Kopplung funktioniert auf Communication Services-Ressourcenebene. Dies bedeutet, dass Sie viele SBCs mit einer einzelnen Communication Services koppeln können. Dennoch können Sie einen einzelnen SBC nicht mit mehr als einer Communication Services-Ressource koppeln. Für die Kopplung mit unterschiedlichen Ressourcen sind eindeutige SBC-FQDNs erforderlich.

Wenn die Unterstützung für Mutual TLS (MTLS) für die Direct Routing-Verbindung auf dem SBC aktiviert ist, müssen Sie das Baltimore CyberTrust Root und die DigiCert Global Root G2-Zertifikate im SBC Trusted Root Store des TLS-Kontexts für Direct Routing 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 TLS-Zertifikatänderungen für Office.

SIP-Signalisierung: FQDN

Die Verbindungspunkte für das direkte Routing von Communication Services sind die drei folgenden FQDNs:

  • sip.pstnhub.microsoft.com: Globaler FQDN. Muss zuerst verwendet werden. Wenn der SBC eine Anforderung zum Auflösen dieses Namens sendet, wird von den Microsoft Azure DNS-Servern eine IP-Adresse zurückgegeben, 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. Geografisch der zweiten Prioritätsregion zugeordnet.
  • sip3.pstnhub.microsoft.com: Tertiärer FQDN. Geografisch der dritten Prioritätsregion zugeordnet.

Diese drei FQDNs sind in der folgenden Reihenfolge erforderlich:

  • Optimale Erfahrung (weniger Auslastung und am nächsten zum zugewiesenen SBC-Rechenzentrum durch Abfragen des ersten FQDN)
  • Failover, wenn von einem SBC eine Verbindung mit einem Rechenzentrum hergestellt wird, bei dem ein vorübergehendes Problem auftritt. Weitere Informationen finden Sie unter Failovermechanismus für die SIP-Signalisierung.

Die FQDNs („sip.pstnhub.microsoft.com“, „sip2.pstnhub.microsoft.com“ und „sip3.pstnhub.microsoft.com“) werden in eine der folgenden IP-Adressen aufgelöst:

  • 52.112.0.0/14 (IP addresses from 52.112.0.0 to 52.115.255.255)
  • 52.120.0.0/14 (IP addresses from 52.120.0.0 to 52.123.255.255)

Öffnen Sie Firewallports für alle diese IP-Adressbereiche, um ein- und ausgehenden Datenverkehr der Adressen für die Signalisierung zuzulassen.

SIP-Signalisierung: Ports

Verwenden Sie die folgenden Ports für das direkte Routing von Communication Services:

Verkehr Von Beschreibung Quellport Zielport
SIP/TLS SIP-Proxy SBC 1024–65535 Auf dem SBC definiert
SIP/TLS SBC SIP-Proxy Auf dem SBC definiert 5061

Failovermechanismus für die SIP-Signalisierung

Vom SBC wird eine DNS-Abfrage zum Auflösen von „sip.pstnhub.microsoft.com“ gesendet. Das primäre Rechenzentrum wird basierend auf dem SBC-Standort und den Leistungsmetriken des Rechenzentrums ausgewählt. Liegt im primären Rechenzentrum ein Problem vor, wird „sip2.pstnhub.microsoft.com“ verwendet. Dieser FQDN wird zum zweiten zugewiesenen Rechenzentrum aufgelöst. Sollten Rechenzentren in zwei Regionen nicht verfügbar sein (was äußerst selten vorkommt), wird der letzte FQDN (sip3.pstnhub.microsoft.com) verwendet, der die IP-Adresse des tertiären Rechenzentrums ergibt.

Mediendatenverkehr: IP-und Portbereiche

Der Mediendatenverkehr fließt zu und aus einem separaten Dienst, der als Medienprozessor bezeichnet wird. Die IP-Adressbereiche für Mediendatenverkehr sind identisch mit den Bereichen für die Signalisierung:

  • 52.112.0.0/14 (IP addresses from 52.112.0.0 to 52.115.255.255)
  • 52.120.0.0/14 (IP addresses from 52.120.0.0 to 52.123.255.255)

Portbereiche

Die folgende Tabelle enthält die Portbereiche der Medienprozessoren:

Verkehr Von Beschreibung Quellport Zielport
UDP/SRTP Medienprozessor SBC 49152–53247 Auf dem SBC definiert
UDP/SRTP SBC Medienprozessor Auf dem SBC definiert 49152–53247

Hinweis

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

Mediendatenverkehr: Geografie der Medienprozessoren

Medienprozessoren werden in den gleichen Rechenzentren platziert wie SIP-Proxys:

  • NOAM („USA, Süden-Mitte“, zwei in den Rechenzentren der Regionen „USA, Westen“ und „USA, Osten“)
  • Europa (Europa, Westen, Europa, Norden, Schweden, Frankreich, Mitte)
  • Asien (Rechenzentrum der Region „Singapur“)
  • Japan (Rechenzentren in den Regionen „Japan, Osten“ und „Japan, Westen“)
  • Australien (Rechenzentren in den Regionen „Australien, Osten“ und „Australien, Südosten“)
  • LATAM (Brasilien, Süden)
  • Afrika (Südafrika, Norden)

Mediendatenverkehr: Codecs

Abschnitt zwischen SBC und dem Cloudmedienprozessor

Von der Schnittstelle für direktes Azure-Routing für den Abschnitt zwischen dem Session Border Controller und dem Cloudmedienprozessor können folgende Codecs verwendet werden:

  • SILK, G.711, G.722, G.729

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

Abschnitt zwischen der Communication Services Calling SDK-App und dem Cloudmedienprozessor

Für den Abschnitt zwischen dem Cloudmedienprozessor und der Communication Services Calling SDK-App wird G.722 verwendet. Es wird daran gearbeitet, weitere Codecs auf diesem Abschnitt hinzuzufügen.

Unterstützte Session Border Controller (SBCs)

Nächste Schritte

Konzeptionelle Dokumentation

Schnellstarts