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.