Grundlegendes zu Anrufabläufen
Der folgende Abschnitt enthält eine Übersicht über die Anrufabläufe in Azure Communication Services. Signalisierungs- und Medienabläufe hängen von den Typen der Anrufe ab, die von Ihren Benutzern getätigt werden. Beispiele für Anruftypen sind 1:1 VoIP, 1:1 Festnetz und Gruppenanrufe mit einer Mischung aus VoIP- und Festnetzteilnehmern. Lesen Sie den Artikel zu den Anruftypen.
Informationen zu Signalisierungs- und Medienprotokollen
Wenn Sie einen Peer-to-Peer- oder Gruppenanruf tätigen, werden im Hintergrund zwei Protokolle verwendet: HTTPS (REST) für die Signalisierung und SRTP für Medien.
Die Signalisierung zwischen den SDKs oder zwischen SDKs und Communication Services-Signalisierungscontrollern wird per HTTPS REST (TLS) durchgeführt. Azure Communication Services verwendet TLS 1.2. Für Echtzeit-Mediendatenverkehr (Real-Time Media Traffic, RTP) wird das User Datagram-Protokoll (UDP) bevorzugt. Falls die Nutzung von UDP durch Ihre Firewall verhindert wird, wird vom SDK für Medien das Transmission Control-Protokoll (TCP) genutzt.
Wir sehen uns nun die Signalisierungs- und Medienprotokolle in unterschiedlichen Szenarien an.
Anwendungsfälle für Anrufabläufe
Fall 1: VoIP, wobei eine direkte Verbindung zwischen zwei Geräten möglich ist
Bei VoIP- oder Videoanrufen vom Typ 1:1 wird für den Datenverkehr der direkte Pfad bevorzugt. „Direkter Pfad“ bedeutet, dass eine direkte Verbindung hergestellt wird, wenn sich zwei SDKs gegenseitig direkt erreichen können. Dies ist normalerweise möglich, wenn sich zwei SDKs in demselben Subnetz befinden (z. B. im Subnetz 192.168.1.0/24) oder wenn sich die Geräte jeweils im Livezustand in Subnetzen befinden, die sich gegenseitig erkennen können (SDKs in den Subnetzen 10.10.0.0/16 und 192.168.1.0/24 können sich gegenseitig erreichen).
Fall 2: VoIP, wobei keine direkte Verbindung zwischen Geräten möglich ist, dafür aber eine Verbindung zwischen NAT-Geräten
Wenn zwei Geräte in Subnetzen angeordnet sind, die sich nicht erreichen können (z. B. wenn Alice in einem Coffee-Shop und Bob im Homeoffice arbeitet), aber die Verbindung zwischen den NAT-Geräten möglich ist, stellen die clientseitigen SDKs die Konnektivität über die NAT-Geräte her.
Für Alice ist dies die Netzwerkadressenübersetzung (NAT) des Coffee-Shops, und für Bob die NAT im Homeoffice. Das Gerät von Alice sendet die externe Adresse ihrer NAT, und Bob geht genauso vor. Die SDKs erhalten die externen Adressen über einen STUN-Dienst (Session Traversal Utilities for NAT, Sitzungsdurchlauf-Hilfsprogramme für NAT), der von Azure Communication Services kostenlos bereitgestellt wird. Die Logik, mit der der Handshake zwischen Alice und Bob verarbeitet wird, ist in die von Azure Communication Services bereitgestellten SDKs eingebettet. (Sie müssen keine zusätzliche Konfiguration durchführen.)
Fall 3: VoIP, wobei weder eine direkte noch eine NAT-Verbindung möglich ist
Falls sich mindestens eines der beiden Clientgeräte hinter einer symmetrischen NAT befindet, ist ein separater Clouddienst erforderlich, um die Medien zwischen den beiden SDKs zu übertragen. Dieser Dienst wird als TURN (Traversal Using Relays around NAT, Durchlauf mit Signalisierung für NAT) bezeichnet und wird ebenfalls von Communication Services bereitgestellt. Für das Communication Services SDK für Anrufe werden automatisch TURN-Dienste basierend auf den erkannten Netzwerkbedingungen genutzt. TURN-Gebühren sind im Preis des Anrufs enthalten.
Fall 4: Gruppenanrufe per Festnetz (PSTN)
Bei der Signalisierung und den Medien für Festnetzanrufe (PSTN) wird die Telefonieressource von Azure Communication Services genutzt. Diese Ressource ist auch mit anderen Netzbetreibern verbunden.
Der PSTN-Mediendatenverkehr fließt über eine Komponente, die als „Medienprozessor“ bezeichnet wird.
Hinweis
Für diejenigen, die mit der Medienverarbeitung vertraut sind, ist unser Medienprozessor auch ein Back-to-Back-Benutzer-Agent gemäß der Definition in RFC 3261: SIP – Session Initiation Protocol. Dies bedeutet, dass er Codecs übersetzen kann, wenn Aufrufe zwischen Microsoft- und Netzbetreibernetzwerken verarbeitet werden. Der Signalisierungscontroller von Azure Communication Services ist die Implementierung eines SIP-Proxys über den gleichen RFC von Microsoft.
Bei Gruppenanrufen fließen die Medien- und Signalisierungsdaten immer über das Azure Communication Services-Back-End. Die Audio- bzw. Videodaten aller Teilnehmer werden in der Medienprozessor-Komponente gemischt. Alle Mitglieder eines Gruppenanrufs senden ihre Audio- bzw. Videostreams an den Medienprozessor, von dem gemischte Medienstreams zurückgegeben werden.
Als Echtzeit-Standardprotokoll (RTP) für Gruppenanrufe wird das User Datagram-Protokoll (UDP) verwendet.
Hinweis
Der Medienprozessor kann als Einheit für die Steuerung mehrerer Punkte (Multipoint Control Unit, MCU) oder als Einheit für die selektive Weiterleitung (Selective Forwarding Unit, SFU) fungieren.
Falls für das SDK UDP für Medien aufgrund von Firewalleinschränkungen nicht verwendet werden kann, wird versucht, das Transmission Control-Protokoll (TCP) zu nutzen. Beachten Sie, dass für die Medienprozessor-Komponente UDP erforderlich ist. In diesem Fall wird der TURN-Dienst von Communication Services also dem Gruppenanruf hinzugefügt, um TCP in UDP zu übersetzen. TURN-Gebühren sind im Preis des Anrufs enthalten.
Fall 5: Communication Services SDK und Microsoft Teams in einer geplanten Teams-Besprechung
Die Signalisierung wird über den Signalisierungscontroller abgewickelt. Medien durchlaufen den Medienprozessor. Signalisierungscontroller und Medienprozessor werden von Communication Services und Microsoft Teams gemeinsam genutzt.
Fall 6: Frühe Medien
Dies bezeichnet Medien (z. B. Audio und Video), die ausgetauscht werden, bevor eine bestimmte Sitzung vom aufgerufenen Benutzer akzeptiert wird. Wenn es einen frühen Mediendatenstrom gibt, muss der SBC an den ersten Endpunkt anschließen, der Streamingmedien startet. Der Mediendatenstrom kann beginnen, bevor Kandidaten nominiert werden. Der SBC sollte während dieser Phase Unterstützung für das Senden von DTMF haben, um IVR-/Voicemailszenarien zu aktivieren. Der SBC sollte den Pfad mit der höchsten Priorität verwenden, auf dem er Prüfungen erhalten hat, wenn die Nominierungen noch nicht abgeschlossen wurden.
Nächste Schritte
Die Artikel zu den folgenden Themen könnten Sie auch interessieren: