Posts

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.

The Value of Voice

Make it Short, it is Expensive

Determining the value of communications

[Post is better viewed on the blog Website]

Mothers-in-law are a sensitive subject. Anyone who has a mother-in law knows this very well.

Now, don’t get me wrong. Most people would probably envy me for mine. She got into this post because she is a natural reserve for technology of the 60-70’s. She made a conscious decision to remain planted back in those days in many areas, technology is just one of them. It’s a long story and this isn’t the best place to go into details about it J. Last week I was in Spain with my wife trekking in the Pyrenees and our kids were left with our extended family. Two days during the week were with my mother-in-law at our house. When I called and my 6 years old son picked up the phone he started waffling his usual nonsense. In the background I heard my mother-in-law saying to him – “make it short, this is a very expensive call”.

The value of voice goes down to zero

This is something I heard many years ago and one I use myself. But this statement needs to be placed in the right context. When I call from my vacation, I have many means of making a free call or a call that is so cheap that practically puts it into the “free” category. My son can waffle for as long as he wants. I can call through a mobile application (called Bphone) provided by my local service provider that takes my home number with me and allows me to make calls from anywhere over WiFi at the cost of a local call, as if I was calling from home. This happens to be an application AudioCodes has provided Bezeq (the local service provider) for this service. I have plenty of other options for calling PSTN using Viber, Skype… or the AudioCodes enterprise mobility application. All these allow for calls from anywhere for a free/flat rate to a very low cost.

But this doesn’t mean that the value of voice goes down to zero. Voice is still the #1 revenue source for service providers. It has value for consumers and surely has value for enterprises, value that is far more than the call itself. There are services attached to calls in the enterprise environment.

A good post written by Yossi Zadah is scheduled for release next Monday that takes a look at the value of voice calls through the prism of call toll fraud, so stay tuned.

The value of communication is determined by the service in which it is embedded

The Value of VoiceThe value of voice as well as video, presence and messaging, is not in simply connecting such sessions but needs to be viewed in the context of the service in which it is embedded. If voice/video communication is embedded in an insurance company’s self-service website where a user can speak with an agent when running into issues purchasing his insurance, the value of the call is not the amount of cents it costs but rather the fact that the deal was closed instead of the customer going to the competitor. There is a multitude of examples of similar and other cases such as remote learning and group collaboration. In all these cases, the value of the call is the cost saved or the revenue earned. The value perceived by the provider of this specific service is higher than the value the Communications Service Provider (CSP) receives for the call. Therefore, packaging the calling service in a way that is easy to embed into other services will allow the communications service provider to extract more value from it. This naturally leads us to the web and to WebRTC.

WebRTC as a catalyzer

WebRTC makes communications ubiquitous across web services. It renders the world of VoIP communications accessible to web developers and not only to VoIP experts. WebRTC is a catalyzer for communication revenue as it allows combining communications with web services. Moreover, it allows connecting these services with the existing enterprise communications platforms through SBCs that reside within the enterprise domain or in the cloud. With WebRTC, communications become a web feature that allows for the increase of conversion rates and revenue from web-based services and therefore, its true value becomes the value of the service and not of the call itself.

Returning to the phrase “The value of voice goes down to zero” I would coin a new phrase “The value of voice is equal to the value of the service in which it resides.

What is your view on the value of voice? Feel free to express your views and comment to this post.

1 Answer to WebRTC Signaling

1 Answer to WebRTC Signaling

[Post is better viewed on the blog Website]

A lot of opinionated information has been written about the debated topic of WebRTC signaling. An example of a good and well-balanced technical post is WebRTC Hacks, written by Victor Pascual.

I am excited to be participating in a panel on this topic next week at WebRTC Global Summit in London and I thought it would be a good idea to provide some points about this topic beforehand. If you happen to be around please come and pay us a visit, we are at booth #6.

What is the debate about?

There are 2 fundamental items the industry is debating about:

  • Should WebRTC define signaling
  • When building a product/service should signaling be based on existing standard or proprietary protocols

The answer to the first question is easy. Since WebRTC was born to serve Web developers, not Telecom VoIP geeks, one would never be able to imagine what WebRTC could be used for. This fact requires taking the “less is more” approach and define only the minimal must, thus, leave signaling out of the WebRTC definition scope and put it in the hands of those building each specific solution.

The second question seems more complex as is testimony to the many opinions out there. Some think proprietary JSON-based signaling is the only answer. Others think standard signaling is the answer pitching to go for SIP or XMPP. Another opinion I enjoyed debating about at the WebRTC 2013 conference in Paris was that WebRTC was “born” for IMS (needless to say I didn’t support that point of view).

1 Answer to WebRTC Signaling

So what is the 1 answer for WebRTC signaling?

If it wasn’t clear to this point, the answer is simply – it depends.

The decision of what signaling to use when building a product or a service depends on its nature and the solution for which it was designed for.

The primary distinction required for deciding if a standard or proprietary approach fits best is whether the solution goes into a service island or if it needs to connect with an existing VoIP network.

In the case of a service island, proprietary signaling will typically be chosen because it is the easy approach, however, if advanced telephony functions, already well defined in standard protocols such as SIP are required, there is no point in reinventing the wheel. It is perfectly OK to pick and choose the functionalities of SIP needed in the implementation and ignore the rest.

On the other hand, if the solution is about allowing WebRTC service to connect with existing standard VoIP networks such as SIP the natural signaling choice would be SIP.

Last but not least, if you are providing an end-to-end solution that includes the WebRTC clients as well as the server, whatever signaling is hidden under the hood doesn’t really interest the developer building the application. What does interest the developer is how simple it is to use your APIs for integrating your client into his product.

It would be interesting to get your comments to this post detailing your view on this subject and how you decided to deal with this matter in your implementation.

Moving WebRTC Into Your Network Through the Front Door

Moving WebRTC Into Your Network Through the Front Door

As part of my work with WebRTC, I get a chance to speak to different types of companies about their WebRTC plans. When speaking with companies that have existing VoIP products and services, the conversation usually moves to how WebRTC should be added to their offering, what the additional service benefits are and how to architect the solution. The typical requirement is to leave the existing deployment untouched and bridge WebRTC into the existing network through some sort of a GW. Where should the logical function of the GW be located and what should the network architecture look like are usually the questions debated. To answer them, I decided to write this post.Moving WebRTC Into Your Network Through the Front Door

Image credit: Muhammad Mahdi Karim

To demonstrate the consideration points and options, I will use an example of a contact center. For the sake of this example, let’s take a contact center that has both PSTN lines as well as SIP Trunks from a service provider. All traffic inside the contact center is via SIP where some of the agents are working on premise and others are home agents who are “called in” for handling contact center peak traffic.

 

Architecture Options when Adding WebRTC

In my discussions with customers and partners who are looking to add WebRTC into their existing networks, the architecture alternatives considered were:

  • A dedicated GW
  • Adding a WebRTC interface to their current core server
  • Adding WebRTC through an SBC

Before and After WebRTC

BeforePre WebRTC Contact Center Connectivity

  • Traffic comes from a service provider over SIP trunks or PSTN
  • All traffic in the contact center is SIP
  • Home agents are connected over IP-SIP but this is done in a secured and controlled manner
  • The contact center core server is placed inside the contact center network. Security is handled by other elements so it is protected from denial of service attacks, call fraud and other security vulnerabilities
  • Calls are using G.729 or G.711. Transcoding, if required, is handled in the contact center network

 

After

Adding WebRTC into the game creates new requirements and a new type of traffic source. With WebRTC, users browsing the website of the company serviced by the contact center, can call in directly from the browser. Their traffic runs over the Internet directly to the contact center.

WebRTC includes 2 voice codecs: G.711 and Opus. These are the codecs that come within the browser. If the intention is to eliminate the need for download, calls must be initiated using one of these 2 codecs.

Since G.711 is not built for running over the open Internet as it doesn’t include resiliency, it is beneficial to initiate the calls with Opus. The optimal approach would be to run Opus end-to-end from the browser to the agent but in cases where this is not possible, it is best to keep Opus on the open Internet leg and transcode when getting into the contact center network.Alternatives for adding WebRTC to the Contact Center

  • The contact center is required to have a “leg” in the public Internet domain
  • Quality of service is not managed. Even though in many cases the quality is good, supporting SLA requires the capacity to manage and monitor quality of experience (QoE)
  • Supporting Opus requires either adding a new intensive computing transcoding function or adding Opus to the agent’s client

 

Alternatives Comparison for adding WebRTC to Contact CenterThe comparison above doesn’t relate to any vendor specific product but rather looks at common functionalities of such products. Given this, the following conclusion should be viewed in context of the actual functionality supported by the specific products considered.

The comparison shows that in the case of the contact center example in this post, adding WebRTC to the existing internal contact center server will yield high risk and therefore, it is not a recommended alternative.

The selection between a pure GW and an SBC would depend on priority focus. If security and QoS are of high priority, the comparison leans towards the SBC alternative.

Lync Conference 2014 Ran Inbar

Lync Conference 2014 – Smashing into a New Era

[Post is better viewed on the blog Website]

Lync Conference 2014 Ran InbarThe second annual Lync Conference is now behind us, this year held in the Aria Convention Center in Las Vegas and again a sell-out.  Themed “Coming Together”, the event was attended by some 1,800 end-customers, partners and Microsoft staffers.   Mecca for the Lync faithful, the Lync Conference is the place to be for Lync education, networking and a peek at coming attractions.

This year saw an increasing number of enterprise users, many sharing their experiences in moving beyond their early pilots to full implementations.  During AudioCodes’ private “Circle of Excellence” pre-conference event, we heard from a number of Lync network administrators about their successes and challenges in implementing Lync voice and conferencing across their enterprises.  Cargill, Amgen, Bally Entertainment and a number of other large enterprises all shared their Lync migration stories in great detail.  You can read a summary of the event by Brent Kelly, Consultant at KelCor.

We also took the opportunity to demonstrate our new 430HD and 440HD IP Phones along with our Better Together over IP functionality for Microsoft Lync.  Shown here, Ran Inbar, CTO Unified Communication for AudioCodes demonstrates the Better Together functionality to Matt Landis, a widely read blogger on the topic of Lync.

On the main keynote stage, Microsoft announced some key milestones for Lync with Derek Burney demonstrating the increasingly integrated Skype/Lync experience, the newly updated Lync client for Android tablets and a pre-release look at voice-driven “zero click” Lync client features.

Microsoft Lync Conference 2014 Gurdeep PallFollowing Derek, Gurdeep Singh Pall returned to the stage, announcing the end of the era of Unified Communications and the start of Universal Communications, bringing a consistent user experience across media types and devices. Gurdeep also demonstrated a web-based Jscript application, showing a somewhat un-realistic medical consultation experience, where a patient could hold a video call with a doctor.  (While the technology is very much realistic, in my experience, actually getting a doctor on a video call is highly un-realistic – they seem to be pretty techno-phobic.)

AudioCodes had the opportunity to share our experiences on a panel discussion on the Lync Ecosystem, sharing the stage with AT&T, Jabra, Unify2 and HP.  Challenging the “one throat to choke” argument, the panel dissected the benefits of the well established relationships between the large systems integrators, partners and enterprise buyers.

And finally, in an over-the-top spectacle, Microsoft’s exhibit featured a “product launch” cage where visitors could use a large slingshot to launch legacy telecom devices into a wall, aiming for a target with a gong in the center.  The occasional direct hit would fill the hall with the crashing sound, followed by cheers from the crowd.

Even if you missed the event, you can still participate in the conversation on http://mylync.lyncconf.com – Alan can be reached  via email at alan.percy@audiocodes.com or on Twitter @AlanDPercy

Going native with WebRTC

Going Native with WebRTC

Going native with WebRTCIf you are reading this blog there is a good chances you heard about WebRTC and are well aware of the various products and services around it. Centering on enterprise communication and how WebRTC is being realized in this segment, the market is pretty much focused on one solution – a GW.

Now don’t get me wrong, WebRTC GWs are very important, you can’t really do without them if you want to overcome the slow deployment cycles and stay current with technology advancements. The point is that a GW is not enough. Let’s delve more into that.

The Typically Proposed “WebRTC for Enterprise” Architecture

If you look at some of the architectures used today for bringing WebRTC into enterprise networks they typically comprise a WebRTC GW and a media server that transcodes Opus to some other common codec, say G.729. Some options will also include RESTful APIs for configuration and creation of services on top. On the Audio side, there are cases where G.711 is used end-to-end but this option is not a preferred one from quality perspective when going over the open internet even though there are ways to add resiliency and improve quality even if G.711 is used.

A typical architecture of WebRTC GW Deployment

A typical architecture of WebRTC GW Deployment

 

The architecture described above is great, it will do the job. Question is, at what price.

Basically this architecture is kind of an “easy” way to bridge WebRTC into an enterprise network. You put a big box that will brute-force everything to what you have running on your network today. If that big box doesn’t provide the required capacity, just add another one.

There is another option

The most “expensive” component in GWing WebRTC into an enterprise network is the transcoding part. The way to work around this is by adding native support for Opus to the end devices. Doing so will yield quality improvement, cost reduction and preserve privacy. You can find a detailed technical overview why going native with WebRTC media on the end devices is important in an earlier blog post I published.

Reality is that Opus transcoding is extremely computing intensive so architecting this task on the server side will take a significant capacity toll on your system.

The flip side of this is that putting Opus on the IP Phone is complex. Assuming you are going for a SW upgrade and not a HW change, it requires flexibility in the phone architecture and hard work to get Opus running on it.

The subject of why adding Opus to existing IP Phones is complex interested me for a long time so I had a chat with our experts. Eli Shoval who is running our DSP Group and Oren Klimker, a team leader in this group.

The challenges in running Opus on an IP Phone can be summarized to be:

  • Processing power – Since not all IP Phones were born equal there needs to be optimization work and actual rewriting of some codec parts to make it run best on the IP Phone processor
  • Memory – This includes both footprint and run-time memory requirements. Opus is a feature rich codes that serves a wide variety of implementation scenarios; additionally, since sampling rate of Opus is higher than traditional VoIP codes memory required for an audio channel is increased

This in turn yields 2 main tasks required to overcome the MIPS and memory challenges:

  • Optimization – This work includes optimized implementation of some components of the Opus codec for both performance on the specific phone’s SoC (System on Chip) and memory consumption
  • Selective implementation – Part of the rewrite work needs to include removal of certain functions not required on an IP Phone

But there is Opus 1.1, doesn’t that solve the issue?

The short answer to this is NO.

In details, there are 2 reasons why Opus 1.1 doesn’t remove the need for native support for Opus on the end devices but rather make it even more essential.

The first reason is simple. Since transcoding will always add delay, reduce quality and impose cost on the server implementation; whenever possible, better to avoid getting into transcoding.

The second reason lies in the details of Opus 1.1 improvements. There is a pretty long list of changes, some such as surround encoding improvements don’t really touch the IP Phone requirements that much. What I want to take a closer look at is the speed improvements. As it looks, the team that built Opus 1.1 focused on improving the codec speed when running on ARM processors with NEON (do I hear mobile?), they reached up to 40% improvement. On the other hand, for x86 architectures there is no real improvement and in some cases things even got a bit worse. This can be seen in the diagrams below.

 

 

Opus 1.1 performance on ARM Cortex-A9 and i7-3520M

Opus 1.1 performance on ARM Cortex-A9 and i7-3520M

Source: xiph.org

 

This means that Opus 1.1 doesn’t bring good news to transcoding servers but it does improve the performance on some of the end devices.

Conclusion

As explained in this post and on earlier ones the preferred architecture for deploying WebRTC on any network and specifically on enterprise networks is one with end-to-end media without transcoding. The target should be to minimize the cases of transcoding to those where it is a must. Such cases as where traffic is going through a GW to PSTN or over SIP Trunks. In other cases, going native with WebRTC on the end devices is a preferred architecture.