Posts

One-Fish-Two-Fish-Red-Fish-Blue-Fish-by-Dr-Seuss

A Mouse has cut the Wire: I can’t hear you…..

 [Post is better viewed on the blog Website]

 

When I was a kid, I loved reading the Dr. Seuss books with the fun and educational rhymes. As an adult, I loved reading them to my own children when they were young. Some things never grow old.

It seems that it is the same with the quality of a phone call. From the early days of the switchboard to calls over the cellular network, the phrase “can you repeat that? I couldn’t hear you” has been commonly heard over the years. And so has the emphasis on improving voice quality accompanied the advances made in telephony communications.

One-Fish-Two-Fish-Red-Fish-Blue-Fish-by-Dr-Seuss

Source: One Fish Two Fish Red Fish Blue Fish, by Dr. Seuss

This is no less true today with Voice over IP (VoIP) networks. Perhaps the greatest enemies of a quality call over VoIP networks are delay, jitter and packet loss. Network experts invest great efforts in fine tuning their networks so as to minimize the negative effects of these factors. In a recent post on this blog entitled “Voice is Coming to LTE”, Amir Zmora pointed out that in his experience in speaking with service providers that are already invested in VoLTE and interconnecting with other networks, it was clear that voice quality and QoE are their main concerns.

VoIP traffic may traverse wireline, WAN, cellular or wireless networks. Wireless traffic in particular is inherently inconsistent and the effects of delay, jitter and packet loss, if not handled, can seriously impair the quality of a call. Wireless networks were designed first and foremost for data applications. But in data focused applications, the most important thing is for the payload to arrive complete, how fast it gets there is less important. Thus, compensating measures can be implemented to guarantee that requirement. However, while these capabilities ensure the arrival of the packets, they also increase delay and jitter. And while delay for data applications is acceptable, in the case of VoIP the delay may be intolerable resulting in someone saying “I didn’t catch that, come again?” or just dropping the call altogether.

As most VoIP entities in the network (session border controllers, gateways, ATAs, IP Phones, mobile clients, etc.) were designed to handle wireline, and not wireless impairments, they have a hard time handling (without help) traffic emanating from wireless networks. To get around the problem, AudioCodes has implemented special built-in tools inside its Session Border Controllers. By placing the SBC with these tools between the wireless network and any other network (wireless, wireline, cellular, etc.), the impairments from the wireless network traffic can be managed and reduced dramatically to allow for an end-to-end quality call and prevent someone from saying, “I cannot hear your call. I cannot hear your call at all!”

Want more information?

Click here to download a White Paper in which you will learn how built-in SBC tools such as an adaptive jitter buffer, transcoding, redundancy, trans rating and quality-based routing can each play a major role in significantly enhancing QoE. Furthermore, when taken together and given the ability to fine tune and balance between the variables, they can be truly powerful.

forcing vendors to enter a cat-and-mouse game

Voice is Coming to LTE

[Post is better viewed on the blog Website]

 Back in 1999, when 3G was still a questionable dream IMS started to take root as an architecture for mobile services. It was adopted by the 3GPP and later on also by 3GPP2 and other organizations and forums. Standardization work went on for many years resulting in continuous releases of standard versions forcing vendors to enter a cat-and-mouse game.

forcing vendors to enter a cat-and-mouse game

The adoption of IMS was slow and disappointing

There are many IMS deployments today but IMS didn’t deliver on its promise. While vendors and service providers were busy fighting in the standard bodies, small start-ups came quickly to the market with advanced services and took the market by storm.

VoLTE is based on IMS and is defined in IR.92 and IR.94. In a nutshell, it defines Voice, SMS over IMS (IR.92) and Video (IR.94) over LTE networks.

So what is all the fuss about VoLTE?

The answer to that lies in the eyes of the beholder.

LTE networks are being deployed by hundreds of service providers worldwide. Once LTE coverage is ubiquitous, there is a lot of sense for the service provider to move away from circuit switched (CS) voice to VoLTE, as in a few years it will eliminate the need to continue supporting the CS network, thereby reducing OPEX.

Additionally, higher quality end-to-end voice will be possible as VoLTE supports HD voice and includes features for resource reservation as well as other important features such as security.

From the end user perspective, in addition to the higher quality voice and security that comes with VoLTE, longer battery life will be possible as the need for dual LTE & CS connectivity of the phone will be removed.

Reality check

Learning from the past, there are 3 fundamental challenges service providers and vendors will need to solve.

Time to market

Service providers have waited for technologies to become stable and for standards to become fully ratified. This stopped them from launching advanced services, leaving the door open for OTTs.

Interoperability

The reality is that service providers currently providing VoLTE services are not all doing so the same way. Different capabilities and scenarios are supported by each service provider. This results in the need to verify each device and server before it is deployed on their network and vendors are required to make modifications in order to pass this certification process. Given this reality, there is a need to have a mediation element (SBC) between service providers, thus interoperability is theoretical… (did I say there is no point in waiting for everything to be perfectly compatible and ready?) Launch…don’t wait.

There are other networks out there

The service provider world is more complex than that of an OTT. The service provider doesn’t have the benefit of building an island. It needs to connect to older networks, enterprise networks and other service providers. This again brings up the need for that demarcation point that will mediate signalling and make sure voice quality between those networks remain good.

Speaking with service providers that are already invested in VoLTE and interconnecting with other networks, voice quality and QoE are their main concerns. Solutions for these concerns are provided through advanced audio processing done in mediation entities that interconnect between the networks.

Stay tuned for more on QoE in future posts on this blog.

Why is this important?

There are different opinions about the future of VoLTE and its chances to succeed. There is no doubt that secured voice calls using HD codecs are possible today using OTT. It is also clear that an OTT will not go this route, but in the service provider space VoLTE looks like a technology that will happen because:

  • It makes sense from an operational cost perspective
  • VoLTE integrates nicely into the service provider’s existing OSS/BSS systems
  • There are ways to downgrade the call to 3G/TDM when LTE is not available…SRVCC

Having said that, interoperability is a challenge. Service providers should assume there will be no 100% interoperability and standard support both on phones and servers. Certification of clients will always be required as well as demarcation points between networks as exist today in their VoIP networks.

Therefore time to market is more important than completing every item on the standards checklist.

REST API for SBC Configuration

Why REST APIs are Not Yet Another SBC Configuration Interface

[Post is better viewed on the blog Website]

REST API for SBC ConfigurationFor most of us who grew up in the telecom industry, management protocols like SNMP, TR-69, and Command Line Interface (CLI) have been for many years the only management protocols we’ve known and used on telecom equipment.

Telecom’s bigger (but younger) brother, the Internet, has developed its own set of management interfaces (APIs), mainly SOAP and REST.

Well guess what? Similar to what happened to some telecom services that were replaced by Web apps (for example SMS replaced by WhatsApp), so are legacy telecom management protocols being replaced by Web management protocols, led by REST.

But REST is more than just another way to manage telecom devices. Being a dominant API in Web technology, REST serves, among other things, as a bridge between Web applications to telecom devices which were previously isolated in their own ‘telecom’ domain.

Linking these two worlds yields new services which were not previously possible.

For example, today an SBC can be connected to a CRM web application (i.e. Salesforce.com) and allow an employee to place a call to his customer by clicking the contact’s name on the CRM web GUI (this may also involve WebRTC).

Some words on how REST works. REST (or RESTfull API as it is sometimes called) is used to manage and read the status of a remote device.  It uses HTTP as its transport layer and in most cases the message payload uses ‘JSON’ structure.

JSON is a human-readable format, which makes it possible for anyone to inspect these messages.

Besides the great synergy that REST brings by linking the Web and Telecom worlds, REST in itself has important advantages over the legacy Telecom management protocols that make the development process easier for the 3rd parties integrating with the API. Unlike SNMP and TR-69, REST is, as said, human-readable. Thanks to HTTP, REST easily traverses firewalls – a problem which SNMP and CLI may face. REST also does not require identical schemas (data structures) to run on both managing and managed devices in order to talk to each other, which simplify its maintenance. REST is also secure as it can run over HTTPS while security on the legacy protocols is complex.

Lastly, REST is a stateless API unlike CLI (which is both statefull and unstructured). REST statelessness makes it easier to implement.

AudioCodes, which has always been a firm believer in open standards, is investing heavily in REST. Our soon to arrive next major SBC release, will have an impressive set of REST APIs with which our partners are already working to create innovative new applications. Stay tuned.

Redundancy & High Availability

High Availability Redundancy for All

[Post is better viewed on the blog Website]

The Need for High Availability

The need for businesses to remain on-line at all times, if the connection to the service provider or on premise equipment should go down, is a critical one. And it is critical for all businesses, large and small alike.

In VoIP networking, the ability to always keep the network up and running is called High Availability (HA) and it can mean several things. For one, it means survivability. If the WAN connection (SIP trunk) to the service provider goes down, the customer needs a “Plan B”.  This is typically accomplished with a Session Border Controller (SBC) deployed at the enterprise, playing an important role in continued phone connectivity and routing at the customer site. It also can mean resilience. Here, the calls at the customer will find their way out of the local site to their destinations via alternative channels. This can be via PSTN fall-back, via GSM connection or even via a connection to a back-up second SIP trunk.

Redundancy & High AvailabilityAnd then there is redundancy where fully redundant networking infrastructure is used, eliminating single point of failure risks. With VoIP networking this would mean there are two SBCs deployed in an active/standby configuration. In normal operations, the first SBC does everything while the standby SBC is only synched with the first one. However, if for whatever reason the first SBC goes down, the second one takes over and all the active calls now go through it, ensuring that no active calls are dropped. User registration is synched between the two devices and a transfer to the standby SBC, seamless to both the network and to the users, occurs.

Increase in HA Demand for Medium to Small Businesses

Survivability and resiliency tend to be features provided in networks of all sizes. However, redundancy, for many vendors, seems to be reserved for only the larger carrier and enterprise networks, those with over 600 sessions. To handle requirements for High Availability redundancy for small to medium businesses some SBC vendors offer their customers over-sized carrier-class SBCs. This mismatch forces customers to deploy SBCs which don’t fit neatly into the enterprise environment, as they are more expensive, have unnecessary features on the one hand and may be missing other features necessary for this environment on the other.  (We call this “Going duck hunting with a Howitzer” – overly complex and in the end, not very effective).

At AudioCodes, we have witnessed a sharp increase in demand for High Availability Redundancy in small to medium businesses.  Perhaps these businesses have reached the conclusion that even in these smaller business environments they simply can’t take the risk that something will take down their network. AudioCodes has moved to satisfy this demand from the smaller businesses by installing High Availability redundancy in the Company’s Mediant 500 and 800 SBCs in addition to the higher-session SBCs.

(BTW: no ducks were harmed in the writing of this article)

Waves - Communications Webification

Things I Picked Up at WebRTC World East 2014

[Post is better viewed on the blog Website]

Last week was a busy one at WebRTC World in Atlanta with several parallel tracks, demos, keynote sessions and many discussions with long-time friends from the industry and some new friends I made at this event.

And here lies my (expected) problem. I’m mainly still seeing the same people I used to meet at the SIP events 10+ years ago, and not enough new faces. We were shown some customer examples by TokBox and a live demo of an easyRTC customer but this wasn’t enough. As an industry, we haven’t yet managed to open WebRTC to the general public of the web developers.  Could it be that WebRTC World is an event more tailored for VoIP experts? Tsahi and Chris are taking a stab at this challenge next week together with Google at the KrankyGeek show that will follow Google I/O.

With all the hype around WebRTC these past couple of years many many are now disappointed as they don’t see the growth happening at the “expected” pace. In the conference’s welcome notes, Phil Edholm addressed this issue nicely presenting WebRTC in the context of Geoffrey Moore’s theory for the Technology Adoption Lifecycle. 

The Chasm - Technology Adoption Lifecycle

Clearly, WebRTC will proliferate only once it is commonly used by web developers. Usage by the existing VoIP communication industry alone will not bring the communications capabilities enabled by WebRTC to the applications and scenarios we envision today. WebRTC, as Phil presented, is driving the communication webification wave. By the end of this decade, the way in which we communicate will change. We just need patience for this technology to take off.

Waves - Communications Webification

 

Keynotes

Google, Serge Lachapelle

The presentation by Serge covered 2 main topics. He started with the story of how WebRTC came to life. From a gap identified by the Chrome team, “Human Communication is not possible in browsers”, to the decision to acquire GIPS and the official announcement of WebRTC. There were 2 big challenges any company looking to launch communications services would run into – building and binding together the voice and video technology and overcoming all legal and royalty issues related to them. Since Serge had already 10 years of experience in breaking down those walls, he knew that they must be solved for the general public of developers and innovators in order to make this successful. Hence, the decision to acquire a leading media engine vendor and invest significant money and efforts into solving the patents tangle.

The technology challenges led nicely to the second part of his presentation that talked about upcoming (expected very soon) releases where a lot of focus has been put, among other things, on quality,  WebRTC over wireless networks, faster connection time and better adaptation to network changes. This is, of course, a short list. We will need to see the release notes of the upcoming Chrome 36 & 37.

In an earlier event in London, Serge spoke about the priority being given to solving WebRTC for mobile. I would have liked to hear in-depth details on that part of the picture. More might come to light next week when Serge covers this topic at the KrankyGeek Show where he will talk about Mobile WebRTC. I will not be there but will surely keep an eye on that half day event.

 

Microsoft, Bernard Aboba

This was an interesting technical presentation. It started with the directive of Microsoft CEO Satya Nadella for Mobile First, Cloud First continuing with the requirements for achieving high quality real-time communications on mobile. The presentation also covered the area of ORCA and how it will be adopted in WebRTC.

Bernard mentioned that the various Microsoft products such as IE, Lync, Skype, Yammer and others are all independent regarding their decision relating to WebRTC adoption. With Microsoft increasing their transparency about their IE plans through their IE platform status website (a place to see what the Dev team is working on) and the IE Developer Channel (where pre-beta versions of IE can be found), I hope we will soon learn more about Microsoft’s plans for WebRTC.

 

Avaya, Gary Barnett

There were several keynotes by vendors but I’m mentioning this one as it looks like Avaya is right on the money with their current plans for WebRTC in the scope of their Collaboration Environment engine given the company’s market position, customers and DNA. Different from other communications vendors who are trying to copy what others have already done and follow the footsteps of the API platform service providers, Avaya is using WebRTC to enhance their current offering.

In his presentation, Gary talked about how WebRTC plugs-in to Collaboration Environment and makes use of existing capabilities such as speech analytics with the addition of web content brought to the service of the Contact Center agent and manager.

The presentation was given only in the context of Collaboration Environment and the Contact Center segment. There are of course, other products and services such a communications vendor can launch by utilizing WebRTC but no information was given in this regard.

 

TalkBox, Ian Small

As usual, Ian gave a great presentation seasoned with good live demos. On this occasion and at his previous keynote at WebRTC West in Santa Clara, Ian put a lot of focus on media processing capabilities. These are complex things to do but bandwidth adaptation, dominant speaker detection and dynamic layout changing were done by video companies many years ago. The nice thing about what TokBox does is that it makes all this accessible to the web world in a complete and comprehensive solution. They could have just bought all these media processing capabilities from a 3rd party and used them.

 

AudioCodes at WebRTC World Atlanta

In a previous post I talked about the Open vs. Island types of WebRTC deployments; AudioCodes, falls into the “Open” category as an enabler of communication across VoIP networks and vendors in high quality. As such we presented the SBC with WebRTC interface including support for DTLS and other goodies as well as the Opus enabled IP Phone. From this perspective AudioCodes is well differentiated from other comparable vendors who demonstrated products that are more in the GW category. The key differences AudioCodes presented were as follows:

  • Adding WebRTC to the SBC rather than as an external box
  • Opting for Opus all the way instead of G.711 or mandatory transcoding on the GW
  • Taken together, this means a more efficient, lower cost, higher quality solution

In addition to our booth, both Alan Percy and I took part in a total of 8 sessions:

Were you in Atlanta last week? I’m looking forward to hearing your take on this event in the comments section below.

You weren’t there and want more insight as to what took place in the above sessions or others? Feel free to drop us a note in the comments section below or to contact us directly.

2 Box WebRTC GW

Why not All WebRTC GWs Were Born Equal

[Post is better viewed on the blog Website]

2 Box WebRTC GWWebRTC, although not finalized in standard bodies, is already being deployed in different networks and segments. One can categorize WebRTC deployments as either an Island or as Open.

An Island – All communications of the service run within the closed network of the provider of the service. An Island deployment can use any proprietary technology it wishes and can change behaviour between versions without the need to worry about backwards compatibility as long as it doesn’t change the interfaces with which users/developers interact.

Open – The provider of the service doesn’t control all the components and therefore, must stick to standard protocols. By way of illustration, think of connecting a home user from the browser to an enterprise SIP network or a service provider’s voice network.

Now enough with theory and let’s look at reality.

  • In reality, some Islands need to be connected to the external world.
  • In reality, most of those “Open” deployments require an alignment between vendors and server components to connect between them, AKA SBC.

Why is this important?

When looking at WebRTC in the context of existing communications and networks, there is no point or need to reinvent the wheel. That said, in cases where there is a need to bridge WebRTC into existing telephony networks (say SIP), WebRTC should be added as an interface to the existing connection point.

Looking at some of the ways WebRTC GWs are being designed today, we can see that many vendors have taken the route of adding WebRTC through an external box as illustrated below.

WebRTC GW as an External Box

One might say that the WebRTC GW is all that is required but there are many reasons why eventually such deployments end up requiring an SBC in the architecture. These reasons may include: Security, SIP Trunk and SIP networks interoperability, QoS and regulatory compliance.

What is the down side of a two box solution?

In addition to the obvious need to manage and maintain two boxes or SW components, there are also technological downside factors to this type of architecture.

In this architecture, each of the two components will take care of different functionalities – the GW will provide the WebRTC specific functionalities while the SBC will handle the generic SIP functionalities as well as the per vendor/network functionalities.

The GW functionality

GW functionality includes:

  • Terminate WebSockets and any other proprietary/standard signaling used on the WebRTC leg
  • Terminate DTLS
  • Handle ICE functionality
  • Handle RTP multiplexing as in WebRTC all RTP and RTCP streams are sent on the use port
  • Support for Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF)

The SBC functionality

SBC functionality includes:

  • Support for enhanced SIP features such as class 5 features, music on hold and forking
  • Support for vendor specific functionality and call signaling.

Putting it all together

Due to the nature of functionality supported by each one of these components, both signaling and media need to flow through them both. This presents a significant challenge to the architecture as it increases complexity and media delay.

WebRTC GW in an SBC

What is the alternative architecture?

Similar to other interfaces and vendor specific functionalities supported by an SBC, WebRTC can be included within the SBC itself. By taking this approach and allowing for dynamically turning on and off this functionality, you avoid the problematic issues addressed above.

WebRTC GW

Have you deployed or are you looking to deploy a WebRTC GW? Which of the approaches do you find most fits your needs?

Let’s Hear IT from the Middleman

Let’s Hear IT for the Middleman

 [Post is better viewed on the blog Website]

The rapid rise of e-commerce internet sites in recent years has brought about significant changes in the way we go about purchasing goods and services. In particular, items that previously we would only have considered acquiring through an agent are now freely available for us to buy directly via the web. Despite all that, there are still some areas where we are more reluctant to cut out the middleman, like buying a house or car. The added complexity of this kind of purchase (e.g. legal issues, payment plans and just the amounts of money involved) means that we feel more comfortable in the knowledge that someone else is acting on our behalf.

Technological Middlemen and the SBC

Let’s Hear IT from the MiddlemanThe same can be said for the world of technology and telecommunications. Many middleware systems and mediation devices are available today to simplify and control interconnectivity between all sorts of platforms. In the world of IP communications, the predominant mediation device is the Session Border Controller or SBC, which sits at the border between two VoIP networks and provides security, quality, and access control between the two domains.

Connecting Microsoft Lync to SIP Trunking Services

Several recent posts on the AudioCodes blog have discussed the importance of deploying SBCs in a variety of different scenarios. One scenario where there seems to be grounds for leaving out an SBC is when connecting enterprise Microsoft Lync deployments to SIP trunks. According to Microsoft’s own recommendations, the Lync Mediation Server acts as the mediation device between the enterprise Lync Server pool and the outside world. Using this architecture, companies are able to connect to Microsoft-certified SIP trunking services and start to reap the technological and commercial benefits that they offer. With tight IT budgets always competing with the draw of technological innovation, the addition of an SBC into such a scenario would, on the face of it, seem to be something of an unnecessary extravagance. A closer look, though, reveals a number of important considerations that, when weighed up against the alternative, support a strong case for deploying an SBC to connect Lync to SIP trunking services.

Mediation Server or SBC?

Recently, we published a technical guide document entitled “SIP Trunking in Lync Networks – The Easy Way Out” (download it for free here). The aim of this document is to highlight some of the considerations when connecting Lync to SIP trunks which may not be obvious to many IT managers. The document explains how the complexity of SIP trunking connectivity cannot always be handled adequately by a direct connection from Lync’s Mediation Server. SBCs, on the other hand, deliver critical technological and cost-savings value to SIP trunking connectivity in areas such as:

  • Flexibility
  • Interoperability
  • Security
  • Voice quality

The guide goes into some detail in each of these areas. There isn’t room in a single blog post to cover all of them but, for the moment, let’s just take a closer look at one aspect of the first item to illustrate the limitations of Mediation Server when compared with using an SBC. (In future blog posts we will look at some others.)

SBCs for Routing Flexibility

Least cost routing (LCR) is a common feature in any communications setup for controlling costs, giving administrators the ability to decide how to route outgoing calls in the most economical way. Mediation Server is only capable of connecting to one SIP trunking provider at a time, meaning that enterprise-controlled LCR for outbound calls is not possible. With an SBC in place, however, administrators are able to connect to multiple SIP trunks simultaneously and create extensive LCR schemas to ensure that calls are handled in the most efficient and cost-effective manner. And, if your SBC is a hybrid device supporting both SIP and TDM connections, you can perform LCR between multiple SIP trunks and PSTN connections.

SBC – The Middleman You Can’t Do Without

So maybe not all middlemen are unnecessary evils. Just as your real estate agent might have the market knowledge and experience to find you a better deal than you could have done yourself, so too deploying an SBC can help you control the costs, quality and security of your SIP trunking connections.

To quote from “SIP Trunking in Lync Networks – The Easy Way Out”:

An experienced IT manager knows that sometimes the potential downsides of taking shortcuts outweigh the cost of well-designed deployments. The expense of an SBC is relatively small compared to the overall cost of designing, implementing and operating a Lync deployment. The decision to include an SBC is, therefore, a simple one, given the value it offers in terms of security, interoperability and quality.

If you want to learn more, please download our guide. We’d love to hear to your thoughts in the comments section below.

Michael-Williams

Using the SBC Configuration Wizard: An Interview with Michael Williams

[Post is better viewed on the blog Website]

Speaking with customers is always a great way to get feedback. The PM team at AudioCodes does this regularly. Avi Grabinsky who is already well known on the AudioCodes blog was kind enough to invite me to join one such virtual meeting. The result of that meeting is this first customer interview on our blog. The interview is with Michael Williams who is a Technical Consultant for Nexus Open Systems. Nexus is an AudioCodes partner using our SBC Wizard as part of their installation and maintenance process for their customers. It was interesting to hear Michael’s view on this tool.Michael-Williams

Michael, for our readers who are not familiar with Nexus Open Systems, can you tell us what the company is all about?

Nexus Open Systems delivers IT solutions, software, websites and support services to companies and organisations of all sizes that require true technical expertise to meet their goals. Established in 1998, the company has two offices, incorporating a digital media studio and a hi-tech IT Training and Exam Centre, in Exeter the heart of South West England.

We are a networks and technology solutions company working throughout the UK and beyond. 15 years old, we have 75 staff encompassing a team of 40 engineers and developers.

Nexus has been involved with the Microsoft Lync product since its inception and amongst our 18 Microsoft competencies we hold the Gold Communications competency which relates to the Lync product set. This is testament to our ability to consult, install and support Lync solutions. For 2014 our goal is to become a Premier Lync Support Partner and our software development team are developing a Lync application which will go to market in 2015.

We have strategic relationships with key vendors within the Lync Ecosystem including: Microsoft, AudioCodes (Silver Partner), Mitel (Gold Partner), Dell (Premier Partner), VMware (Enterprise Solutions Partner) and Jabra (Gold Partner).

In the segment of Microsoft Lync who are your prime customers and what segments do you cater for?

Nexus works primarily with medium to large enterprise clients with regards to Lync, with on-premise deployments making up the majority of our current projects.

We are not confined to any organisation segments and work across all verticals, including professional services, public sector, education, non-profit and general industries.

Where do you see  AudioCodes products playing a role in Lync environments?

AudioCodes form a core part of our Lync environment offerings, both in terms of gateways and also handsets. We build our solutions primarily around the AudioCodes product set and then bring in other elements from the Lync ecosystem.

You have been an early adopter of the AudioCodes SBC Wizard. What did you find as the key benefits of this tool and how was life before it?

The SBC Wizard helps us reduce the amount of time needed to setup an SBC: as the wizard applies the most common settings, it saves around an hour and a half per SBC.

Before the SBC Wizard we would have to configure all the basic settings that are needed manually. This can be very tedious and time-consuming.  Moreover, previously when we did the configuration manually there were configuration errors. If we were lucky, those errors were discovered on the spot as part of the configuration process and then we had to spend some time figuring out the errors and fixing them. In the harder cases, errors were discovered after deployment when users were already using the network and some scenarios weren’t running well. Such cases are more of a problem because they involve bad customer experience. Therefore, using the wizard not only saves us time but helps us improve our customers’ experience.

You have several Unified Communications partners. How do you handle cases of multi-vendor sites and do you use AudioCodes products to support these environments?

Our engineers have the expertise to be able to integrate Lync together with AudioCodes devices within multi-vendor sites. Microsoft Lync and AudioCodes are our prime focus for Unified Communications; alternative solutions play a much smaller role in this part of our portfolio.

What do you see as the future direction and growth areas for Nexus?

Nexus is increasingly moving into the large business and enterprise sector. With regard to voice, we are currently developing this segment of the market and are driving it through a direct and reseller channel pre-sales and consultancy regarding Microsoft Lync and AudioCodes gateways.

I think the technology that will have the biggest impact in the communications market will be SIP trunks. They allow our customers to reduce costs and improve disaster recovery options.

If you are interested in sharing your experience with AudioCodes products in an interview on this blog please send me a note.

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.

Classification

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.

Classification

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.