WebRTC Gateway

To enable browsers using different application providers to communicate with each other (e.g. a user logged into application providers X wants to call someone that is logged into application provider Y) a so-called WebRTC trapezoid can be used. In this case the two providers use a widely used VoIP signalling protocol such as SIP to federate between them. However, each of their respective browser-based clients signals to its server using proprietary application protocols built on top of HTTP and WebSocket.

This component that mediates between WebRTC and SIP is referred to as a WebRTC Gateway. Beside connecting different WebRTC applications, a WebRTC gateway also enables the communication between a WebRTC phone and a VoIP or even a PSTN phone. Thereby, a WebRTC gateway extends the scope of WebRTC applications and enables much wider reach and usage scenarios.[2]

Example of a WebRTC Trapezoid

The usual process with WebRTC is that a user downloads a WebRTC JavaScript application. This application is then used to communicate with another user. A WebRTC gateway would usually contain the server from where a user would download the WebRTC JavaScript application. When receiving a call from the user, the WebRTC gateway needs to decide whether the callee is reachable over WebRTC. If not, then the call will have to be translated into SIP for example. To translate a call into SIP, the gateway will have to map different layers:

• Signalling: There is no standardised signalling protocol for WebRTC applications. However, SIP over WebSockets (RFC 7118) is often used partially due to the applicability of SIP to most of the envisaged communication scenarios as well as the availability of open source software such as JsSIP. In such a case, the gateway would only need to repackage the SIP packets from the WebSocket layer into UDP, TCP or TLS.
• Media transport: The WebRTC specifications indicate that for security reasons WebRTC applications must use SRTP for transporting media content. While some VoIP applications support SRTP as well, this is optional and hence not always the case. If the callee does not support SRTP then the WebRTC gateway will have to map between SRTP and RTP.
• Media content: The WebRTC specifications indicate that WebRTC applications must use for audio communication either G.711 or OPUS as the Audio codec. Applications using SIP for establishing audio session are free to choose any type of codec. If the callee does not support OPUS or G.711 then the WebRTC gateway will have to transcode between the WebRTC and SIP sides of the communication.
• Media address negotiation: In order to be able to traverse all kinds of NAT, the WebRTC specifications indicate that WebRTC applications must use STUN and ICE in order to detect the addresses under which two end points can exchange media packets. While these technologies are also implemented by some SIP user agents, this is not mandatory. If the callee does not support ICE or in case media transport layer needs mapping or media transcoding is required then the WebRTC gateway will have to act as an ICE end point and route the media packets between the caller and callee.

WebRTC to SIP mapping

There are already a number of open source and commercial solutions available for providing the WebRTC gateway functionality. As a lot of required functionality of a WebRTC gateway such as media handling, signalling mapping is supported by SBC the function of WebRTC gateway is often integrated into SBCs or provided by SBC vendors.