In Voice over IP and mobile wireless networks, there are often differences in the way that voice is coded. Different styles of networks use different voice codings (often called codecs) and a wide diversity of these codecs are in use. It's not just an issue for voice; video, fax and tones can also be coded differently depending upon the network or standards that are in use.
When there are differences in the way that voice or other media types are encoded, decisions need to be made so that a call or session can successfully run over the entire network that is being traversed. The same situation can come into play when a customer interacts with a service such as voice mail or conferencing; somehow, the voice or video coding needs to be processed so that the application can handle it. In today's networks, transcoding is used when there are differences between codecs in an end to end call or when using a voice or multimedia based service.
Traditionally, gateways have been used to reconcile codecs when crossing from a circuit-switched to IP network, but many of today's calls and sessions are running over an all-IP network. You might think that all of those IP networks would use the same voice codecs, but the problem of having many ways to code voice still persists. In these cases, session border controllers (SBCs) can be utilized to reconcile the media by transcoding one voice or multimedia coding to another, so that the end to end session works successfully and there is reasonable quality on both ends of the session. In the early days of SBCs, they handled interworking between different protocols such as SIP and H.323, but transcoding required a different device. More recently, SBCs have added banks of Digital Signal Processors (DSPs) in order to be able to support SBC sessions with transcoding.
Okay. Now we're talking. Simply add a bank of DSPs onto an SBC chassis and voila, we can transcode any call we want. Alas, the truth is somewhat more complicated than that. Like the chips used on personal computers, DSPs have evolved to support more channels and faster processing over time, which offers great value to customers that want lots of processing power in compact, cool packaging. Good. But on an SBC, the DSPs are used in conjunction with the other processors on the system in order to provide many services at an IP network border, such as protocol translation, denial of service (DoS) protection and possibly encryption. All of these services place loads on the system, which means the nice new bank of DSPs you just ordered on the SBC might never get used up to full capacity.
Let's consider an example. Suppose you have just ordered an SBC which has enough DSP capacity to transcode 2000 sessions. Will you ever actually see 2000 simultaneous transcoding sessions processed on this system? Perhaps not. Very often, the transcoding capacity of an SBC is limited by the number of Calls Per Second (sometimes called Sessions Per Second) or CPS (SPS) that can be supported by the SBC's CPU processor. Since this discussion is about SBCs, we'll use the SPS or Sessions Per Second terminology for the rest of this post. If the network application demands a high number of sessions per second, the SBC will only be able to handle that number of simultaneous sessions before it starts rejecting calls. This SPS threshold might be considerably less than the number of transcoding sessions that could be handled by the DSPs in the system, hence the extra DSP capacity is wasted. In our example, if the Sessions Per Second supported by the SBC is 75 SPS and the average hold time is 12 seconds, the number of simultaneous transcoding sessions which can be handled by a single SBC if we want to have 999 out of 1000 sessions answered is about 994. In this case, roughly half of the DSP capacity on the SBC with a 2000 transcoding session capacity is unusable for this particular call model. (If you want to try this formula out for yourself, check out this neat Erlang calculator).
If you are a potential customer for an SBC, what are the implications? First, it's important to know how much traffic your network or application is expecting, taking into account the number of sessions per second, an average hold time for the sessions and the desired number of sessions to be handled during peak times. Some applications have very short hold times and this can greatly reduce the effective capacity of an SBC. For example, voice mail systems in some countries have very short average hold times - as little as 6 seconds - due to the "slam down" effect when callers choose not to leave messages. Once the session model is understood, the session metrics can be used to size the SBC. You'll want to check with your vendor and find out how many sessions per second they support and how that varies based on hold times. You'll also want to see if the addition of transcoding has an impact on the number of sessions supported. Once you have this information, you can determine how big an SBC you need and what kind of sessions per second support is needed per SBC.
Dialogic has been working on voice and related technologies such as video for many years, so we understand voice and multimedia call models and how to size an SBC so that it meets customer expectations. For more information on our SBCs with multimedia transcoding capabilities, check out the web page for the Dialogic® BorderNetTM 2020 Session Border Controller.
08-27-2012 1:55 PM
Dialogic, the Network Fuel™ company, inspires the world’s leading service providers and application developers to elevate the performance of media-rich communications across the most advanced networks. We boost the reliability of any-to-any network connections, supercharge the impact of applications and amplify the capacity of congested networks. Forty-eight of the world’s top 50 mobile operators and nearly 3,000 application developers rely on Dialogic to redefine the possible and exceed user expectations.