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.


How Personal Can an SBC Get with You?

Understanding SBC User Classification

 [Post is better viewed on the blog Website]

 As I delve more into the nature of the SBC, I uncover additional layers of complexity that the SBC needs to address and solve. This returns me back to one of my earlier posts about the need for an SBC.

Taking a broader view makes me think about the role of standards, or more accurately, where their role ends and where the role of application specific implementation begins. This was taken to the extreme with WebRTC, something I touched upon in a post about WebRTC signaling and whether it should be standard or non-standard.

The reality is that also in “traditional” SIP communication there is a limited scope that standards can encompass. After all, the SBC wasn’t invented as a standard entity but rather as an entity that performs things in a different way than what the standards defined. It succeeded because it worked… it offered a solution for some of the major VoIP deployment roadblocks such as FW/NAT traversal. Real life experience proved that some things better stay in the application level, settling for only standardizing must-have functions, as was done correctly with WebRTC.

In this blog post I want to address one such application level functionality of the SBC. Basically, the question I wanted to answer was – “to what extent does an SBC need to take decisions based on who is the user participating in the session?”. The topic came up in one of my discussions with R&D and I decided that rather than enjoying this information by myself, I would share it on the blog.

To shed some more light on this topic, I turned to Ilan Avner. Ilan is SIP-SBC Group Leader and a VoIP Expert.

Q. To what level does the SBC take decisions based on personal user characteristics?

The identity of the user and the equipment from which he initiated the session are important factors in SBC decision process. There are SBCs that use layer 3 information for this process and don’t extend the analysis to the user level. We found this method of using a pre-defined profile based on IP address mapping to be insufficient for an enterprise environment where IP addresses of devices and users may change. Moreover, even though the analysis of the user and SIP message fields is far more complex, performing what we call “User Classification” is an indispensable part of the SBC decision process.


Q. You talked about the importance of User Classification. Can you shed some light on what exactly User Classification is and how it is used in the SBC decision process?

User Classification is a process in which users are grouped according to an array of parameters. When a SIP session is initiated and arrives at the SBC, on top of layer 3 classification there are 3 fundamental parameters of the session that help in the classification:

  • The type of remote SIP server – IP-PBX, Gateway, SBC, Media Server, Proxy, etc.
  • The device vendor – this is relevant both for clients and servers
  • SIP user information – this is specific information about the user itself, not the device. It can be about the group of which he is part, or about the organization or related policy

Q. What are the SBC use cases of User Classifications and for what type of decisions does the SBC use this information?

Information collected and the resulting classification of the user further helps in SBC decisions such as:

  • Routing and SIP message manipulations
  • SLA Enforcement – Call Admission Control (CAC), QoE, bandwidth management
  • Enforcing security policy
  • Overcoming SIP signaling mismatches (SIP interoperability)
  • Media functionality such as codec transcoding and FAX transcoding

 Q. Can you give some specific examples of how user classification is implemented in the AudioCodes SBC?

The AudioCodes SBC has this classification ability built-in its basic SIP processing. Each dialog request goes through a built-in classification process, the dialog can be classified either by layer 3 parameters or by any SIP layer parameters (using a dedicated classification table), once the SIP traffic is classified the dialog is tagged as belonging to a specific SIP group, this group is then used as an input to all of the dialog processing (Routing, Manipulations, CAC, Security, SIP signaling functionality, Media functionality…).

As part of the classification process our SBC looks at various parts of the SIP message. Here are a few examples:

  • Any SIP URI that appears in the SIP message (Request-URI\TO\FROM\P-Asserted\P-Preferred…)
  • A list of supported codecs and capabilities (e.g. FAX support)
  • Any vendor specific parameter (e.g. user agent or any X-Header)

Illustration of SBV user classification 

In the above diagram we see 4 different types of SIP user agents and the classification parameters each received by the SBC. This is of course an example, the actual classification is more complex and involves additional SIP message fields. The end result of this process is the tagging of each session and users associated with it, thus allowing for different SDP negotiation and SIP message exchange manipulation.

In conclusion

SBCs are required to perform complex decision processes per session and should, therefore, use every piece of information available including user specific data. This logic can’t be part of the standard but rather the application and therefore is part of the differentiation between SBCs available on the market.

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.