Detailliertes WebRTC-Diagramm
Legende
Klicken Sie auf die Zahlen unten, um zu erfahren, was in den einzelnen Phasen geschieht.
|
![]() |
![]() |
Für die gesamte WebRTC-Signalisierung wird ein Websocket eingerichtet. Die Verbindung wird einmal erstellt und für alle nachfolgenden Nachrichten wiederverwendet. Für den eingehenden Low wird keine neue Verbindung erstellt, so dass für den Aufbau einer eingehenden Verbindung kein Netzzugang erforderlich ist. |
![]() |
Wenn ein Anruf eingeleitet wird, sendet der Cloud Media Service oder der Premises Edge zusammen mit dem WebRTC-Client Anfragen an die Genesys- und Google STUN-Server. Es wird der Server verwendet, der zuerst antwortet. Diese Redundanz stellt sicher, dass es zu keiner Dienstunterbrechung kommt. |
![]() |
Ein symmetrisches NAT arbeitet nicht mit dem STUN-Prozess zusammen, da eine neue Übersetzung für den Medienfluss erstellt wird. Dadurch kann der direkte Medienpfad nicht fortgesetzt werden, was dazu führt, dass ein TURN-Kanal für den Medienfluss verwendet wird. |
![]() |
Der Client empfängt Kandidaten von seinem Peer und sendet eine Binding-Anfrage zur Überprüfung der Konnektivität. Die Binding-Antwort wird verwendet, um die Verbindung zu validieren und zu bestätigen, dass der erwartete Pfad verwendet wurde. Wenn der Client eine andere NAT-Adresse zur Kontaktaufnahme mit dem Medienendpunkt verwendet als zur Kontaktaufnahme mit dem STUN-Server, wird dies erkannt und ein neuer reflexiver Peer-Kandidat erzeugt. |
![]() |
Es ist nur ein SRTP-Medienpfad erforderlich. Ein direkter Medienpfad kann zwischen realen IP-Adressen (BYOC Premise) oder mit NAT-reflexiven IP-Adressen (BYOC Cloud) eingerichtet werden. Wenn ein direkter Medienpfad nicht zugänglich ist, kann ein TURNs-Kanal verwendet werden, um den Netzwerkzugang oder NAT-Probleme zu umgehen. |