Posts

Garfield & Odie

The NSA is After My Grandmother Secret Lasagna Recipe

Commenter: Hi, can I ask a WebRTC related question?

WebRTC forum moderator: Of course, you are in the right place.Garfield & Odie

Commenter: My name is Garfield.

WebRTC forum moderator: Ahh OK, are you related to the cat?

Commenter: Seriously? When’s the last time a cat asked questions in the WebRTC forum?

WebRTC forum moderator: Good point.  How can I assist you today, Mr. ahh Garfield?

Commenter: I have a problem with a family secret which has been passed down from mouth to ear for centuries.

WebRTC forum moderator: And how is it related to the WebRTC forum?

Commenter: Well, I am quite old and I realized that this is a good time to pass the secret to the next generation. I have been told that WebRTC has the most secured media channel there is. So I thought this would be a good place to do it.

WebRTC forum moderator: If I may ask, how old are you?

Commenter: 15 years old.

WebRTC forum moderator: Excuse me? Ahh. Why don’t you pass your secret to your children?

Commenter: They’re on the other side of the ocean and I am afraid to do it on an international call.

WebRTC forum moderator: Why?

Commenter: Hey, I may be old but I’m not so naive to let the NSA learn about my grandmother’s secret lasagna recipe.

WebRTC forum moderator: I get your point. You heard right about WebRTC. Let me explain: The security mechanism in WebRTC is quite different than other calling systems. WebRTC mandates all media channels voice, video and data using DTLS protocol for security.

The browsers exchange a Datagram Transport Layer Security (DTLS) handshake on every media (voice, video and data) channel. Once these DTLS handshakes are completed, the media is encrypted and begins flowing between the browsers using Secure Real-time Protocol (SRTP).

Other calling systems are using SDES (used by SIP); in SDES the crypto is forwarded in the SDP via the signaling interface and can be used by the servers in the signaling path to decrypt the media.

SDES, which is used more in the SIP world, would help interface more easily to existing SIP-based infrastructure. Although there is consensus that DTLS will be mandatory for WebRTC to support, until two weeks ago, Google Chrome supported both SDES and DTLS. The most recent Chrome version no longer supports SDES. Mozilla Firefox never supported SDED.

In short, when using WebRTC end-to-end, eavesdropping is not an option; your grandmother’s lasagna secret recipe is safe.

Commenter: Many thanks, by the way, what happens if recording is a necessity such as in Contact Centers or where regulation requires it?

WebRTC forum moderator: In such cases, there are a few options. One option is using WebRTC client API for recording, however it’s a local solution.  An organization straight forward approach is to use a WebRTC GW with forking abilities, or a Session Border Controller which supports SIPREC for recording with WebRTC termination capabilities. The SBC then maintains two DTLS call legs toward each party of the call and in the middle; it forks the call to the recording server using a standard SIPREC protocol.

WebRTC Recording with SIP-Rec

Commenter: It’s strange that you are mentioning SBC’s in this context, since a few weeks ago I read in BlogGeek.me that SBCs are not required in the WebRTC world.

WebRTC forum moderator: That’s true when making a call between two browsers but there will be a need for a border element to be between the WebRTC world and the SIP world, WebRTC GW (SBC), to terminate WebSocket, DTLS, ICE and OPUS transcoding.

Commenter: That’s very intriguing! So do you think it is safe to send Pomodoro Siciliano over the WebRTC data channel too?

WebRTC forum moderator: I would recommend starting moderately with the basil.

Commenter: Meeow…..

WebRTC forum moderator: Oh my……..

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?

Cloud

Who is afraid of the cloud?

[Post is better viewed on the blog Website]

Cloud“The Cloud” – everyone is talking about it. Studies, market reports and analysts refer to it as the “next thing” and as the opportunity that communication service providers (CSPs) must not miss. Well, it is not so easy!

Revenue opportunity for the service providers

There is no doubt that the telecom market is changing. The increased competition and the commoditization of traditional telecom services have negative impact on the CSPs revenues leading them to evolve beyond network connectivity and seek new revenue opportunities.

The good news is that the cloud trend that we are seeing for some years in the market has reached a point where CSPs can create “real” business value. According to Informa’s Telecom Cloud Monitor (http://www.informatandm.com/cloud-monitor/), the number of CSPs selling Cloud services has increased from around 60 in 2009 to about 230 in 2012 and there is a consistent growth in CSPs cloud spending.

CSPs active in cloud services by region

Cloud services allow the CSPs additional revenue streams with new value propositions that they can offer. For example, a CSP can leverage its key strengths in communication technologies to offer hosted unified communications (UC) services that combine data, voice, security and more, but at a lower cost as compared to on-site platforms. Another example is the provision of cloud applications such as business sales automation, invoicing and billing, and storage and backup in the cloud.

Why should businesses move to cloud-based services? Well, there are some good reasons for doing so including cost flexibility, business scalability and simplifying communication services.

Can we trust the cloud?

How can the CSPs deal with customers’ fears of the cloud? These customers, most of them being small medium business (SMBs), are scared of putting key business functions into the cloud because if something goes wrong, they fear it could stop their business in its tracks. So, CSPs need solutions that will enable them to allay these fears.

We need to remember that CSPs have a unique advantage over other cloud players such as Over-the-Top (OTT) providers, given their existing data and voice communication networks. This is the biggest asset differentiating them from others. Using their existing managed networks, the CSP can guarantee end-to-end Quality-of-Service (QoS) that is critical for SMBs that need to perform at an enterprise level. The CSPs are known for their existing secure networks, providing them with a strong brand advantage when dealing with SMBs that are concerned with putting their sensitive business data in the cloud. And of course, CSPs have the advantage of existing local footprints and existing customer relationships.

The SMB customers that move to the cloud, in most cases do not understand technology and products, but they do require solutions and services. From the CSP perspective, the most critical factor for the SMBs will likely be the quality of experience (QoE) – keeping customers satisfied and avoiding churn. As mentioned above, CSPs are in a unique position given their existing managed communication network including the on-premises access equipment. The on-premises equipment is the demarcation point to the CSP data and voice cloud services. Without QoE assurance in this equipment, it will be extremely difficult for the CSP to sell and deploy reliable and trusted cloud-based services.

SMBs and Cloud

Protecting the business

As part of my work in AudioCodes I meet regularly with leading CSPs and hear their perspectives regarding their SMB customers’ needs when moving to cloud-based services. One of the things that they are most wary about is the business continuity, meaning, how can they make sure that the data and voice cloud services are always available? Consider the implications of an unreachable business, even if it is just for few minutes. Of course this will reduce customer satisfaction and eventually cost the business money. Or consider the example of a small insurance company that cannot access to its customer data base in the cloud and how bad that would affect the business customer support service.

In the real world, failures happen, and yes, there will be cases when the voice or data services in the cloud will be unreachable. So the question is how can we protect ourselves from such a scenario?  And the answer is: Backup, Survivable & Resilience.

SMBs and Cloud Appliance

One solution is to use business routers with backup and survivability features. One of the great things about such a product is that it allows the CSPs to allay their customers’ fear of the cloud and provide them the confidence they need to place their key business functions in the cloud.

The approach is to use multiple WAN interfaces, backup PSTN interfaces and suitable software. With redundant WAN interfaces, you can make sure that in the case of a connection loss to the primary WAN the router will auto-switch to the backup network (for example the 3G/4G mobile network) assuring the SMB customer’s an “always on” Internet connection.

The router also ensures that critical business telephony services will continue to operate in the case of a connection loss with the hosted PBX. This is done using unique software features that will auto route the outgoing calls to the backup PSTN and will maintain internal business telephony operations.

So, the next time you are considering cloud-based services, ask yourself, are you protected in the case of a connection loss to the cloud? There is no reason why you shouldn’t be.

Image Credit: Flickr user Karen Ka Ying Wong

all you need is cloud

All You Need is Cloud

[Post is better viewed on the blog Website]

all you need is cloudI recently read the post from Software Advice called 3 Ways to Keep Your VoIP Service From Going Down With the Internet by Don Sadler. Overall it, was music to my ears, hence the title of this post.

Many people fall in love with the concept that going cloud with your enterprise telephony system means the end of all of your telephony worries.

The reality is more complicated, however.

Don’t get me wrong, putting your enterprise communications in the cloud is the right way to go. Yet life is a bit more complex than pure cloud vs. pure on-premise. The grey area between them is what complicates things.

The misconception of pure cloud

Starting to use an enterprise communications cloud service would basically require the following steps:

  • Register for the service and pay with your credit card
  • Upload an Excel file with all users and extensions
  • Start talking

This would pretty much be all that is required for a greenfield, a one location business with a few guys that are using an application on their mobile phones for their business telephony operations. But what if you are an enterprise, large or SMB, with multiple locations and an existing telephony system?

In such a case there will be a few requirements that will complicate things. A non-exhaustive list of these requirements include:

  • Gradual migration to the cloud
  • Call flow optimization (e.g. when 2 users are calling in the same premise)
  • Cost optimization when calling to PSTN
  • Resiliency

Gradual migration to the cloud

Typically, IT will not pull the plug on the current on-premise system and plug in the cloud service instead. They would run a test on one site, then expand to a multi-site pilot and only after a few months make the switch. What happens during this pilot phase and how are the 2 systems connected?

Moreover, in some deployments, IT may decide to maintain the old system for a longer period.  This may be due to technical or business reasons. Supporting this requirement will typically be achieved by deploying an on-premise SBC that will connect the 2 networks and make this integration transparent to the end user.

Call flow optimization

In the pure cloud approach, when all you have on-premise are IP Phones or an application on your smartphone, for example a phone call from John to his colleague next door, Alice, would see the signaling going through the cloud.

How about the media?

Would it go directly between John and Alice or would it need to go all the way to the cloud provider and back?

The answer is… it depends.

There are various factors that will determine the media flow in such a case. The key requirement for the cloud provider to technically be able to enable direct media is to know John and Alice are located on the same network. This can be achieved by simply having one “leg” of the cloud SBC in the enterprise network, something that introduces a security vulnerability or through an on-premise “component” that will figure this out. In real world deployments, all of these options exist.

Cost optimization when calling to PSTN

Do you want all calls to the PSTN to go out from the cloud provider’s network or perhaps you have better PSTN termination agreements in some areas where you also have a local branch? Would you want to route calls to the PSTN in that calling area through your local branch?

Achieving this will require some extra routing logic and an on-premise GW in the branch office.

Resiliency

This brings us back to Don Sadler’s post that talks about resiliency requirements for hosted communication services. Resiliency will keep communications alive even if the cloud provider’s service goes down or if there is a problem with the company’s connection to the provider. Having an on-premise cloud appliance will ensure continuity of communications between extensions in the branch, calls to the PSTN and routing of calls through a backup Internet connection (e.g. cellular).

Enterprise Hosted Services Architecture

A typical hosted enterprise communication services architecture

Conclusion

If you are in process of architecting your move to the cloud, it is important to remember that as VoIP cloud deployments move from MPLS to non-dedicated lines over the Internet, the level of control in the hands of your cloud provider is reduced. As such, having an on-premise demarcation point becomes essential. Solutions that enhance cloud communication services are available on the market. Audiocodes, as part of its One Voice for Hosted Services, offers such solutions specifically for Broadsoft deployments as well as for other hosted VoIP and UC deployments.

Featured image credit: Paula Izzo
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.

One Voice Operations Center

The VoIP Network Management Jigsaw Puzzle

Have you ever felt that your VoIP network management system is like a jigsaw puzzle requiring you to jump from one application to the other in order to complete a full cycle of handing an issue? Well, you are not alone. Meet Alice. Alice works in the IT department of a mid-size company with 3 offices in the US, 2 in Europe and 2 in APAC. This is what happened to her last week.

8:45am, Los Angeles

Alice gets a notification on her browser-based alarm system that there is a high call drop rate in the Boston branch office. She turns to the voice quality monitoring system to zoom-in on the problem.

She waits for the monitoring system to start, it’s a different GUI so it takes her a minute to find the information on that specific branch.

Since it looks like a problem that happened repeatedly over the last 2 hours, she runs a report to get the details of all calls dropped.

She flips back for just a minute to the alarm system to make sure these are really the calls for which the problem was reported. Alice then realizes that the problem has to do with one specific SIP Trunk that is dropping calls.

She must act fast. The Boston site executive was in touch with her from his mobile several times already. He and his team are about to go into a conference call with a customer and he is worried the call will fail.

Calling the service provider support line doesn’t look like something that will solve the problem for the call about to begin at the top of the hour. It is 8:53am and there is no time for support IVR and a call queue.

Alice decides to work around the problem and bypass this SIP trunk by configuring the branch SBC to route the calls through the Chicago branch over an MPLS link. She is still on the monitoring system so Alice now needs to switch to enter system with a different GUI, for the SBC configuration system.

OK. So I made up the story and invented my character Alice. But scenarios such as this one do play out every day for IT managers.

The multitude of independent management and configuration tools, each dealing with a specific task, is a major drawback in VoIP network management. You may think that this jigsaw puzzle is inevitable as each system comes from a different vendor or simply because each product has its related system even if they all come from the same vendor. But it doesn’t have to be that way.

But Gentleman, We Can Rebuild It

One Voice Operations CenterWhat if there was an all in one unified VoIP management suite? What if call quality monitoring, alerts and management of your network servers were all managed from one system? Well…that is exactly what AudioCodes One Voice Operations Center is all about.

The AudioCodes One Voice Operations Center is a suite of management tools providing full coverage of the entire set of actions required to manage a voice network in a Unified Communication environment.

It uniformly manages, monitors and operates the entire AudioCodes One Voice portfolio, including SBCs and Media GatewaysMicrosoft SBAs and IP Phones.

For example, in case of an enterprise using a Lync server, the One Voice Operation Center provides a complete view of the network voice quality, including Lync client to Lync client calls and Lync to PSTN calls. All in real-time. And if you need to fix a configuration, there is no need to go far. The same suite provides a provisioning interface to manage all your SBAs, SBCs and gateways.

Want to learn more? Come visit our booth #625 at the ‘Lync Conference’ to watch a live demo of our ‘One Voice Operations Center’.

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.