Posts

Privacy Security

What Do You Know about OTT Voice Usage in Your Enterprise?

Encryption doesn’t always equal privacy

IT departments have all the means necessary to manage voice communication over the enterprise network and know the ins and outs of those communications. Some enterprises have compliance requirements to which they must adhere, some have security considerations and others have reasons to “know what’s happening in their network”.

With traditional VoIP systems, achieving the above is relatively a simple task.

However, OTT VoIP traffic is a different story. And in the case of OTT, most enterprises settle with one of the following options:

  • Block it
  • Live with the reality

The question is, are these the only two options available and what do enterprises really want to do about OTT VoIP?

Border TURN server

Some enterprises are adding a new entity to the border of their network, a border TURN server that forces all VoIP media traffic to go through it. This includes enterprise managed VoIP as well as OTT. VoIP media that doesn’t go through the border TURN server is blocked.

Adding this entity and blocking all VoIP media that doesn’t go through the border TURN server creates a problem for WebRTC communication because only one TURN server address can be provided for the peer connection establishment procedure. Since many services require media to go through an application TURN server, the border TURN server is left out of the flow and media that doesn’t go through, is blocked.

In a post I published last week together with Dan Burnett (co-editor of WebRTC standards) on WebRTCStandards.info (where we publish updates about what takes place at IETF and W3C with regards to WebRTC), we talked about RETURN. In a nutshell, RETURN encapsulates two TURN servers into one by adding the border TURN server as a configuration option to browsers. Details and illustrations can be found in the original post.

Since WebRTC media is always encrypted, what is the point in requiring it to pass through the border TURN server?

What can be extracted from encrypted communication?

Privacy SecuritySince all media flows through the border TURN server, there are some basic things it can “know” – such as the source, destination and length of a call.

With this knowledge, the server can block calls from black listed addresses, limit/monitor call duration and collect this information.

These capabilities are pretty basic and I wanted to know if there was more a border TURN server can detect in an encrypted media stream. To better understand, I turned to Yossi Zadah (who is already well known on this blog) and to Ilan Shallom. Ilan is a Professor at Ben-Gurion University and founder of a speech recognition company that today is part of AudioCodes. His technology is the brain behind our VocaNOM solution.

Some might be surprised to learn that there is a significant amount of information that can be extracted from an encrypted media stream. There are studies that show it is possible to identify the language of the conversation. Other studies show it is possible to unveil the identity of the speakers on such a call and even create approximate transcripts of encrypted VoIP calls by identifying words in the stream.

There is also a thesis specifically relating to Skype using Silk (from back in 2011) that details information that can be learned from such conversations.

Key Takeaways

  • Border TURN servers are being deployed at enterprises. Though they impose problems on WebRTC communication, RETURN is planned by the IETF as a solution.
  • Given the limitations border TURN servers impose on OTT traffic, my personal view is that they would be counterproductive in most cases as they limit Bring Your Own OTT (BYOO) in the enterprise
  • If you thought that your WebRTC call is private…think again.
Super Bob visiting Enterprise Connect

Enterprise Connect Kicks Off with Big News

Day 1 of Enterprise Connect is now done, with plenty to share.

Super Bob visiting Enterprise Connect

This year marks the 25th anniversary of Enterprise Connect (previously operating as VoiceCon), which was the theme for many of social and networking events during the show. A real testament to the need for fresh information on communications solutions (which have changed dramatically over the last 25 years).

Skype for BusinessMicrosoft formally unveiled their Skype for Business brand and client offering, showing a number of work environments and end-point devices in their booth. Front and center was the AudioCodes 440Hd IP Phone, showing its presence display and one-button calling.

Big news from Interactive Intelligence as they used the event to launch their PureCloud offering, a complete integrated collaboration solution based on WebRTC and hosted in the cloud. Most notable was a ground-breaking offer that included PureCloud Collaborate for FREE.

Had a great visit with Scott Francis from King County – a peer of mine and end-customer of AudioCodes that has deployed Microsoft infrastructure, offering UC services to improve the efficiency of county government. He’s a Superhero in his own IT responsibilities!

Visiting the show floor, I started my rounds of checking in with some of the partners that offer Lync and Skype for Business solutions. I started with a visit the folks from Ronco Communications, who were showing their Verapresence solution, an enhancement to Microsoft Lync that adds a number of important call management features including announcement, attendant, and call alerting features.

Looking forward to Tuesday, expecting more detailed discussions with partners, keynotes and time in some of the individual sessions. Be sure to check back again tomorrow!

Super Bob

Enterprise Connect – Through the Eyes of Bob

I’m really excited to be attending my first-ever Enterprise Connect in Orlando this next week.   From looking at the vendor list and sessions, it should be one of the biggest showcases of Unified Communications solutions this year and a great place to see the latest new solutions for my growing business.

Super BobRumor has it that Microsoft (booth # 1221) is going BIG with their launch of the new Skype for Business client and server software, taking Lync to the next level. Their booth and sessions are a “must see” on my list.  Zig Serafin, Corporate Vice President, Skype Business Services at Microsoft is the keynote speaker on Wednesday, March 18th from 10-10:30.  I’ll be there watching and listening intently.

After Microsoft (and it looks like right across the aisle), I’m really looking forward to visit AudioCodes to see their solution pavilion and demonstrations.  With offerings for my desktop users, the server room, my NOC and branch offices, the complete One Voice portfolio has served me well.  My understanding is they will be showing their One Box 365 complete solution including managed IP Phones.   I also hear from a reliable source that they’ll be showing a WebRTC to Lync integration, allowing users to share a URL to initiate a WebRTC call to Lync from their browser, avoiding the painful Lync browser plug-ins.

A number of great Microsoft and AudioCodes partners will be there as well, including NACR (booth #1805), SPS (booth #1531), The Via Group (booth #2012), and others.   The challenge is making the rounds and remembering everything in the few days I’ll be at the show.

The folks at AudioCodes have really flattered me with an invitation for a personal appearance in their booth and some cool tee shirts and other goodies with my likeness on them.  Stop in to their booth, snap a picture with me and you’ll go home with some cool swag.   If you are more interested in winning a new Surface 3 Pro, be sure to enter their Passport to Skype for Business drawing.

But I won’t keep all the great stuff to myself, I’ll be blogging and tweeting during the event, showing the best new solutions and snapping some pictures.  Keep an eye on #AUDCHERO on Twitter and be sure to check back to this blog every morning during the entire Enterprise Connect event.

After the event is over, you can always check in weekly as my accomplishments are regularly posted on my landing page at:  http://online.audiocodes.com/super-bob

OTT-Island

Media, Signalling and Breaking the OTT Islands

My post summarizing some of the Telco presentations at WebRTC 2014 received a comment from Josh, one of our blog’s loyal readers,who pointed out the market need for breaking the OTT islands.

On the topic of transcoding in your piece. Can you tell me how hard it is to transcode or not and can being a strong transcoder bring a high barrier to entry OTT VoIP network to market? I believe Audiocodes is one of the few players that can transcode brilliantly. For example: I believe you can allow for Whatsapp users to talk to Viber or Line to communicate with Skype. Now that is a service that would knock the socks off the market. Can you give me some color on this thought process?”

My reply to Josh was:

“Great comment that deserves a post as an answer rather than just a reply in the comments section”

So here it comes…

I would like to break down the comment into 3 topics:

  • OTT Islands
  • Media
  • Signaling

OTT Islands

This boils down to the following: do these service providers/OTTs want their services to interconnect?

Imagine you couldn’t call your friends’ home or mobile phones just because you are using service provider A and he is using service provider B. That’s not something we can accept.

In the Telco world, interoperability is king.

One of the reasons excuses Telcos use to justify their slow progress on RCS and VoLTE is the need for specifications to stop changing. They invest endless efforts and money to assure interoperability, that you can call anyone and that you can take your mobile to any country with a compatible network and just use it as a roaming user.

Using the same thinking process, some wait with WebRTC as even WebRTC1.0 is not really finalized and now we have ORTC and WebRTC 1.1 in the plans.

In the OTT world, interoperability contradicts the basic DNA of the company. They build islands and protect them. They typically don’t want you to be able to call someone who is not on their network unless you do it using some “out” service based on PSTN and are charged accordingly.

OTT-Island

There are rare cases where OTT players open up for others to interconnect between them. I was fortunate enough to be involved in such an initiative in my previous life. We provided a server that connected between two very big OTT players. Initiative came from them as they were battling an even larger OTT service provider and concluded they would be better off teaming up on this.

This interconnect was requested by them, hosted by them and available only for them. To the best of my knowledge, this interconnect wasn’t that successful. The reason might be that the interconnect was only for a limited set of capabilities. Doing full interconnect – user management, presence, voice, video, chat and advanced communication features – is hard and not always desired by the OTT as it eliminates the reason for a user to join their network, as he can access it from his current one, so why bother installing another app.

WebRTC is an interesting beast in this context. On one hand it is being adopted by traditional telecom vendors and service providers but on the other hand it was built for the web and has some OTT symptoms.

WebRTC deployments have strong client server coupling and connectivity to other networks is done through a GW, similar to the way it will be done in the case of OTT.

Assuming an OTT does want to open his service for interconnection, there are two big items he will need to make sure are open. Signalling and media.

Signalling

Signalling in this context includes all communication between the client and the server that is not media (media preferably goes directly between the clients).

Finding users, adding them as contacts, publishing presence information and receiving such information, initiating sessions (chat, voice, video) and activating advanced features. All of these functions require signalling.

OTTs don’t wait for standards to be ratified. On the contrary, signalling is the area where they differentiate, where they add their unique competitive edge. While some base their signalling on standard protocols such as SIP, there are always layers on top that make it different from the standard.

Hacking OTT signalling is sometimes possible, the problem is that OTT service providers may change parts of their signalling or add capabilities as they add more features. Moreover, if they don’t want you to GW them to other networks, they can block you.

Media

Media is a completely different animal. While some OTT service providers view voice quality as one of their strong points (Viber played on HD voice high quality in their early days), generally speaking, voice and video codecs used by these service providers are industry common codecs.  Skype, for example, developed the Silk codec for their internal use but later on opened it for everyone to use and today Silk is a popular codec. Opus, the mandatory codec for WebRTC, incorporates both Silk and CELT.

Viber does claim to use some internal codec but since most of these OTT players (Viber among them) provide PSTN connectivity, they have the capability to transcode the media used in their island to G.711, thus, to any codec.

Relating to the comment Josh made: While there are many transcoding solutions available, especially when voice traffic goes over the open internet, as in the OTT case, quality issues may arise. Given over 20 years of experience and technology developed at AudioCodes our products include quality enhancement capabilities that compensate impairments and network behaviour differences such as jitter and delay.

Why this is important?

While people see value in interconnection between OTT players or even having multi-OTT applications, OTT service providers typically view this in contradiction with their interest. They want users to use their service so they can monetize them.

WebRTC in the eyes of Technology and Marketing in Telecom

What Telcos Had to Say at WebRTC 2014

At the very end of 2014, I was at the WebRTC 2014 conference in Europe. I already provided a summary of the important things discussed at the conference and talked about the challenges of running WebRTC on mobile devices which was one of the topics I presented at the event.

In this post, I want to provide a few highlights of what Telcos presented with regards to their activities in WebRTC on the first day of the conference.

How do Telcos grasp WebRTC?

The answer to this question depends on who you ask. Sebastian from Slovak Telecom presented this topic nicely by showing how technology and marketing people view it in the telephony context –  connecting from IMS and billed as telephony.

WebRTC in the eyes of Technology and Marketing in Telecom

Dr. Joachim Stegmann from Deutsche Telekom presented the different views inside his company in one slide which nicely demonstrated the fact that WebRTC, as a technology, can serve multiple needs. It can extend existing networks and services on the one hand while creating new opportunities in the Web and Telco OTT fronts on the other. One hand doesn’t contradict the other and each will typically be handled by different groups inside the Telco organization.

WebRTC Business Opportunities in 4 segments

Taking a closer look at the 4 key areas Joachim presented:

Connecting Telcos and the Web – This is pretty much the IMS integration view that allows Telcos to launch new services that utilize both IMS and WebRTC. I can see the value but I view it more as a GW type of approach and would put the focus on the services that can be launched on the WebRTC side and less on how they connect to IMS.

Enterprise communication – This is a B2B type of service, and based on what Joachim discussed, it reduces the complexity we experience many times in enterprise video conferencing and collaboration. I agree that WebRTC can make these services better, easier to launch and easier to use. But there are many WebRTC-based collaboration services available today, many of them not too successful as they just took what was possible before with a plug-in and did it with WebRTC. The successful services (not all WebRTC based) provide a more comprehensive offering. I refer to Microsoft Lync that provides an enterprise telephony and collaboration solution or Slack that integrates nicely with many Web services in order to provide a compelling solution.

Service providers need to more than just adopt WebRTC in order to win here.

WebRTC will change customer service – This is B2C communication, in the form of some sort of Contact Center 2.0. Amazon has raised the bar on customer service but that has nothing to do with WebRTC, rather it has to do with state of mind. Integrating a video chat client into a tablet can be done without WebRTC, the hard part is providing the service not the technology. Given Contact Center overload, and in many cases, desire to move B2C to other channels such as chat and forums, the video service is relevant only to specific target audiences in specific segments (hint: $ value of the user being served).

Cloud-based MVNO and Telco OTT – This topic is broader than just WebRTC; it relates to the challenges Telcos are facing in their competition with OTT players. The solution is not technical as the same technology is available to all. The challenge is in agility and capacity to innovate in the service and business model. In these type of services there is a need for asymmetric business models rather than the traditional per-minute/subscription models.

Congestion issues

Staphane Tuffin from Orange Labs, presented congestion issues and why best effort service is not enough. He talked about managed VoIP and why it doesn’t apply for Web Communication service providers. Stephane proposed a solution for WebRTC network admission, identifying WebRTC traffic and ensuring QoS.

Telecom API

As part of the telecom API trend and launch of WebRTC API platforms by service providers, Maurizio De Paola from Telecom Italia presented the company’s EasyAPI, giving Web developers access to the Telecom Italia network. Maurizio showed a few examples of how services can combine users from Telecom Italia’s IMS network with non-Telecom Italia subscribers.

EasyAPI WebRTC Integration with Telecom Italia Network

 

This is nicely aligned with what AT&T announced in their developer summit a short while before CES. A Developer API platform adds the ability to extend user’s mobile identity to the browser.

WebRTC client side

Telecom OTT is a hot topic, John Neystadt from Telefonica presented TU Go, the Telefonica OTT service that runs on different devices and browsers. John presented the reasons for launching TU Go, primarily to allow Telefonica’s 26 operators to offer their subscribers a way to extend the usage of their phone number to other devices.

There were many technical points to consider such as authentication, signalling and transport (decided on a JSON-based proprietary protocol over WebSockets) and how to GW TU Go into their network (they built their own GW for that purpose). Transcoding was, of course, a big topic as Opus is CPU intensive.

Conclusion

While last year, service providers were talking mainly about trials and architectures that combine WebRTC with IMS, this year the main discussion was about real services and issues service providers encounter. That in itself is another milestone in the maturity of WebRTC.

the whole is greater than the sum of its parts

WebRTC Connectivity Solution with Focus on Quality and Scale

The whole is greater than the sum of its parts

the whole is greater than the sum of its partsWe released a PR today about the AudioCodes WebRTC Connectivity Solution. In this post, I want to provide a technical insight into this solution, explaining why the whole is greater than the sum of its parts.

A typical approach to connecting WebRTC with an existing enterprise VoIP network would follow one of these two architectural concepts:

  • Browser using Opus with some kind of proprietary signaling-> WebRTC to SIP GW -> SBC -> Transcoding to G.7xx -> IP Phone on a SIP network
  • Browser using G.711 with some kind of proprietary signaling-> WebRTC to SIP GW -> SBC -> [Optional: Transcoding from G.711 to G.7xx]-> IP Phone on a SIP network

Both cases introduce some issues

The external WebRTC to SIP GW carries a price.

Transcoding from Opus to G.7xx is something you would want to avoid unless there is no other option. Opus requires hefty CPU resources (much more than most audio codecs) and introduces quality issues while increasing CAPEX.

The other alternative, using G.711 over the open internet, is not a good option as G.711 wasn’t built for sustaining quality over unmanaged networks.

Traffic traverses between networks and different network types (WiFi, Wireline Ethernet, public Internet and enterprise networks) while devices themselves can vary as well. Handling of network impairments should be done in the entity that connects between these networks as it is familiar with the requirements of each and has the per-session knowledge of source and destination of traffic. While the two links above use VoLTE as an example in the post, similar issues arise when traversing WebRTC to non-WebRTC networks and the algorithms described in these posts serve the need of this architecture as well.

Another missing piece in typical deployments is the ability to monitor the traffic, know what is happening on the network and impact SBC decisions for quality improvements.

Putting quality and scale at the front

The solution announced was designed with these two factors at the forefront and that is what makes it stick-out of the crowd.

Integrated solution

In our solution, WebRTC is supported in the SBC itself. This includes WebSockets, DTLS and other WebRTC “special” behavior. This architecture simplifies deployment and management as well as reduces delay, (or in other words, increases quality).

Minimal transcoding scenarios

By supporting Opus in the AudioCodes IP Phone, we hold the rope at both ends. On the one hand, voice over the open Internet is using the Opus codec which is purposely built for this task. On the other hand, transcoding is not required as the IP Phone also supports Opus. This significantly increases the number of calls supported while reducing CAPEX.

Signaling

For signaling we use SIP over WebSockets. We found this to be a good solution when the goal is to connect to existing networks.

Another advantage of the decision to use SIP for signaling is the connection to WebRTC API platforms. WebRTC API platforms typically use proprietary signaling. For connecting to existing networks they build an adaptor which is typically SIP. This basic SIP implementation can’t connect to any existing enterprise SIP network but going through the SBC allows it to do so. While this SIP adaptor varies and is not always pure WebRTC over WebSockets, eliminating the need for this adaptor to implement a full WebRTC to SIP GW, simplifies this interconnection making this task easier.

Voice quality enhancement

As mentioned, traffic traversing between networks typically suffer from call quality degradation. There are different implementations of media engines on the client side that are optimized for the network with which the client plans to work. When the client connects with another client on a network that it wasn’t built to connect with, voice call quality issues increase. Having the SBC as a demarcation point between the networks allows for the utilization of the AudioCodes voice enhancement algorithms for improving audio quality.

Detect & correct

The AudioCodes Session Experience Management (SEM) not only monitors and detects voice call quality issues, it also works in harmony with the SBC to allow for smart, quality based, routing and quality improvements.

Why is this important?

A WebRTC GW doesn’t stand by itself; it needs a multitude of capabilities and supporting elements to ensure effective and high quality service. This is why the whole is indeed greater than the sum of its parts when bringing all that is required for an end-to-end WebRTC Enterprise connectivity solution.

Survey Results - Top VoIP Features

Survey Review: What VoIP Buyers are Looking For

Back in March, I wrote about enterprises moving their VoIP communication systems to the cloud and why it is more complex than simply putting a credit card number on a website. In that post, I referred to what Don Sadler from Software Advice wrote about 3 Ways to Keep Your VoIP Service From Going Down With the Internet.

The guys from Software Advice were kind enough to send me the results of their latest survey – Small Business Buyer View 2014 and I thought it would be worthwhile sharing the results with our readers.

Survey Key Takeaways

There are several findings in the survey I find interesting. Let’s go over them one by one.

More than half of prospective buyers were investing in business VoIP service for the first time.

Most of us, techy, VoIP savvy people, tend to believe VoIP is common in most businesses. I mean technology is around for over a decade now. How much time do those SMBs need to get going? For many of us, VoIP as we know it is old school; we are looking today at more advanced variations of VoIP like WebRTC that bring VoIP to the browser.

The reality is that most SMBs are not connected to VoIP services. Itzik Feiglevitch from AudioCodes presents more information about this in a diagram based on an analysis he has done.

Worldwide-SMBs-connected-to-VoIP-Services

The answers received in the survey fall nicely within the general point of this diagram – there is still a large market of SMBs out there that haven’t yet made the shift to VoIP.

Buyers were primarily concerned with reliability and scalability when evaluating new phone systems

Scalability is one of the advantages of going cloud but moving VoIP communication to the cloud doesn’t really increase reliability. There is the reliability of the servers themselves that typically improves because a VoIP communications cloud provider would normally have a stronger team of IT expertise that make sure the service is always on. However, having all the traffic go up to the cloud and back and the dependency on the link to be always on remains a challenge.

As explained before in my post All You Need is Cloud, the on-premise SBC would help mitigating this challenge by providing resiliency, optimized call routing, call cost optimization and QoE.

No buyers were interested in an on-premise IP-PBX, while a vast majority wanted a hosted solution

This is a clear trend we see across all businesses of different sizes and for different services – shift to SW solutions and cloud services. Having said that, concerns raised in the previous point must be addressed.

77% of SMBs are looking for services in the browser

Another interesting point that was not part of the “key Findings” presented at the top of the survey but did draw my attention, is the requirement for Web based solutions.

Many SMBs are probably not even aware yet of WebRTC but they are experiencing more and more services that are provided in their browser. Seeing that 77% actually preferred VoIP in their browser is an interesting indication for the potential of WebRTC in the UC for SMB space.

Survey Results - VoIP Deployment Preferences

Auto Attendant Tops the List of Desired Applications

The survey was seeking to learn the most important features buyers have on their decision checklist. The diagram below shows that Auto Attendant is well positioned on this list.

Survey Results - Top VoIP Features

Auto attendant is the way to navigate through a company’s directory instead of speaking with a real person who would transfer the call.

What if you could just say the name of that person, or what if employees could dial to anyone on their contact list, company list of suppliers and customers by just saying their name?

Based on AudioCodes advanced voice recognition technology, we provide this service today in the cloud, connecting to any PBX or hosted VoIP system.

Why is this survey important?

Understanding the criteria based on which SMBs make their buying choices is important. It reassures us about the “move to the cloud” trend but also clarifies the need to continue and provide reliability in the process.

Steve Austin

Why RCS Failed

[Post is better viewed on the blog Website]

How Standards Define Themselves to Death

Steve AustinSteve Austin, The Six Million Dollar Man, was – Better…Stronger…Faster… That was the hope of RCS (Rich Communication Services).

RCS started its journey at the GSMA in 2008 with the promise to allow service providers to deliver “OTT like” services with interoperability across service providers and managed quality of service as it is provided by those that own the network. By being better than what OTT can offer, users would vote for those services of the service provider.

Where was the market back then?

Looking at OTT on mobile at that time, things were still kind of preliminary.

Skype – Mainly used on desktops, Skype for mobile was in its infancy

WeChat – didn’t exist, launched in 2011

WhatsApp – Didn’t exist, launched in 2009

Facebook Messaging – Project Titan for user to user messaging was launch in 2010 and mobile messenger app was launched in 2011

Viber – Didn’t exist, launched in 2010

You get the point…

The important things to conclude from this data are:

  • Back then, when RCS started, there was still plenty of market share for it to capture
  • The OTTs listed above took the market by storm working vertically (a specific service) and not horizontally (many services for a specific segment/region)
  • They are all islands…didn’t wait for any standards
  • Oh…and they are all free

Why RCS lost to OTTs?

RCS has standardized itself to death in 2 ways.

It has insisted on trying to define and standardize everything possible rather than sticking to the bare minimum. Due to this, it lost a lot of time and left little room for flexibility to those who wanted to deploy it. RCS and the brand “joyn” defined everything all the way up to the user experience, what the address book should look like and what the user would see on each and every screen.

On top of that, RCS standardization tries to capture requirements from 2 camps, what was known previously as RCS and RCSe, later to be unified under the Blackbird standard version. This moves sounds great but Blackbird still includes different options for doing pretty much the same thing. When you define multiple ways to send a message and to implement presence based features, the life of the developer becomes more complex.

The promise of RCS was valid

The promise of RCS was, and even today still is a valid one. It has been proven to be valid through the success of OTT players such as WhatsApp that provide some of the RCS services but in a proprietary way.
Different from VoLTE, that has good technical and business reasons to replace Circuit Switched voice, RCS doesn’t enjoy the network ownership advantage, OPEX savings and enhanced user experience compared to using an OTT service for the same purpose.

The major benefit of RCS could have been cross service provider interoperability.

Other assumed benefits, such as a unified user experience, are not more than a pipe dream as not all device vendors will vote for what joyn has defined (i.e. Apple). Given that, we are left with an application, at least on some of the devices, and not a pre-integrated experience that comes pre-loaded on the device.

The enhanced address book and integration with the phone’s address book has come to the OTT applications user experience a long time ago. Given the ubiquitous nature of some of them (who of my friends doesn’t have WhatsApp? None!), the benefit of RCS interoperability is losing its advantage.

There was another option

The other option was to put time-to-service at a higher priority than top to bottom standardization work.

Time-to-service as priority #1 doesn’t translate to zero standards, it translates to standardizing only what really needs to be standardized as was done in WebRTC, while leaving the rest for the implementers.

In context of RCS that would mean APIs (e.g. send message, get contact…) for applications to use the RCS service for launching innovative services and things related to payload (e.g. how a file is transferred between clients).

Service providers and RCS server vendors would provide client SDKs based on which the service provider could launch its own services. Additionally, they would provide them to developers to build services with and integrate them into other applications.

Conclusion

Reality has proven that even in places where standards exist, once communication crosses between services and networks, it goes through mediation servers. We see more coupling between clients and servers today, something that contradicts the goal of standards, to enable zero vendor lock. This reality is apparent today in every type of real-time communication – UC, IP-PBX, VoLTE and WebRTC. There is no reason why it will be different in RCS and therefore waiting runs the risk of missing the opportunity.

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?