Have you ever got confused about which way to turn when you get to an intersection with over 6 roads coming off it?

Imagine how you’d feel if you were a SIP session arriving at an SBC with over a 1000 different hops to choose from!   This is actually a reasonably common scenario for an interconnect SBC, routing tables can grow to millions of entries that help to select between thousands of possible next hops.

This is a pretty complex problem, but on top of that you need to factor in a large number of different criteria that need to be considered as part of that routing decision. For example:

• Does this call need to be looked up in a number-portability database, particularly for mobile subscribers?
• What’s the lowest cost option for reaching the destination?  Does that vary at different times of day?  Does the lowest cost route have quality problems, or restrictions on what it can carry?
• What services need to be invoked for this call before it is routed onwards?
• Are there multiple options that give equally good service that should be load-balanced? More

Why is it I can play Angry Birds on about 15 different hardware platforms?  We live in a world where Microsoft deploys their software on literally thousands of devices today and I still can’t figure out how to prevent the blue screen of death.  Perhaps the greatest innovation from Apple was not the iPhone but the AppStore.  With the creation of apps for e-mail, Facebook, walking my dog and calling my Grandma I can literally do whatever I normally do in my life with a specific app.  The proliferation of apps means I can download any content on any device.  These trends are common across all industries.  The world values software and hardware has really become a commoditized way to display my content.  Software is literally EATING the world.

If this is a common trend then why can’t I apply those principles to my SBC?  With proprietary media cards to run sessions, cards to encrypt media, and DSPs to transcode between codecs I literally am bound to a specific platform with specific cards.  The SBC industry 10 years ago required these specific types of hardware cards to do functionality that previously was impossible to perform directly on CPU cores. More

Sometimes we, here at #KYSBCS, feel a little like Sprocket the dog. While others believe that their SBC is built on a foundation of solid rock, only we know that under that supposedly unyielding exterior, rambunctious Fraggles are causing mayhem. Oh… Hold on… Sorry… I have just been told that, actually, only one of us feels that way. Anyway, regardless, the point still stands: Since the dawn of time (or IP transport, at least) the reassembly of fragmented IP packets has wreaked havoc on the performance of endpoint equipment – devices responsible for presenting or acting on the data within the payload – including session border controllers.

If their size exceeds the Maximum Transmission Unit (MTU) of a link, larger IP payloads may be fragmented (sliced and diced into smaller packets) as they traverse network infrastructure. While each device might apply its own fragmentation algorithm, the process is quite straightforward: The payload of a large packet is divided into multiple smaller packets, each with duplicate IP header information, but containing a unique subset (portion) of the original data. OK – so there is a little more to it than that. There are fragmentation offsets in the IP header that tell the receiver what part of the packet it is getting and a ‘more fragmentation’ flag that is set from 0 to 1 when more packets should be expected to completely recompile the original payload. More

Wait a minute…What translation? SIP is SIP right? Well in fact, no. Unfortunately, over time, the standard has gone through changes and various interpretations from one vendor to the next, leading to a variety of SIP flavors across a multitude of devices. So where does that leave us, in today’s evolving networks? Well, in every great SIP client / server company, there’s full time interop teams dedicated to the continuous effort of finding – and fixing – any multi-vendor issues that arise from interaction between incompatible devices.

Go on – ask your favorite supplier if they have a team of people doing that!

For every one else? Well, I’m sure you’ve guessed it – that’s where SBCs come in! In additional to its diverse core functions (B2BUA  and network security to name a couple), ‘translation’ is just another area where session border controllers can really shine. Because of their location at the (logical) edge of the network, they are in prime position to fix up any known interop issues in the signalling messages which traverse them. All they need is a powerful and easy-to-use message manipulation framework (MMF) that does not impact the system’s performance when checking and manipulating a high level of messages. Sounds easy, right? Well, many have tried but most have failed. But we, here at #KYSBCS, ask: is that because they are they limited by their platform and architecture? Or is it because they are simply not trying hard enough? Or both! More

In a recent post ‘more than just hearsay‘  we showed how delivering SBCs on commercial-off-the-shelf (COTS) hardware is entirely possible.And indeed you’ll find a COTS option of some sort available today from all good SBC vendors.
What that post didn’t focus on is why you should care? So, here’s why….

1. COTS hardware is cheaper to buy for equivalent performance. No argument here, it’s business 101 that if it costs X to develop a hardware system, then you need to recoup those X costs through sales margins. COTS hardware is sold in far greater volume, so the margin can be kept far lower.
2. Running your SBC on COTS hardware means you can standardize hardware management tools across all your COTS servers. So if you run other applications (e.g.billing) on the same type of COTS server, you’ll only need to integrate the monitoring package once into your management system. Plus you’ll need less training for your operations engineers, since they only have to learn one system.
3. Keep sparing costs down. SBCs need to be reliable, and operators frequently stock spare hardware on site in case of a disaster, so they can restore service quickly. Using COTS hardware means you can save on spares – if you have 10 devices using 10 different types of hardware then you’ll need 10 copies of backup hardware in case any one goes wrong. However if all 10 devices use the same COTS server you can get nearly the same level of protection with just one spare server.
4. Faster hardware refresh cycles. Proprietary hardware will probably only be refreshed every 3-5 years with a significant step up in performance each time. If you’re unlucky you can buy right at the end of the cycle and quickly go obsolete. Whereas COTS servers are refreshed much more frequently, so you can be sure that if your SBC vendor runs on COTS then whenever you buy you’ll be getting a product with a reasonable shelf-life.
5. Better reusability. Even when your SBC hardware does drop off the pace and you need to upgrade, because it’s running on COTS hardware it’s easy to reuse that hardware for other non-critical applications. This isn’t the case with closed, proprietary hardware.

So in summary COTS gives you better Capex, Opex and more flexibility. What’s not to like?

- ojc -

We have mentioned, in one or two posts over the last month or so – like this one – and this one – how session border controllers are increasingly moving from proprietary hardware to general purpose computing platforms. The plain fact is that increasingly cost-effective commercial off the shelf (COTS) servers with powerful multi-core CPUs are now capable of undertaking the packet processing tasks that have, to date, been performed by expensive custom silicon in vendor-specific hardware.

The carrier community has come to this realization and are driving, through the ETSI standards body, their equipment suppliers to deliver on the promise of Network Functions Virtualization, or NFV. Session Border Controllers are ripe for this evolution and we have detailed, in the past, how the most innovative companies in this arena are already along way down this road – forgoing network processors for x86 architectures. But there is more to these proprietary SBCs than just a custom NP.   To quote a recent article:

“One of the challenges of building SBCs is that you need to store flow descriptors for tens of thousands of RTP media flows, and look up the relevant flow descriptor for each and every incoming RTP packet – perhaps as often as 4 or 5 million times a second.  SBCs based on purpose-built hardware typically use a TCAM (ternary content-addressable memory) chip to perform this flow descriptor lookup.  But with 20MB of on-chip cache memory, general-purpose CPUs have both the capacity and the speed to perform flow descriptor look-ups at the required rate.”

Now, that’s not to suggest there isn’t a time and a place for employing a TCAM. Indeed, when developing  ‘big-iron’, such as line-rate 10 Gbps routers, this humble piece of silicon is indispensable.  You see, content addressable memory is pretty slick – primarily because it actually operates in a completely opposite manner to classic memory, in that the application supplies a data word and the CAM returns the address (or addresses) of where that that word can be found. In some implementations, it also returns the word itself. With classic RAM, the application supplies a memory address and the word is returned. More

From codec interworking and SIP normalization to security, the role of a session border controller is primarily to ensure that a voice infrastructure runs smoothly. In some cases, SILKy smooth! While it’s a relatively new addition to the network operator CODEC arsenal, SILK was made famous by its developer – Skype – and is now available as open-source, with the acceptance of Skype’s SILK patent license. As such, many clients now implement SILK as an optional audio compression format.

So what’s so good about SILK? Well, it leverages linear predictive coding (LPC) that provides good quality speech at low bit rates – but nothing unique there – the G.729 also uses a code-excited variant of LPC (CELP). But unlike G.729, SILK is not just a narrowband codec. Indeed, operating at 8kHz, 12kHz, 16kHz and 24kHz sampling rates, SILK is technically defined as a narrowband, mediumband, wideband and superwideband codec. Contrasting its sub-band ADPCM counterpart, G.722 (or AMR-WB), SILK can deliver high-definition voice in excess of even 16kHz.

SILK also features variable bit rate encoding between 6 and 40 kbps. The higher bitrates provide better sound quality, when there is available bandwidth, by reducing quantization distortion. Quantization noise is recognized as the gap between the actual audio level and the fixed point at which it is sampled. More sampling levels mean less of a gap and therefore less distortion.

SILK audio can also be buffered in packets at 20, 40, 60, 80 or 100ms intervals. If the higher encoding delays do not adversely affect overall transmission RTT, larger packets can reduced the effective overhead of the IP header. While there is potentially a more catastrophic effect if a larger packet is dropped or discarded by the intermediate switches and routers, SILK can respond to that with the implementation of an advanced forward error correction (FEC) algorithm.

With the lossy-nature of the 2.4Ghz and 5Ghz unlicensed (Wi-Fi) wireless access points many people use to access telephony services – from devices such as lap tops, tablets and mobile handsets – this FEC attribute is what has set Skype apart from other codecs and why many other unified communications clients are now implementing it. More