Detailed WebRTC diagram
Legend
| The Genesys Cloud Desktop Application and the Collaborate web user interface are client applications for accessing Genesys Cloud and the WebRTC station. | |
| Genesys Cloud is a collection of cloud based services enabling contact center and business user communication | |
| BYOC Premise relocates VoIP components to on premise, but the station works the same. | |
| Google Voice STUN Servers are used as a third-party option. |
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. |
[NEXT] Was this article helpful?
Get user feedback about articles.