Seesaw

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.

Seesaw

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.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

Captcha *