Anforderungen an die Azure Direct Routing-Infrastruktur

In diesem Artikel werden Infrastruktur-, Lizenzierungs- und SBC-Konnektivitätsdetails (Session Border Controller) beschrieben, die Sie berücksichtigen möchten, wenn Sie Ihre Azure Direct Routing-Bereitstellung planen.

Infrastrukturanforderungen

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

SBC-Zertifikate und Domänennamen

Microsoft empfiehlt, das Zertifikat für den SBC durch eine Zertifizierungssignaturanforderung (CSR) anzufordern. Spezifische Anweisungen zum Generieren einer CSR für einen SBC finden Sie in den Verbindungsanweisungen oder Dokumentationen Ihrer SBC-Anbieter.

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 sollte direkt von einer Zertifizierungsstelle ausgestellt werden, nicht von einem Zwischenanbieter.

Alternativ unterstützt das direkte Routing von Kommunikationsdiensten ein Wildcard im CN und/oder SAN, und das Wildcard muss dem Standard RFC HTTP Over TLS entsprechen.

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

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

Kommunikationsdienste vertrauen nur Zertifikaten, die von Zertifizierungsstellen (Certificate Authorities, CAs) signiert sind, die Teil des Microsoft Trusted Root Certificate Program sind. Stellen Sie sicher, dass Ihr SBC-Zertifikat von einer Zertifizierungsstelle signiert ist, die Teil des Programms ist, und dass die Erweiterung für die erweiterte Schlüsselverwendung (Extended Key Usage, EKU) Ihres Zertifikats die Serverauthentifizierung umfasst. Weitere Informationen:

Programmanforderungen – Microsoft Trusted Root Program

Liste der enthaltenen CA-Zertifikate

Die SBC-Kopplung funktioniert auf der Ebene der Kommunikationsdienste-Ressourcen. Dies bedeutet, dass Sie viele SBCs mit einer einzelnen Communication Services-Ressource 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 Teams-Verbindung auf dem SBC aktiviert ist, müssen Sie alle Zertifizierungsstellen, die im Abschnitt „Stammzertifizierungsstellen“ auf der Seite mit den Azure-Zertifizierungsstellendetails aufgeführt sind, im vertrauenswürdigen Stammzertifizierungsstellenspeicher des Teams-TLS-Kontexts auf dem SBC installieren. (Dies liegt daran, dass die Microsoft-Dienstzertifikate diese Stammzertifikate verwenden). Informationen zum Herunterladen der Stammzertifikate finden Sie unter Microsoft 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 Kommunikationsdiensten sind die folgenden drei FQDNs:

• sip.pstnhub.microsoft.com – globaler FQDN – muss zuerst ausprobiert 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 – ist geografisch der zweiten Prioritätsregion zugeordnet.
• sip3.pstnhub.microsoft.com — Tertiärer FQDN — ist 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.122.0.0/15 (IP addresses from 52.122.0.0 to 52.123.255.255)

Öffnen Sie Firewallports für alle diese IP-Adressbereiche, um eingehenden und ausgehenden Datenverkehr zu und von den Adressen für die Signalisierung zuzulassen.

SIP-Signalisierung: Ports

Verwenden Sie die folgenden Ports für das direkte Routing von Kommunikationsdiensten in Azure:

Failovermechanismus für SIP-Signalisierung

Der SBC erstellt eine DNS-Abfrage, um sip.pstnhub.microsoft.com aufzulösen. 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 von einem separaten Dienst namens "Medienprozessor". Die IP-Adressbereiche für den Mediendatenverkehr sind identisch mit der 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 Portbereiche der Medienprozessoren sind in der folgenden Tabelle dargestellt:

Mediendatenverkehr: Geografie von Medienprozessoren

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

• NOAM („USA, Süden-Mitte“, zwei in den Rechenzentren der Regionen „USA, Westen“ und „USA, Osten“)
• Europa (EU West, EU Nord, Schweden, Frankreich Zentral)
• 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 Nord)

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. Die Arbeit am Hinzufügen weiterer Codecs in diesem Abschnitt ist im Gange.

Unterstützte Session Border Controller (SBCs)

• Für das direkte Routing von Azure Communication Services zertifizierte Session Border Controller

Nächste Schritte

Konzeptionelle Dokumentation

• Telefoniekonzept
• Telefonnummerntypen in Azure Communication Services
• Koppeln des Session Border Controllers und Konfigurieren des Sprachroutings
• Übersicht über die Anrufautomatisierung
• Preise

Schnellstart

• Abrufen einer Telefonnummer
• Ausgehender Anruf an eine Telefonnummer
• Umleiten eingehender Telefonanrufe mit der Anrufautomatisierung