Detailed WebRTC diagram
Legend
Click the numbers below to learn about what happens at each stage.
|
![]() |
![]() |
A websocket is established for all WebRTC signaling. The connection is created once and reused for all subsequent messages. A new connection is not created for the inbound low, so network access is not needed to establish an inbound connection. |
![]() |
When a call is initiated, the Cloud Media Service or the Premises Edge along with the WebRTC Client sends requests to both the Genesys and Google STUN servers. The server that responds first will be used. This redundancy ensures no disruption to service occurs. |
![]() |
A symmetric NAT will not cooperate with the STUN process because a new translation will be created for the media flow. This will not allow the direct media path to proceed, which will result in using a TURN channel for the media flow. |
![]() |
The client receives candidates from its peer and sends a Binding request as a connectivity check. The Binding response is used to validate the connection and confirm the expected path was used. If the client uses a different NAT address to contact the media endpoint than it used to contact the STUN server, that will be discovered, and a new peer reflexive candidate will be produced. |
![]() |
Only one SRTP media path is required. A direct media path can be established between real IP addresses (BYOC Premise) or with NAT reflexive IP addresses (BYOC Cloud) If a direct media path is not accessible, then a TURNs channel can be used to work around network access or NAT issues. |