[Post is better viewed on the blog Website]
An Island – All communications of the service run within the closed network of the provider of the service. An Island deployment can use any proprietary technology it wishes and can change behaviour between versions without the need to worry about backwards compatibility as long as it doesn’t change the interfaces with which users/developers interact.
Open – The provider of the service doesn’t control all the components and therefore, must stick to standard protocols. By way of illustration, think of connecting a home user from the browser to an enterprise SIP network or a service provider’s voice network.
Now enough with theory and let’s look at reality.
- In reality, some Islands need to be connected to the external world.
- In reality, most of those “Open” deployments require an alignment between vendors and server components to connect between them, AKA SBC.
Why is this important?
When looking at WebRTC in the context of existing communications and networks, there is no point or need to reinvent the wheel. That said, in cases where there is a need to bridge WebRTC into existing telephony networks (say SIP), WebRTC should be added as an interface to the existing connection point.
Looking at some of the ways WebRTC GWs are being designed today, we can see that many vendors have taken the route of adding WebRTC through an external box as illustrated below.
One might say that the WebRTC GW is all that is required but there are many reasons why eventually such deployments end up requiring an SBC in the architecture. These reasons may include: Security, SIP Trunk and SIP networks interoperability, QoS and regulatory compliance.
What is the down side of a two box solution?
In addition to the obvious need to manage and maintain two boxes or SW components, there are also technological downside factors to this type of architecture.
In this architecture, each of the two components will take care of different functionalities – the GW will provide the WebRTC specific functionalities while the SBC will handle the generic SIP functionalities as well as the per vendor/network functionalities.
The GW functionality
GW functionality includes:
- Terminate WebSockets and any other proprietary/standard signaling used on the WebRTC leg
- Terminate DTLS
- Handle ICE functionality
- Handle RTP multiplexing as in WebRTC all RTP and RTCP streams are sent on the use port
- Support for Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF)
The SBC functionality
SBC functionality includes:
- Support for enhanced SIP features such as class 5 features, music on hold and forking
- Support for vendor specific functionality and call signaling.
Putting it all together
Due to the nature of functionality supported by each one of these components, both signaling and media need to flow through them both. This presents a significant challenge to the architecture as it increases complexity and media delay.
What is the alternative architecture?
Similar to other interfaces and vendor specific functionalities supported by an SBC, WebRTC can be included within the SBC itself. By taking this approach and allowing for dynamically turning on and off this functionality, you avoid the problematic issues addressed above.
Have you deployed or are you looking to deploy a WebRTC GW? Which of the approaches do you find most fits your needs?