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……..

Waves - Communications Webification

Things I Picked Up at WebRTC World East 2014

[Post is better viewed on the blog Website]

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

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

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

The Chasm - Technology Adoption Lifecycle

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

Waves - Communications Webification

 

Keynotes

Google, Serge Lachapelle

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

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

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

 

Microsoft, Bernard Aboba

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

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

 

Avaya, Gary Barnett

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

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

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

 

TalkBox, Ian Small

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

 

AudioCodes at WebRTC World Atlanta

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

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

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

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

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

2 Box WebRTC GW

Why not All WebRTC GWs Were Born Equal

[Post is better viewed on the blog Website]

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

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

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

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

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

Why is this important?

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

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

WebRTC GW as an External Box

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

What is the down side of a two box solution?

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

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

The GW functionality

GW functionality includes:

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

The SBC functionality

SBC functionality includes:

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

Putting it all together

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

WebRTC GW in an SBC

What is the alternative architecture?

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

WebRTC GW

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

The Prophet Jeremiah

Identifying Toll Fraud is Harder Than finding a Needle in a Haystack

What Does That Have To Do With Big Data?

[Post is better viewed on the blog Website]

The Prophet JeremiahAt the time of creation, God spoke with man directly, without any proxy. God spoke to Adam, Eve, the snake and even handled the first murder interrogation by himself when asking Cain “Where is your brother Abel?” After this, when there were too many people, God abandoned the one-on-one approach and started sending his messages and commands through prophets. Then came the kings who listened to the oracles and ignored the prophets.

And then came the scientific revolutionaries, visionaries, dreamers and most recently, the predictors. Unlike prophets, scientific revolutionaries, visionaries and the dreamers, the predictors look to the past to predict the future. And the deeper the predictor studies the past, the clearer he can envision the future.

The predictor is a by-product of an emerging technology – big data. I am sure that big data was invented by a male, since it’s totally built on a male character trait –don’t throw anything away that you may one day need.  This is probably the reason why another male invented large garages. Unlike the traditional rational data bases, big data deals with voluminous amounts of unstructured data (not organized by any method), which is gathered from many sources in large quantities, various formats and varying qualities. There are four main characteristics related to big data (aka the four Vs); Volume, Velocity, Variety, Volatility. Allow me to add a simple analogy from my life to describe the difference between rational and irrational data bases. When I return from the grocery I pile ALL the vegetables and fruit in the refrigerator inside their plastic bags. My lovely and more rational wife washes them all, skins the melons and watermelon and cuts them into pieces, peels the vegetables and sometimes cuts them as well, to be ready for making salad or cooking.

Mr. Gurdeep Singh Pall is the Corporate Vice President for Skype and Lync at Microsoft Corp. Mr. Pall just returned to the Lync unit, after spending the past two years working on Artificial Intelligence projects within Microsoft.  Pall used his opening keynote at this year’s Lync Conference to describe how the work of analytics and Bayesian predictions, will eventually make its way into communications systems. In practice, Singh Pall said, “We can actually predict who you will be calling in the next five minutes.”

Big data and Unified Communications & VoIP services

Unified Communications and VoIP services collect a lot of raw data; this data is worthy of analysis due to its wealth of intelligence. Many companies are increasingly aware that there is information that can be collected and refined to an essence which can be used for performance optimization and network design improvements. UC and VoIP big data analytics will be the key element in converting the big data to a tool which ensures cloud-based VoIP service, including privacy, security, toll fraud, performance, cost and more.

So what can you do with voice analytics?

  • VoIP analytics will build its own multi-layered picture of the network’s topology derived from the big data over time.
  • VoIP analytics will provide Network & Users Profiling
  • VoIP analytics will provide Advanced Call fraud detection and attack prediction
  • VoIP analytics will provide Advanced Multi-Dimensional Cost Analysis

Toll Fraud detection and prevention using big data analytics

Call fraud is associated with significant revenue loss and is hard to discover. I read that discovering call fraud in the masses of call records is more difficult than finding a needle in a haystack. Actually, that’s an easy problem to solve; you know how a needle looks like and by adding enough manpower to do the looking you can eventually find it.  But fraud calls are similar to legitimate calls, so if you can’t identify a fraud call, no matter how much manpower (or CPU power in this case) you put on the job it will be impossible to detect. It’s more like trying to find a specific strand of hay in a haystack.

A common approach to detect call fraud is based on examining accounts made up of several statistics that are computed over a specific period. For example, average call duration, longest call duration, and numbers of calls to particular countries might be computed over the past hour, several hours, day or several days. Account summaries can be compared to thresholds for each period, and an account whose summary exceeds a threshold can be queued and analyzed for fraud.

VoIP analytic fraud detection is designed on a statistical principle of dynamic VoIP fraud detection. The algorithm is based on Tracking Account Behavior which is able to alert or terminate the fraudulent call as it occurs. The algorithm will relay runtime & historical attributes gathered per user, group of users, sites, SIP interface and etc. The VoIP analytics create a signature of predicted usage behavior for each user/group/interface, update the statistical model with each call and score calls for fraud using predicted behavior as the baseline. When a call exceeds a predictive user signature boundary, the VoIP analytic may take actions as per the configuration.

The VoIP fraud detection analytic is built on three stages:

  1. Training – The analysis of large numbers of enterprises of various types such as: Unified Communications, Contact Center, etc. Based on this information, the VoIP analytic Fraud Detection System creates preliminary statistical information which is later segmented per the organization’s characteristics.
  2. Adaptation – Adjustment of the statistics collected in the previous stage to the specific organization. This is done by comparing in real-time the statistics to actual call activity of the organization.
  3. Test – Each call is compared against the statistical call pattern in real-time. Calls that don’t match the pattern will result in fraud alarms with the probability (confidence) grade.

 Conclusion

We are often tempted to impose the way we see things through the prism of our own life experiences on our friends and family while in actuality, what we are really doing is judging them for the way they see things.  A friend once told me that life experience is like a flashlight hanging on your back when you are going forward, in other words, useless.  That may be true. But in the case of Big Data analytics, the system’s life experience is the basis for predicting a better future.