SIP based Contact Center

Migrating to a SIP Contact Center

With every year, SIP is becoming more and more common in unified communication solutions in general, and contact center applications in particular, as companies increasingly recognize the benefits that an all-SIP environment can provide. Legacy contact centers have become expensive to maintain and upgrade and harder to integrate with new and high-value applications. Companies with limited in-house resources can especially benefit from SIP which can support a more dispersed work force including home agents or those working from remote locations.

The SIP based contact center allows companies to leverage new capabilities without pouring more resources into management or IT, infrastructure and applications. These capabilities can be deployed quickly, they are easy to deliver to remote agents and as the companies grow, the solutions can grow with them.

SIP based Contact Center

For many organizations, SIP is an integral part of an upgrade, while for others, SIP is part of a telecom cost reduction strategy.

Consider the following migration paths and best practices:

Step 1: Disconnect the PBX from Contact Center trunks

By disconnecting trunks from the PBX, calls can go directly into the contact center, enabling the introduction of new features not supported by the PBX. Data centers can be centralized, routing calls to dispersed contact centers and sending calls to agents that may be company-based, remotely-based or home-based.

Step 2: Computer Telephony Integration (CTI) Migration

Moving to SIP removes some major pain points that have limited contact center efficiency improvements in the past. In particular, it removes the dependency on the PBX. With traditional PBXs, the link between the PBX and the contact center is via a proprietary CTI link. If the CTI link does not support a certain function or does not provide the data necessary for a specific operation, nothing can be done to overcome the limitation. However, in a SIP environment the flexibility is significantly increased because calls can be directed to the contact center application directly.

Step 3: SIP trunking

Consolidation of telephony trunks into SIP trunks saves a considerable amount of money and is far more flexible and scalable. In addition to the estimated cost savings that can be achieved by using VoIP calls, SIP offers the ability to introduce a whole range of additional services to make the customer service operation more effective, ranging from high definition voice to video and more. Contact centers can save considerable expenses by cutting back on toll-free numbers, as VoIP enables click-to-call, which customers can initiate from their PCs or smartphones. Also, with domestic calling being free, VoIP provides another option for agents to make outbound calls to customers, allowing them to be more responsive or even proactive. In terms of enhancing the customer experience, SIP trunking also enables HD audio, providing a high quality call which can be a real differentiator for many companies.

The Key: Seamless Migration

A seamless migration from legacy infrastructures to SIP is key for organizations making the move, many of which are deeply invested in their legacy equipment. In moving to a SIP-based contact center, there is no need for “rip-and-replace” or discarding earlier investments. Customers can choose to convert to this architecture at their own pace and the SIP solution can grow in line with business needs.

Of course, an open architecture like SIP does have some pitfalls: there is no guarantee that two SIP devices will seamlessly operate together out of the box. Basic functions will work but enhanced functions may need to be tested first. AudioCodes provides a complete end-to-end solution consisting of gateways, SBCs, IP phones and other devices that have already been extensively tested and documented in the contact center environment to ensure full functionality out of the box, considerably reducing risk and professional service requirements in a SIP installation.

TCO Reduction

Ultimately, the result of the move to SIP is a significant reduction of TCO.  This is reflected in the considerable savings generated by a reduction of infrastructure costs including the consolidation of telephony trunking and the elimination of separate infrastructure at each location. By virtualizing the resources through the provision of centralized administration, enterprise-wide resources are better put to use, and the company benefits from the flexibility to support multi-channel interactions with customers and a distributed contact center structure which can consist of multiple sites, home agents and hosted services. Additionally, SIP future proofs new media and applications. All this leads to increased agent satisfaction and a better customer experience which also saves costs.

See what AudioCodes has to offer for your Contact Center.

the whole is greater than the sum of its parts

WebRTC Connectivity Solution with Focus on Quality and Scale

The whole is greater than the sum of its parts

the whole is greater than the sum of its partsWe released a PR today about the AudioCodes WebRTC Connectivity Solution. In this post, I want to provide a technical insight into this solution, explaining why the whole is greater than the sum of its parts.

A typical approach to connecting WebRTC with an existing enterprise VoIP network would follow one of these two architectural concepts:

  • Browser using Opus with some kind of proprietary signaling-> WebRTC to SIP GW -> SBC -> Transcoding to G.7xx -> IP Phone on a SIP network
  • Browser using G.711 with some kind of proprietary signaling-> WebRTC to SIP GW -> SBC -> [Optional: Transcoding from G.711 to G.7xx]-> IP Phone on a SIP network

Both cases introduce some issues

The external WebRTC to SIP GW carries a price.

Transcoding from Opus to G.7xx is something you would want to avoid unless there is no other option. Opus requires hefty CPU resources (much more than most audio codecs) and introduces quality issues while increasing CAPEX.

The other alternative, using G.711 over the open internet, is not a good option as G.711 wasn’t built for sustaining quality over unmanaged networks.

Traffic traverses between networks and different network types (WiFi, Wireline Ethernet, public Internet and enterprise networks) while devices themselves can vary as well. Handling of network impairments should be done in the entity that connects between these networks as it is familiar with the requirements of each and has the per-session knowledge of source and destination of traffic. While the two links above use VoLTE as an example in the post, similar issues arise when traversing WebRTC to non-WebRTC networks and the algorithms described in these posts serve the need of this architecture as well.

Another missing piece in typical deployments is the ability to monitor the traffic, know what is happening on the network and impact SBC decisions for quality improvements.

Putting quality and scale at the front

The solution announced was designed with these two factors at the forefront and that is what makes it stick-out of the crowd.

Integrated solution

In our solution, WebRTC is supported in the SBC itself. This includes WebSockets, DTLS and other WebRTC “special” behavior. This architecture simplifies deployment and management as well as reduces delay, (or in other words, increases quality).

Minimal transcoding scenarios

By supporting Opus in the AudioCodes IP Phone, we hold the rope at both ends. On the one hand, voice over the open Internet is using the Opus codec which is purposely built for this task. On the other hand, transcoding is not required as the IP Phone also supports Opus. This significantly increases the number of calls supported while reducing CAPEX.


For signaling we use SIP over WebSockets. We found this to be a good solution when the goal is to connect to existing networks.

Another advantage of the decision to use SIP for signaling is the connection to WebRTC API platforms. WebRTC API platforms typically use proprietary signaling. For connecting to existing networks they build an adaptor which is typically SIP. This basic SIP implementation can’t connect to any existing enterprise SIP network but going through the SBC allows it to do so. While this SIP adaptor varies and is not always pure WebRTC over WebSockets, eliminating the need for this adaptor to implement a full WebRTC to SIP GW, simplifies this interconnection making this task easier.

Voice quality enhancement

As mentioned, traffic traversing between networks typically suffer from call quality degradation. There are different implementations of media engines on the client side that are optimized for the network with which the client plans to work. When the client connects with another client on a network that it wasn’t built to connect with, voice call quality issues increase. Having the SBC as a demarcation point between the networks allows for the utilization of the AudioCodes voice enhancement algorithms for improving audio quality.

Detect & correct

The AudioCodes Session Experience Management (SEM) not only monitors and detects voice call quality issues, it also works in harmony with the SBC to allow for smart, quality based, routing and quality improvements.

Why is this important?

A WebRTC GW doesn’t stand by itself; it needs a multitude of capabilities and supporting elements to ensure effective and high quality service. This is why the whole is indeed greater than the sum of its parts when bringing all that is required for an end-to-end WebRTC Enterprise connectivity solution.

Garfield & Odie

The NSA is After My Grandmother Secret Lasagna Recipe

Commenter: Hi, can I ask a WebRTC related question?

WebRTC forum moderator: Of course, you are in the right place.Garfield & Odie

Commenter: My name is Garfield.

WebRTC forum moderator: Ahh OK, are you related to the cat?

Commenter: Seriously? When’s the last time a cat asked questions in the WebRTC forum?

WebRTC forum moderator: Good point.  How can I assist you today, Mr. ahh Garfield?

Commenter: I have a problem with a family secret which has been passed down from mouth to ear for centuries.

WebRTC forum moderator: And how is it related to the WebRTC forum?

Commenter: Well, I am quite old and I realized that this is a good time to pass the secret to the next generation. I have been told that WebRTC has the most secured media channel there is. So I thought this would be a good place to do it.

WebRTC forum moderator: If I may ask, how old are you?

Commenter: 15 years old.

WebRTC forum moderator: Excuse me? Ahh. Why don’t you pass your secret to your children?

Commenter: They’re on the other side of the ocean and I am afraid to do it on an international call.

WebRTC forum moderator: Why?

Commenter: Hey, I may be old but I’m not so naive to let the NSA learn about my grandmother’s secret lasagna recipe.

WebRTC forum moderator: I get your point. You heard right about WebRTC. Let me explain: The security mechanism in WebRTC is quite different than other calling systems. WebRTC mandates all media channels voice, video and data using DTLS protocol for security.

The browsers exchange a Datagram Transport Layer Security (DTLS) handshake on every media (voice, video and data) channel. Once these DTLS handshakes are completed, the media is encrypted and begins flowing between the browsers using Secure Real-time Protocol (SRTP).

Other calling systems are using SDES (used by SIP); in SDES the crypto is forwarded in the SDP via the signaling interface and can be used by the servers in the signaling path to decrypt the media.

SDES, which is used more in the SIP world, would help interface more easily to existing SIP-based infrastructure. Although there is consensus that DTLS will be mandatory for WebRTC to support, until two weeks ago, Google Chrome supported both SDES and DTLS. The most recent Chrome version no longer supports SDES. Mozilla Firefox never supported SDED.

In short, when using WebRTC end-to-end, eavesdropping is not an option; your grandmother’s lasagna secret recipe is safe.

Commenter: Many thanks, by the way, what happens if recording is a necessity such as in Contact Centers or where regulation requires it?

WebRTC forum moderator: In such cases, there are a few options. One option is using WebRTC client API for recording, however it’s a local solution.  An organization straight forward approach is to use a WebRTC GW with forking abilities, or a Session Border Controller which supports SIPREC for recording with WebRTC termination capabilities. The SBC then maintains two DTLS call legs toward each party of the call and in the middle; it forks the call to the recording server using a standard SIPREC protocol.

WebRTC Recording with SIP-Rec

Commenter: It’s strange that you are mentioning SBC’s in this context, since a few weeks ago I read in that SBCs are not required in the WebRTC world.

WebRTC forum moderator: That’s true when making a call between two browsers but there will be a need for a border element to be between the WebRTC world and the SIP world, WebRTC GW (SBC), to terminate WebSocket, DTLS, ICE and OPUS transcoding.

Commenter: That’s very intriguing! So do you think it is safe to send Pomodoro Siciliano over the WebRTC data channel too?

WebRTC forum moderator: I would recommend starting moderately with the basil.

Commenter: Meeow…..

WebRTC forum moderator: Oh my……..


Why SBC Signaling and Media are no Longer Tightly Coupled

[Post is better viewed on the blog Website]

Most SBCs, whether enterprise SBCs or core SBCs, are measured and sized by one prime resource – an SBC session.

An SBC session represents a voice call flowing through the SBC and is comprised of a SIP signaling dialog (‘signaling session’) and a media stream.

One would expect that the number of signaling sessions would be equal to the number of media streams, however, the advent of hosted services and unified communications are changing this paradigm.

Imbalance between signaling and media sessions

On a typical SIP trunk service, each call consists of both signaling and media, nevertheless, on hosted PBX service, this is no longer the case.


Typically, two thirds of the calls that take place in a branch office are on-premise calls. In other words, calls that take place between two workers in the same office. The media streams of these calls, assuming the core SBC supports “local media”, remain internal to the branch. This way the bandwidth consumption and delays involved with sending the media streams to the core network are avoided. What this means is that for every three calls, only one media stream goes to the core vs. three signaling sessions.

Another source of SIP signaling to media imbalance, is non-voice traffic such as presence and instant messaging which are part of unified communications. These services generate substantial SIP signaling traffic but carry no media traffic (at least in the form of RTP streams). Presence and IM services are growing at a rapid pace, far outpacing the growth of voice services. Furthermore, a single change of user’s presence generates multiple signaling messages towards all the users who follow this user’s status.

Similar to the data vs. voice trend, where data traffic surpassed voice traffic in 2009 (according to an Ericsson report from 2009), we are experiencing growth of session signaling vs. media streams.

Why is it important for SBCs?

Being prime network entities that traverse and manipulate signaling sessions and media streams, SBCs must be built to handle this trend. More precisely, SBCs need to be architected in a flexible way to handle un-balanced SIP and media traffic. One way to do this is to separate SBCs that handle signaling from those that handle media. Another way is to dynamically allocate CPU and memory resources of a single server to optimally handle different traffic loads of signaling and media.

Lastly, vendors also need to start pricing their SBCs not just by the number of SBC sessions, but also by SBC resources, such as signaling sessions and media streams. This will provide the customer with a more flexible pricing model allowing him to fine-tune his costs based on his usage profile.


Who Needs an SBC Anyway?

[Post is better viewed on the blog Website]

In the early days of SIP, I was working on VoIP protocol stacks at Radvision. As part my role there I used to attend many of the IETF meetings and SIPit interoperability events. The standards where the holy grail and we were a bit naïve in assuming that everyone would be implementing the standard and nothing but the standard…and networks and products would interconnect easily.

The SBCs Come to life

In those days, almost 15 years ago, new startups that focused on something they called a Session Border Controller (SBC) were coming to life. Later down the road of VoIP deployment, more established companies adopted this concept.

I remember a panel at one of the VON shows in which I came out against this trend. At the end of the day, I said, every single SBC function is handled by the standards. As long as the VoIP community will follow the standards, life will be good and simple.

Reality check

I guess it is needless to say that the world of VoIP is more complex than simply implementing the standard. The reality is that networks and products usually don’t interwork without a special effort to make this interworking possible. There are 2 fundamental reasons for this:

  • Standards are complex, very detailed with multiple options, and many times companies interpret them differently
  • Companies want to add their special secret sauce into their products and sometimes, due to technical or commercial reasons, they implement some of the functionalities in a proprietary manner

Regardless of the reasons this is the reality. The naïve position of the past didn’t pass the reality check of real life.


The business communications angle

VoIP is deployed in many enterprises and service providers’ networks, yet there are still many enterprises and SMBs that are not connected to VoIP services. Taking a closer look at those already using VoIP in the enterprise or receiving such a service from their service providers, we see several common characteristics:

  • Not all branches use the same PBX. This is due to acquisitions or changes along the life of the network that were not implemented across the board
  • A hosted service was added servicing some of the branches, requiring the connecting of the on-premise PBX and phones with the hosted service network
  • A unified communications service such as Microsoft Lync was added in addition to the existing telephony system requiring the connection of the 2 networks together
  • Survivability needs and local PSTN termination require an on-premise “box” to provide these capabilities

Each one of the points above introduces complexity and a mix of standard and proprietary (or as some vendors call it, “SIP like” or “in the spirit of SIP”). As this phenomenon is the reality of today’s business networks, a smart mediation box is required to connect between the different elements and support these requirements.

What is special about the SBC that makes it the “Swiss Army Knife” of VoIP?

An SBC is like a Swiss Army Knife as it handles many functions. It is well aware of the specific environment in which it is deployed and typically has a flexible configuration that allows adapting it to the specific deployment environment. On the other hand, SBCs are also known for complex configuration due to their complex functionality. As such, a configuration wizard that contains various vendor product profiles for automatic and easy configuration of the SBC for specific deployment scenarios comes in handy for simplifying SBC configuration.  

A typical SBC would have the following functions:

Mitigation & connectivity – connect between different PBXs and different hosted services, connectivity with different SIP trunk providers.

Security – detect security threats such as denial of service, call theft and eavesdropping and protect the network from them. The SBC may also perform encryption/decryption functions to force a policy requiring all outbound traffic to be encrypted.

Quality of Service – the SBC monitors call quality, reports on issues and may enhance quality through media manipulation

Routing & policy enforcement– making sure calls routed based on the enterprise policy-based on user identity & privileges, call termination cost, quality requirements and network conditions

Regulatory compliance – route calls to recording services

The list of functions above is a general and non-exhaustive list. Naturally, there are different functionalities required depending on the type of the SBC, be it an access SBC or an enterprise SBC.

In conclusion, if in the past there was a debate about the need for an SBC, today SBCs are found in most deployments, on-premise as well as in hosted services, providing functionalities such as security and resiliency. Moreover, the SBC is included in many of the architectures defined in the standards.

Image credit: Flickr user Hiking Artist


1 Answer to WebRTC Signaling

1 Answer to WebRTC Signaling

[Post is better viewed on the blog Website]

A lot of opinionated information has been written about the debated topic of WebRTC signaling. An example of a good and well-balanced technical post is WebRTC Hacks, written by Victor Pascual.

I am excited to be participating in a panel on this topic next week at WebRTC Global Summit in London and I thought it would be a good idea to provide some points about this topic beforehand. If you happen to be around please come and pay us a visit, we are at booth #6.

What is the debate about?

There are 2 fundamental items the industry is debating about:

  • Should WebRTC define signaling
  • When building a product/service should signaling be based on existing standard or proprietary protocols

The answer to the first question is easy. Since WebRTC was born to serve Web developers, not Telecom VoIP geeks, one would never be able to imagine what WebRTC could be used for. This fact requires taking the “less is more” approach and define only the minimal must, thus, leave signaling out of the WebRTC definition scope and put it in the hands of those building each specific solution.

The second question seems more complex as is testimony to the many opinions out there. Some think proprietary JSON-based signaling is the only answer. Others think standard signaling is the answer pitching to go for SIP or XMPP. Another opinion I enjoyed debating about at the WebRTC 2013 conference in Paris was that WebRTC was “born” for IMS (needless to say I didn’t support that point of view).

1 Answer to WebRTC Signaling

So what is the 1 answer for WebRTC signaling?

If it wasn’t clear to this point, the answer is simply – it depends.

The decision of what signaling to use when building a product or a service depends on its nature and the solution for which it was designed for.

The primary distinction required for deciding if a standard or proprietary approach fits best is whether the solution goes into a service island or if it needs to connect with an existing VoIP network.

In the case of a service island, proprietary signaling will typically be chosen because it is the easy approach, however, if advanced telephony functions, already well defined in standard protocols such as SIP are required, there is no point in reinventing the wheel. It is perfectly OK to pick and choose the functionalities of SIP needed in the implementation and ignore the rest.

On the other hand, if the solution is about allowing WebRTC service to connect with existing standard VoIP networks such as SIP the natural signaling choice would be SIP.

Last but not least, if you are providing an end-to-end solution that includes the WebRTC clients as well as the server, whatever signaling is hidden under the hood doesn’t really interest the developer building the application. What does interest the developer is how simple it is to use your APIs for integrating your client into his product.

It would be interesting to get your comments to this post detailing your view on this subject and how you decided to deal with this matter in your implementation.