Moving WebRTC Into Your Network Through the Front Door

As part of my work with WebRTC, I get a chance to speak to different types of companies about their WebRTC plans. When speaking with companies that have existing VoIP products and services, the conversation usually moves to how WebRTC should be added to their offering, what the additional service benefits are and how to architect the solution. The typical requirement is to leave the existing deployment untouched and bridge WebRTC into the existing network through some sort of a GW. Where should the logical function of the GW be located and what should the network architecture look like are usually the questions debated. To answer them, I decided to write this post.Moving WebRTC Into Your Network Through the Front Door

To demonstrate the consideration points and options, I will use an example of a contact center. For the sake of this example, let’s take a contact center that has both PSTN lines as well as SIP Trunks from a service provider. All traffic inside the contact center is via SIP where some of the agents are working on premise and others are home agents who are “called in” for handling contact center peak traffic.

Architecture Options when Adding WebRTC
In my discussions with customers and partners who are looking to add WebRTC into their existing networks, the architecture alternatives considered were:

1-A dedicated GW
2-Adding a WebRTC interface to their current core server
3-Adding WebRTC through an SBC

Before and After WebRTC

1-Pre WebRTC Contact Center Connectivity

Traffic comes from a service provider over SIP trunks or PSTN
All traffic in the contact center is SIP
Home agents are connected over IP-SIP but this is done in a secured and controlled manner
The contact center core server is placed inside the contact center network. Security is handled by other elements so it is protected from denial of service attacks, call fraud and other security vulnerabilities
Calls are using G.729 or G.711. Transcoding, if required, is handled in the contact center network.

2-After Adding WebRTC

Adding WebRTC into the game creates new requirements and a new type of traffic source. With WebRTC, users browsing the website of the company serviced by the contact center, can call in directly from the browser. Their traffic runs over the Internet directly to the contact center.

WebRTC includes 2 voice codecs: G.711 and Opus. These are the codecs that come within the browser. If the intention is to eliminate the need for download, calls must be initiated using one of these 2 codecs.

Since G.711 is not built for running over the open Internet as it doesn’t include resiliency, it is beneficial to initiate the calls with Opus. The optimal approach would be to run Opus end-to-end from the browser to the agent but in cases where this is not possible, it is best to keep Opus on the open Internet leg and transcode when getting into the contact center network.

The contact center is required to have a “leg” in the public Internet domain.
Quality of service is not managed. Even though in many cases the quality is good, supporting SLA requires the capacity to manage and monitor quality of experience (QoE)
Supporting Opus requires either adding a new intensive computing transcoding function or adding Opus to the agent’s client.