Anrufablauf-Topologien

In diesem Artikel werden Die Anrufflusstopologien von Azure Communication Services und details dazu beschrieben, wie der Anrufdatenverkehr verschlüsselt wird. Eine Einführung in Azure Communication Services-Anrufflüsse finden Sie unter "Interne Anrufnetzwerke".

Hintergrund

Netzwerkkonzepte

Bevor Sie Anrufflusstopologien überprüfen, ist es hilfreich, die von diesem Artikel verwendeten Begriffe zu verstehen.

Ein Kundennetzwerk enthält alle von Ihnen verwalteten Netzwerksegmente. Das Kundennetzwerk kann kabelgebundene und drahtlose Netzwerke in Ihrem Büro oder zwischen Büros, Rechenzentren und Internetdienstanbietern umfassen.

Ein Kundennetzwerk verfügt in der Regel über mehrere Netzwerkperimeter mit Firewalls oder Proxyservern, die die Sicherheitsrichtlinien Ihrer Organisation erzwingen. Es wird empfohlen, eine umfassende Netzwerkbewertung durchzuführen, um die optimale Leistung und Qualität Ihrer Kommunikationslösung zu erzielen.

Das Azure Communication Services-Netzwerk ist das Netzwerk, das Azure Communication Services unterstützt. Microsoft verwaltet dieses Netzwerk und verteilt es weltweit mit den Microsoft-eigenen Rechenzentren, die den Endbenutzern am nächsten kommen. Dieses Netzwerk ist für Transportrelay, Medienverarbeitung für Gruppenanrufe und andere Komponenten verantwortlich, die umfassende Medienkommunikation in Echtzeit unterstützen.

Arten von Datenverkehr

Azure Communication Services basiert in erster Linie auf zwei Arten von Datenverkehr: Echtzeitmedien und Signalisierung.

Echtzeitmedien werden über Real-Time Transport Protocol (RTP) übertragen. Dieses Protokoll unterstützt die Übertragung von Audio-, Video- und Bildschirmfreigabedaten. Diese Daten reagieren empfindlich auf Netzwerklatenzprobleme. Obwohl es für Sie möglich ist, Echtzeitmedien mithilfe von TCP oder HTTP zu übertragen, empfehlen wir, dass Sie das User Datagram Protocol (UDP) als Transport-Layer-Protokoll verwenden, um leistungsstarke Endbenutzererfahrungen zu unterstützen. Über RTP übertragene Mediennutzlasten werden über secure RTP (SRTP) gesichert.

Benutzer Ihrer Azure Communication Services-Lösung stellen eine Verbindung mit Ihren Diensten von ihren Clientgeräten her her. Die Signalisierung verarbeitet die Kommunikation zwischen diesen Geräten und Ihren Servern. Beispielsweise unterstützt die Signalisierung zwischen Geräten und Ihrem Dienst die Anrufinitiierung und den Echtzeitchat. Die meisten Signalisierungsdatenverkehre verwenden HTTPS REST. In einigen Szenarien können Sie session Initiation Protocol (SIP) als signalierendes Datenverkehrsprotokoll verwenden. Obwohl diese Art von Datenverkehr weniger empfindlich für latenzempfindlich ist, bietet die Signalisierung mit geringer Latenz eine angenehme Endbenutzererfahrung.

Medienverschlüsselung

Anrufflüsse in Azure Communication Services, die SDK- und Teams-Clients aufrufen, basieren auf dem RFC 8866-Angebot und Antwortmodell des Session Description Protocol (SDP) über HTTPS. Wenn der Angerufene einen eingehenden Anruf akzeptiert, stimmen der Anrufer und der Angerufene den Sitzungsparametern zu.

Mediendatenverkehr wird verschlüsselt und fließt zwischen dem Anrufer und dem Angerufenen über SRTP, einem Profil von RTP, das Vertraulichkeit, Authentifizierung und Replay-Angriffsschutz für RTP-Datenverkehr bietet. In den meisten Fällen wird der Client-zu-Client-Mediendatenverkehr über client-zu-Server-Verbindungssignalisierung ausgehandelt und wird über SRTP verschlüsselt, wenn er direkt vom Client zum Client geht.

Azure Communication Services-Instanzen, die SDK-Clients aufrufen, verwenden Datagram Transport Layer Security (DTLS), um einen Verschlüsselungsschlüssel abzuleiten. Nachdem der DTLS-Handshake abgeschlossen ist, beginnt die Medien mit dem Ablauf dieses DTLS-ausgehandelten Verschlüsselungsschlüssels über SRTP.

Azure Communication Services-Instanzen, die SDK- und Teams-Clients aufrufen, verwenden ein anmeldeinformationsbasiertes Token für den sicheren Zugriff auf Medienrelays über TURN. Mediarelays tauschen das Token über einen tls-gesicherten Kanal (Transport Layer Security) aus.

Mediendatenverkehr zwischen zwei Endpunkten, die an Azure Communication Services-Audio, -Video und -Videofreigabe teilnehmen, verwendet SRTP zum Verschlüsseln des Mediendatenstroms. Kryptografische Schlüssel werden zwischen den beiden Endpunkten über ein Signalprotokoll ausgehandelt, das einen verschlüsselten UDP-/TCP-Kanal verwendet, der ein TLS 1.2 und AES-256 (im GCM-Modus) verwendet.

Prinzipien des Anrufflusses

Es gibt vier allgemeine Prinzipien, die Azure Communication Services-Anrufabläufen zugrunde liegen.

• Der erste Teilnehmer eines Azure Communication Services-Gruppenanrufs bestimmt die Region, in der der Anruf gehostet wird. Es gibt Ausnahmen zu dieser Regel in einigen Topologien, die Sie weiter unten in diesem Artikel finden können.

• Der Medienendpunkt, der zur Unterstützung eines Azure Communication Services-Anrufs verwendet wird, wird basierend auf den Anforderungen der Medienverarbeitung ausgewählt und ist nicht von der Anzahl der Teilnehmer eines Anrufs betroffen.

  Beispielsweise kann ein Punkt-zu-Punkt-Aufruf einen Medienendpunkt in der Cloud verwenden, um Medien zur Transkription oder Aufzeichnung zu verarbeiten. Ein Anruf mit zwei Teilnehmern verwendet möglicherweise keine Medienendpunkte. Gruppenanrufe verwenden einen Medienendpunkt für Misch- und Routingzwecke.

  Dieser Endpunkt wird basierend auf der Region ausgewählt, in der der Anruf gehostet wird. Der von einem Client an den Medienendpunkt gesendete Mediendatenverkehr kann direkt weitergeleitet werden. Oder es kann ein Transportrelay in Azure verwenden, wenn die Firewalleinschränkungen des Kundennetzwerks dies erfordern.

• Der Mediendatenverkehr für Peer-to-Peer-Anrufe nimmt die direkteste Verfügbare Route, vorausgesetzt, der Anruf benötigt keinen Medienendpunkt in der Cloud.

  Die bevorzugte Route führt direkt zum Remote-Peer (Client). Wenn eine direkte Route nicht verfügbar ist, leitet mindestens ein Transportrelay den Datenverkehr weiter. Mediendatenverkehr sollte keine Server durchlaufen, die wie Paket-Shaper oder VPN-Server (Virtual Private Network) fungieren, oder andere Funktionen erfüllen, die die Verarbeitung verzögern und die Endbenutzererfahrung beeinträchtigen können.

• Signalisierung des Datenverkehrs geht immer an den Server, der dem Benutzer am nächsten kommt.

Weitere Informationen zu Medienpfaden finden Sie in der konzeptionellen Dokumentation zu Anrufflüssen.

Anrufabläufe in unterschiedlichen Topologien

Azure Communication Services (Internet)

In diesem Beispiel für die Anrufflusstopologie werden Kunden dargestellt, die Azure Communication Services aus der Cloud ohne lokale Bereitstellung verwenden, z. B. Azure Direct Routing. In dieser Topologie fließen Datenverkehr zu und von Azure Communication Services über das Internet.

Die Richtung der Pfeile im vorherigen Diagramm spiegelt die Richtung der anfänglichen Kommunikation wider, die sich auf die Konnektivität an den Unternehmensperimetern auswirkt. Bei UDP-Medien fließen die ersten Pakete möglicherweise in umgekehrter Richtung, aber diese Pakete werden möglicherweise blockiert, bis Pakete in die andere Richtung fließen.

Flussbeschreibungen

• Ablauf 2: Stellt einen Fluss dar, der von einem Benutzer im Kundennetzwerk im Internet als Teil der Azure Communication Services-Erfahrung des Benutzers initiiert wird. Beispiele für diese Flüsse sind DNS- und Peer-to-Peer-Medienübertragung.
• Flow 2': Stellt einen Fluss dar, der von einem Remotebenutzer für mobile Azure Communication Services mit VPN zum Kundennetzwerk initiiert wird.
• Ablauf 3: Stellt einen Von einem Mobilen Azure Communication Services-Remotebenutzer initiierten Fluss zu Azure Communication Services-Endpunkten dar.
• Ablauf 4: Stellt einen Von einem Benutzer im Kundennetzwerk initiierten Fluss zu Azure Communication Services dar.
• Ablauf 5: Stellt einen Peer-to-Peer-Medienfluss zwischen einem Azure Communication Services-Benutzer und einem anderen innerhalb des Kundennetzwerks dar.
• Ablauf 6: Stellt einen Peer-to-Peer-Medienfluss zwischen einem Mobilen Azure Communication Services-Benutzer und einem anderen Mobilen Azure Communication Services-Benutzer über das Internet dar.

Anwendungsfall: 1:1-Anrufe

Ein 1:1-Anruf bedeutet, dass ein Benutzer direkt einen anderen Benutzer aufruft. Zum Initialisieren des Aufrufs ruft das aufrufende SDK eine Reihe von Kandidaten ab, die aus IP-Adressen und Ports bestehen. Dieser Satz umfasst lokale, relay- und reflexive Kandidaten (die öffentliche IP-Adresse des Clients, wie vom Relay gesehen). Das aufrufende SDK sendet diese Kandidaten an die angerufene Partei. Die angerufene Partei erhält eine ähnliche Gruppe von Kandidaten und sendet sie an den Anrufer.

Das System verwendet STUN-Konnektivitätsüberprüfungsmeldungen, um zu ermitteln, welche Anrufer/aufgerufenen Medienpfade funktionieren, und wählt dann den besten Arbeitspfad aus. Nachdem das System den Verbindungspfad hergestellt hat, führt es einen DTLS-Handshake über die Verbindung aus, um die Sicherheit zu gewährleisten. Nach dem DTLS-Handshake leitet das System SRTP-Schlüssel vom DTLS-Handshake-Prozess ab. Medien (RTP/RTCP-Pakete, die über SRTP gesichert sind) werden dann über das ausgewählte Kandidatenpaar gesendet. Das Transportrelay ist als Teil von Azure Communication Services verfügbar.

Wenn die lokale IP-Adresse und die Portkandidaten oder die reflexiven Kandidaten über Konnektivität verfügen, wird der direkte Pfad zwischen den Clients (oder wenn Sie eine NAT verwenden) für Medien ausgewählt. Falls sich beide Clients im Kundennetzwerk befinden, sollte der direkte Pfad ausgewählt werden. Für diese Auswahl ist eine direkte UDP-Konnektivität innerhalb des Kundennetzwerks erforderlich. Wenn die Clients beide nomadischen Cloudbenutzer sind, verwenden Medien je nach NAT/Firewall möglicherweise direkte Konnektivität.

Wenn ein Client im Kundennetzwerk intern ist und ein Client extern ist (z. B. ein mobiler Cloudbenutzer), ist es unwahrscheinlich, dass die direkte Verbindung zwischen den lokalen oder reflexiven Kandidaten aktiviert wäre. In diesem Fall können Sie eines der Transportrelaykandidaten von beiden Clients verwenden. Der interne Client hat beispielsweise einen Relaykandidaten aus dem Transportrelay in Azure erhalten, und der externe Client muss STUN/RTP/RTCP-Pakete an das Transportrelay senden können. Eine weitere Option besteht darin, dass der interne Client an den Relaykandidaten sendet, der vom mobilen Cloudclient abgerufen wird. Obwohl die UDP-Konnektivität für Medien dringend empfohlen wird, wird TCP unterstützt.

Übergeordnete Schritte

1. Azure Communication Services-Benutzer A löst DEN URL-Domänennamen (DNS) mithilfe von Flow 2 auf.

2. Benutzer A weist mithilfe von Flow 4 einen Medienrelayport auf dem Teams-Transportrelay zu.

3. Benutzer A sendet eine Einladung mit Ice-Kandidaten (Interactive Connectivity Establishment) mithilfe von Flow 4 an Azure Communication Services.

4. Azure Communication Services benachrichtigt Benutzer B mithilfe von Flow 4.

5. Benutzer B weist mithilfe von Flow 4 einen Medienrelayport auf dem Teams-Transportrelay zu.

6. Benutzer B sendet eine Antwort mit ICE-Kandidaten mithilfe von Flow 4, die mithilfe von Flow 4 an Benutzer A weitergeleitet wird.

7. Benutzer A und Benutzer B rufen ICE-Konnektivitätstests auf, und der beste verfügbare Medienpfad wird ausgewählt. Überprüfen Sie die folgenden Diagramme, um verschiedene Anwendungsfälle anzuzeigen.

8. Beide Benutzer senden Telemetrie mithilfe von Flow 4 an Azure Communication Services.

Kundennetzwerk (Intranet)

In Schritt 7 ist Der Peer-to-Peer-Medienfluss 5 ausgewählt.

Diese Medienübertragung ist bidirektional. Die Richtung von Flow 5 gibt an, dass eine Seite die Kommunikation aus einer Konnektivitätsperspektive initiiert. In diesem Fall spielt es keine Rolle, welche Richtung verwendet wird, da sich beide Endpunkte innerhalb des Kundennetzwerks befinden.

Kundennetzwerk an externe Benutzer (vom Teams-Transportrelay weitergeleitete Medien)

In Schritt 7 werden Flow 4 (vom Kundennetzwerk zu Azure Communication Services) und Flow 3 (von einem Mobilen Azure Communication Services-Benutzer zu Azure Communication Services) ausgewählt.

Das Teams-Transportrelay verarbeitet diese Flüsse in Azure.

Diese Medienübertragung ist bidirektional. Die Richtung gibt an, welche Seite die Kommunikation aus einer Konnektivitätsperspektive initiiert. In diesem Fall werden diese Flüsse für Signalisierung und Medien verwendet und verwenden unterschiedliche Transportprotokolle und Adressen.

Kundennetzwerk für externe Benutzer (direkte Medien)

In Schritt 7 wird Flow 2 (vom Kundennetzwerk zum Peer des Clients über das Internet) ausgewählt.

Die Verwendung von direkten Medien mit einem Remotebenutzer mit einem Mobilgerät (keine Vermittlung über Azure) ist optional. Mit anderen Worten, Sie können diesen Pfad blockieren, um einen Medienpfad über ein Transportrelay in Azure zu erzwingen.

Diese Medienübertragung ist bidirektional. Die Richtung von Flow 2 an den mobilen Remotebenutzer gibt an, dass eine Seite die Kommunikation aus Konnektivitätsperspektive initiiert.

VPN-Benutzer zum internen Benutzer (vom Teams-Transportrelay weitergeleitete Medien)

Die Signalisierung zwischen dem VPN an das Kundennetzwerk verwendet Flow 2'. Die Signalisierung zwischen dem Kundennetzwerk und Azure verwendet Flow 4. Medien umgehen jedoch das VPN und werden über Flows 3 und 4 über Azure Media Relay weitergeleitet.

VPN-Benutzer zu internem Benutzer (direkte Medien)

Die Signalisierung zwischen dem VPN an das Kundennetzwerk verwendet Flow 2'. Die Signalisierung zwischen dem Kundennetzwerk und Azure verwendet Flow 4. Medien umgehen jedoch das VPN und werden über Flow 2 vom Kundennetzwerk an das Internet weitergeleitet.

Diese Medienübertragung ist bidirektional. Die Richtung von Flow 2 an den mobilen Remotebenutzer gibt an, dass eine Seite die Kommunikation aus Konnektivitätsperspektive initiiert.

Von VPN-Benutzer zu externem Benutzer (direkte Medien)

Das Signal zwischen dem VPN-Benutzer an das Kundennetzwerk verwendet Flow 2' und Flow 4 für Azure. Medien umgehen jedoch das VPN und werden über Flow 6 weitergeleitet.

Diese Medienübertragung ist bidirektional. Die Richtung von Flow 6 an den mobilen Remotebenutzer gibt an, dass eine Seite die Kommunikation aus Konnektivitätsperspektive initiiert.

Anwendungsfall: Azure Communication Services-Client zu PSTN über einen Azure Communication Services-Trunk

Azure Communication Services ermöglicht das Tätigen und Empfangen von Anrufen aus dem Telefonfestnetz (Public Switched Telephone Network, PSTN). Wenn der PSTN-Trunk über Telefonnummern verbunden ist, die von Azure Communication Services bereitgestellt werden, gibt es keine speziellen Konnektivitätsanforderungen für diesen Anwendungsfall. Wenn Sie Ihren eigenen lokalen PSTN-Trunk mit Azure Communication Services verbinden möchten, können Sie Azure Direct Routing verwenden.

In diesem Fall nutzen Signalisierung und Medien, die vom Kundennetzwerk zu Azure fließen, Flow 4.

Anwendungsfall: Azure Communication Services-Gruppenanrufe

Der Dienst, der Audio-, Video- und Bildschirmfreigabe bereitstellt, ist Teil von Azure Communication Services. Sie verfügt über eine öffentliche IP-Adresse, die sowohl über das Kundennetzwerk als auch über einen nomadischen Cloudclient erreichbar sein muss. Jeder Client und jeder Endpunkt muss eine Verbindung mit dem Dienst herstellen können.

Interne Clients erhalten die lokalen, reflexiven und Relaykandidaten auf die gleiche Weise, wie dies für 1:1-Anrufe beschrieben wurde. Die Clients senden diese Kandidaten in einer Einladung an den Dienst. Der Dienst verwendet kein Relay, da er über eine öffentlich erreichbare IP-Adresse verfügt, sodass er mit seinem lokalen IP-Adresskandidaten antwortet. Der Client und der Dienst überprüfen die Konnektivität auf die gleiche Weise, die für 1:1-Aufrufe beschrieben wird.

Einschränkungen der Interoperabilität

Medien, die über Azure Communication Services fließen, sind wie folgt eingeschränkt:

• Session Border Controller (SBC) eines Drittanbieters: Ein SBC an der Grenze mit PSTN sollte den RTP/RTCP-Stream beenden, über SRTP gesichert und nicht an den nächsten Hop weiterleiten. Wenn Sie den Datenfluss an den nächsten "Hop" weiterleiten, wird er möglicherweise nicht verstanden.

• SIP-Proxyserver von Drittanbietern: Ein SIP-Dialogfeld von Azure Communication Services mit einem SBC und/oder Gateway eines Drittanbieters durchläuft möglicherweise Microsoft-native SIP-Proxys (genau wie Teams). Die Interoperabilität mit SIP-Proxys von Drittanbietern wird nicht unterstützt.

• B2BUA (oder SBC) eines Drittanbieters: Ein SBC eines Drittanbieters beendet diese Azure Communication Services-Medienflüsse zu und von dem PSTN. Die Interoperabilität mit einem Drittanbieter-SBC im Azure Communication Services-Netzwerk (in dem ein SBC eines Drittanbieters zwei Azure Communication Services-Endpunkte vermittelt) wird nicht unterstützt.

Nicht unterstützte Technologien

• VPN: Azure Communication Services unterstützt keine Medienübertragung über VPNs. Wenn Ihre Benutzer VPN-Clients verwenden, sollte der Client den Mediendatenverkehr über eine nicht-VPN-Verbindung teilen und weiterleiten, wie in der Aktivierung von Lync-Medien zum Umgehen eines VPN-Tunnels angegeben.

  Hinweis

  Obwohl der Titel Lync angibt, gilt es für Azure Communication Services und Teams.

• Paket-Shaper: Paket-Snipping-, Paketüberprüfungs- oder Paketformungsgeräte werden nicht unterstützt und können die Qualität erheblich beeinträchtigen.

Nächster Schritt

Verwandte Inhalte

• Weitere Informationen zu Anruftypen.
• Erfahren Sie mehr über die Clientserverarchitektur.