You are here›Research Topics›Context aware communication›Blog›WebRTC Interworking with Traditional Telephony Services
WebRTC Interworking with Traditional Telephony Services
Previously, we demonstrated how WebRTC can be used to create web apps for real-time communication and conferencing, all of which were running between our WebRTC browser or WebRTC iOS runtime. In parallel, we have been working on how WebRTC can be used to connect to existing telephony services, enabling native calling directly from a webpage.
Interworking between a WebRTC enabled browser and MMTel devices
In order for a web app to communicate with MMTel conformant devices, it requires translating both the signaling and the media between the WebRTC formats and the MMTel ones. The former uses a potentially semi-proprietary signaling, running over some combination of HTTP and/or WebSockets, while the latter uses SIP signaling directly. In addition, the web app uses unidirectional media streams, whereas the MMTel expectation is to receive bi-directional streams. These differing requirements need someone to mediate signaling and media.
In our solution, we have three components that provide the necessary functionality. An ICE lite server, a signaling gateway and a media relay. The ICE lite server provides the reflexive IP addresses that the WebRTC implementation needs; the signaling gateway converts the webapp's communication into SIP/IMS signaling and the media relay converts the WebRTC media framing into the MMTel conformant representation.
Once the web app has retrieved its reflexive addresses using ICE-lite, it will contact the signaling gateway using HTTP and create a WebSocket connection. The app will then register itself to the core IMS network via the signaling gateway. The registration procedure might (and usually does) include authentication of the app. The signaling between the web app, the signaling gateway, and the IMS system is illustrated in the figure below.
A session is established so that the web app sends an initial INVITE, including an SDP offer for the "outgoing" stream, to the gateway. The signaling gateway will reserve the resources from the media relay, which will then make an educated guess about whether a stream for the "other" direction is needed, too. Consequently, the signaling gateway will initially send an SDP answer to the initial INVITE and create an SDP offer of its own. This SDP offer is carried in a SIP UPDATE. Once the media between the web app and media relay is sorted out, the session will progress towards IMS and will be handled like any other session. At this point, the media relay has mapped two unidirectional "web app streams" into one bidirectional "IMS stream" and will forward all media between the two. The mapping is done for both audio and video streams, meaning that we are able to support both audio and video calls between WebRTC and MMTel clients and conferences.
The WebRTC-MMTel interoperability is the first part of the demonstration video below.
WebRTC and PSTN Interoperability
When one has created the WebRTC and MMTel interoperability mentioned above, PSTN interoperability is very simple. It is simply a matter of routing the call to a PSTN gateway, enabling us to call a regular phone. This is the second part of the video clip.
Use of DTMF in WebRTC
Our current WebRTC implementation has no direct support for Dual-Tone Multi-Frequency (DTMF) tones sent on the audio stream. Instead, the DTMF signals are sent on the session control channel using the SIP INFO method. In the video, we demonstrate sending DTMF signals from a web client to a conference service.
In this blog post, we have shown how a web app utilizing the W3C WebRTC API can interoperate with existing telephony services. We believe that such interoperability will be a key success factor for WebRTC-based web telephony.
– Nicklas Sandgren, Tomas Mecklin, and Jouni Mäenpää