Ericsson WebRTC H.264 Interop

Ever Wondered About WebRTC Interoperability With H.264

HW Codecs on iOS join the game

Different webRTC implementations need to interwork. People will use different devices with different browsers and they expect it to work! There will for example be different implementations of H264 , and naturally users demand the different implementations to interwork.

Ericsson WebRTC H.264 Interop

Ericsson has recently been able to demonstrate successful interop between independent WebRTC implementations that use different  H.264 video codec implementations.. The test was done between a Bowser using the hardware accelerated H.264 (decoder) API exposed by iOS 8 on certain CPU’s, while Firefox used the OpenH264 library provided by Cisco.

Look at this blog from Ericsson Research for more info: http://www.ericsson.com/research-blog/context-aware-communication/openwebrtc-bowser-interop-firefox/

Ericsson will be showcasing OpenWebRTC and Browser at the WebRTC Conference & Expo 2014 in Paris Dec 16-18.

 

 

Read more
Did-The-Telco-Bell-Ring

What is WebRTC for Telcos?

Did the Telco bell ring?

Did-The-Telco-Bell-RingI often read statements from the “Internet advocates” or from vendors around Telco’s and their views/mistakes in relation to WebRTC, but barely any share experience from within.

I would like to share my thoughts on how the “democratization of voice” is seen by those who (still) earn a large portion of their annual revenues from it. What does it mean when various departments within an operator “want WebRTC” all of a sudden – what is “WebRTC for Telcos” – because sometimes, it is quite far from the obvious.

To follow up my last blog, let me share some first-hand thoughts how I perceive this (of course not only from within the company I work for, but also when I exchange thoughts with peers from various other operators). Some point out the believe the dial tone is still considered more important than actual web development or highlight that to some extent operators are bad for WebRTC. Parts of these arguments are often true. I asked myself: Why do operators most of the time start with telephony or consider IMS first when thinking about WebRTC?

Natural evolution vs the need for radical change

Well, why actually would they not start with it – that is after all the area they know and earn money from? Is it not natural that classical Telco people working day in/day out with SIP and deploying their brand new IMS consider using it for WebRTC as well (especially since IMS is mostly built for telephony)? I fully agree that we need a dramatic shift, but I wonder if anyone thought about how this can happen if not step by step, and how education inside the old structures can be done best in order to do so.

Change will not happen radically for everything, for everyone, for all our services, for our thinking, our culture – not just yet anyways. By doing a radical change in offering communications services, we can of course bet on the future already now, but which manager would risk revenues for the next years just to be the forerunner? Not to mention whether the people are ready (both from their knowledge and expectation perspective) to drive this change. I think it won’t happen overnight, it most likely cannot happen overnight, but that does not mean it is not happening at all.

Taking this into account: What is more natural than evolving your existing services and trying out new things when possible? An internal trial here and there perhaps, some laboratory deployments showcasing some of the functions the fancy new boxes have, but that are not used yet, or a student working on an innovative topic. As outlined by me before, it is easier than ever to try things out. Unfortunately that seems to happen mostly in the labs in a creative way and does not yet impact the thinking of the main organization unit dealing with (tele-) communication at the moment. This has to change!

How does the average Telco learn about WebRTC

Coming back to examining why it is that Telco’s seem to start always with classic click-to-dial use cases and are so keen on getting their IMS hooked up with WebRTC I asked myself: How did WebRTC actually “infiltrate” the average operator fellow’s mind set (of those looking at it at the moment – it is still far from being the majority within an operator) in the first place? Web 2.0 has not done that, neither have apps or Flash, or a move to IP in the core with NGN a while ago. What happened – why now?

At the moment I would say this has happened mostly through vendors. Our current technology vendors (mostly traditional ones that also provided technology decades back) come, present roadmaps, evolution of our currently running services, and also new boxes or features. These presentations are either given to technology and marketing together or separately. I can bet that certainly every single presentation of this kind contains WebRTC.

Here lies also one of the reasons for the Telco’s perception that IMS & WebRTC is closely related: Their first contact point is not Google, the larger Internet vision, or an excitement/drive for new things. They touch base with WebRTC mostly exclusively in relation to IMS and traditional services or the “classical” well-known suspects of “new” IMS services through their known partners.

It is not ignorance of alternatives to IMS or insistence towards SIP as signaling protocol, it is simply because many do not even know there is a need to think for alternatives. For the more conservative parts, using open-source software such as OpenSIPS/Kamilio for SIP in their core or thinking about IMS alternatives is already considered extravagant, and now those folks should question current approaches as a whole, even for their main services and change overnight? This is highly unlikely if you ask me.

Those who did not understand the transition yet and still believe in core legacy principles will most likely not change their view just because of WebRTC.

Operator services have not changed tremendously when the iPhone and apps came along.
Why should it happen now – just because of WebRTC?

Let’s assume people in charge of technology or products heard about WebRTC as described, think (in the context they have learned about it) about new possibilities, and come to ask one day to “add WebRTC to something”.

Now what does that mean?

  • They think about a service that should be accessible in browsers, e.g., an existing service such as “classic telephony”. Usually this means the request does not come along with any further requests. People don’t even think about “more” – new possibilities
  • They like the idea of adding voice or video to some website where this does currently not exist as a feature, but do not yet think about the potential that actually brings along
  • People operating new telephony platforms that evolved to IP will naturally hear about WebRTC, and since it is all IP the assumption of “just adding another end point” is rather obvious. Now they want also “the fixed line accessible with WebRTC”
  • Try out new “WebRTC capabilities” that have been part of a delivery (e.g. an SBC, media server, RCS platform) and simply explore what is now possible “on the web”

I have yet to meet somebody from an operator that till now requests any of the “real” WebRTC differentiators, such as contextual awareness, anonymity, or better codecs, and knows about that being worked on actively outside of some lab.

Chances: Enhance the existing & explore the new

So where do I see chances in the mid-term?

I tried to highlight that already in an earlier post: The Internet world will certainly teach us how to embed communications into the web and will do a much better job than us – despite our history with implementing real-time communication.

It is very crucial not to forget the value that can be delivered by evolving traditional services. New enhanced services are the ones mostly expected from an operator (by that I mean the evolution of services we currently offer) and also the ones where we can calm down controlling by keeping to some extend traditional less-risky operator business models. Maybe not per-minute pricing for the average consumer (but hey, they have flat rates anyways and just need to be properly identified), but for example “call center minutes” towards businesses can easily be charged even if the request is coming from a browser – at least for some time. And if existing traditional services are enhanced, maybe the current subscription will also not be cancelled just yet, even though alternatives arise. I do not suggest to keep this as long term strategy or that no change is needed; rather the opposite: Change is overdue, we’ve missed out before, let’s use our chances now and start with the easiest use cases immediately (it should be easy thanks to “All-IP” one might think).

Looking at embedding communications is also something I would try as an operator, but finding their real potential that will result in commitments of investing into it will take time I believe. I urge absolutely everyone to try gathering experiences in this area, but not to have too high expectations in the beginning. The cheering about the future value is unfortunately something that needs proven figures and an adaptation in the ”Telco mindset” to be fully understood. Motivations here are often cost savings or the simple unavailability of any budget for a new product idea (“Hey, we want video communication but have no budget – maybe we can use WebRTC”) rather than completely and thoroughly evaluated use cases. To follow up the call center use case – clearly the context can be exploited here and value can be added, but less with “pure end to end WebRTC” in the short term.

What is worth to mention is that I restricted some of my operator arguments by adding the apodosis “… unless it happens in their labs”. I believe that while WebRTC has its place in the labs, the new way of thinking has to make its way very, very quickly into the normal business units. I believe it is very important to gather experiences, not only for the development of so called new businesses, but even more importantly to reshape the existing business and adapt the new technology, new mindset step by step in as many areas as possible. This does in fact not even have to mean “do WebRTC” as understood by Google or anyone in the community. It simply means re-think current strategies how to best evolve legacy services and align with the new technologies and potentials that are available. We missed out on apps – let’s not miss out again!

Outlook and Conclusion

What are my expectations from the upcoming conference?

  • Share as many experiences from within as I can. Hopefully by then I can talk about some of our work as well.
  • See how other operators approach it. Learn about their experiences, less from technical perspective than from cultural, integration, coexistence of the old and new
  • Provide a balance between traditionalists/conservatives and the forerunners for whom change cannot come fast enough. I know where many concerns come from and am trying day in, day out to understand them and try to address them and clear them in a sensible way, and move forward – one step at a time J

Black-and-WhiteI summarized many points in this initial post that are worth a follow up, and I will try to highlight where I see the potential first and also tangle why some things just are not moving as fast as one would expect. My presentation will also highlight lessons learned so far (what is harder, what is easier) and look at where WebRTC – or rather the evolution of new paradigms that come along with it – can realistically be seen “at the average Telco” in the short term.

Remember: I believe the story is not black or white. For any shade of gray you want to draw, however, you need to understand and have both colors to do so and achieve the expected outcome.

Read more
WebRTC Orchestration-Quobis

Five Points to Consider for Real WebRTC Deployments

There are nowadays lots of ongoing proof of concepts and field trials involving WebRTC, having some of them reached the production stage. In this post we are going to explore which problems arise when you move from the lab to a production environment. These are five points to take into account when you are working with real field deployments of WebRTC.

Hide complexity of the user device

WebRTC is designed to run in any type of device and platform with the sole requirement to use a browser that supports it. Unfortunately, and even though they are implementing the standard specification, different platforms and browsers present unique peculiarities that require some degree of customization by the applications running on top.

In addition, recent movements from Microsoft indicate that they will support ORTC instead. This forces web communication applications to have their own version for Internet Explorer. Despite this, it’s possible to use elements to hide this particular implementation via a middleware that make applications work on any device and browser with no changes in the code.

WebRTC Orchestration-Quobis

Hide complexity of vendors

WebRTC does not mandate anything for signaling and it’s up to the application developer to select or even define the appropriate signaling mechanism for each environment and use case. This has been discussed in details in a Webinar focusing on WebRTC Standards. Gateway vendors have chosen different ways to manage signaling from standard based solutions, that are being adopted by some vendors and the open source community, to proprietary solutions based on SDK or proprietary APIs.

To deal with this fragmentation the industry is working on abstraction libraries like ORCAjs.

Manage the integration with existing services

It is easy to Implement WebRTC services, as you can see from demos that are available on the Internet. The big problem is when you want to create a WebRTC based service that is fully interconnected with your existing platforms, especially when you need to deal with authentication, authorization or accounting.

There are different possibilities out there to authenticate users, from anonymous calls where authentication is not needed (for instance, in some click-to-call solutions where only DoS protections or temporal accounts are dynamically provided), to the use of strong telco (or enterprise) authentication mechanisms (like AD, HSS or others)

Authorization or the management of user privileges and billing are other points to take into account. Service providers need to federate with their operation systems and policy managers, so the new WebRTC architecture will need some connectors to OSS, BSS and other existing elements.

Manage multi-tenancy services

Services providers and telcos are willing to offer new services to corporate customers that help to retain the revenues from this market. In this scenario it’s critical to have the possibility to offer services that are able to work in a multi-tenancy way. This means being able to run different instances of the solution to allow all the administrators of each company to manage different features like users, privileges and services.

Prevent security concerns

Some new potential threads appear with the use of WebRTC and part of the traditional VoIP attacks will be inherited.

Ad-hoc attacks in WebRTC include access to physical devices. It is easy to figure out how risky it would be to allow any web application to access users’ webcam or screen without asking permission of the user.  Other attacks on WebRTC include cross-domain and DoS. This means that you can connect to a server whose domain is different from the domain you downloaded the code from. This gives the necessary flexibility to make this web communications useful, but it also could allow some kind of distributed Denial of Service attack, that should be prevented.

A tool is needed to provide security mechanisms that prevent attacks and fraud in WebRTC sessions.

In summary

These are some of the points that are not part of the current feature lists of WebRTC gateway vendors, that should be looked at when planning real field deployments. Different user devices, signaling protocols, gateway vendors, user topologies or user privileges may represent a huge complexity in the delivery of WebRTC services and a potential threat in terms of security.

Read more
Keeping things simple requires complicated effort

WebRTC MTI Video Codec: More is Less

Webinar Poll Results Different From My Opinion

Last week I held the second Webinar in the series of WebRTC Webinars for Upperside Conferences. This time it was with Victor Pascual Avila who gave an update about standards. We had 2 live sessions, one in the morning EMEA time and second in the morning US time.

In case you missed it, slides are available as well as the recording.

Keeping things simple requires complicated effortPrior to the Webinar I wrote about the areas WebRTC standards cover and more importantly, why it is good WebRTC defines only the minimal must requirements, As an opening to the Webinar, I presented that diagram and spoke about the “Less is More” advantage in WebRTC standards.

In a nutshell, we want any WebRTC application to run in any WebRTC enabled browser, thus, W3C standardization work is important.

Additionally, we want one WebRTC implementation to work with any other WebRTC implementation and therefore definition of transport, security and media codecs are important, AKA, work done in IETF.

Since WebRTC is built with Web in mind and for the Web, similar to other Web technologies, the way the browser communicates with the server, structures data exchanged and acts upon that data is in the hands of the application.

This is how innovation thrusts.

Poll Question: What should be the mandatory video codec in WebRTC?

After Victor spoke about the different point of views of vendors and segments on the mandatory to implement (MTI) video codec in WebRTC we presented this poll question. Options to choose from were:

  • H.264/H.265
  • VP8/VP9
  • Both should be mandatory
  • There should be no mandatory video codec
  • Don’t care, just make up your mind…PLEASE

To my great surprise, in both sessions, the majority (around 40%) selected option 3.

The need for a mandatory video codec

The preferred option for connecting a session is with media flowing directly between the 2 browsers. In some cases, due to FW/NAT complexities, there is a need for media to go through a TURN server. In both of these options media flows securely between the browsers and even when there is a need for a forwarding server in-between, it doesn’t (and can’t) touch the media, decrypt it or transcode it.

Achieving this requires both browsers to support the same codec.

If they don’t, a transcoding server will need to be placed in the middle, be part of the communication breaking privacy and overloading servers with CPU intensive transcoding and media decrypt/encrypt tasks.

Considerations for selecting the mandatory video codec

There are a few parameters to take into consideration when selecting the MTI codec:

  • Quality
  • HW support
  • License
  • Royalties
  • Porting
  • Future codecs

 

Quality

All in the eyes of the beholder there are different comparisons and opinions depending to a large extent on what camp/company one is part of.

In my eyes, both options are of good enough quality. I don’t see a significant enough difference that would make the decision lean towards one option over the other as long as comparison is apples to apples (VP8 to H.264 and VP9 to H.265, network conditions and additional resiliency tools).

At the end of the day, the WebRTC MTI video codec decision is more of a business decision rather than a technical one.

HW support

H.264 is the standard codec used today for real-time communication. As a result of that, it is supported in many chipsets and mobile devices. This in turn allows for HW acceleration of the CPU intensive encoding and decoding tasks but that is right only for some of the devices and surely not for Apple devices.

On top of that, if an application wants to connect between a WebRTC client and a traditional video conferencing/UC client H.264 will probably be the codec found on the latter.

Having said that, chipset vendors are adding VP8 support as it is already supported by Imagination Technologies, the vendor providing this IPR to most of those vendors.

VP9 is also making its way to HW devices so this gap is about to be closed.

On the traditional video communications front, vendors are adding VP9 as an additional codec but that may take time.

License

Both H.264 and VP8 come with a permissive BSD license.

Google took care of that for VP8 and Cisco took on the challenge to open source H.264.

For the next generation codec, VP9 and H.265 it is a different story.

Google continues the same path of BSD open source for VP9. H.265 on the other hand comes as GNU GPL 2.0 or via a commercial license.

Royalties

Patents and royalty payments are one of the key questions to ask. As WebRTC lives in the world of the Web it is required to allow any developer to build his application without the need to worry about patent infringement. This includes not only applications that run in the browser but also mobile and other devices as they all need to interwork.

VP8 – Google made VP8 royalty free and handled all the patent issues. New issues may come-up once in a while but Google is committed and big enough to solve them. The royalty free “feature” comes with no strings attached, you can port the codec to any platform and still enjoy the Google umbrella.

H.264 – Cisco has also committed to free developers from the H.264 patent burden but the story here is different as in order to seek shelter under the Cisco umbrella you must use their binary package. This works well for browsers but what if I’m developing a mobile application and want the codec to be part of it? What if I want to port the codec to an embedded device and make changes to the codec? In these cases the developer will need to bear the royalties of H.264.

The work Cisco has done for freeing H.264 is well explained by Cullen Jennings in this video.

VP9 – Google has gone the same path.

H.265 – No indication for a similar arrangement by Cisco or others.

Porting

Since all 4 codecs come in some sort of open source license it is technically possible to take the code and port it yet licensing and royalty considerations apply as detailed above.

Future codecs

The decision between VP8 and H.264 will have a good chance to impact the decision of the future codec (VP9 or H.265) and therefore the considerations and differences detailed above (mainly in the licensing and royalty front) must be taken into consideration.

Mandating both is a bad option

So we agree there needs to be a decision.

We reviewed the different parameters to consider.

Why not go for both as the majority of the audience on the Webinar recommended?

There will be no need for a server in the middle to transcode and break privacy.

The 2 browsers will always be able to negotiate which codec to use and life will be great.

Not exactly!

Forcing the implementation of both H.264 and VP8, and in the future H.265 and VP9 increases complexity. WebRTC is open source and it will find its way into different types of devices, including proprietary embedded devices (think of a WebRTC enabled sensor, camera or medical device).

Moreover, licensing and royalty/patent issues will arise in some cases for H.264, and based on current status, in all cases for H.265.

Conclusion

Having H.264 added to the browsers can be a good thing. It will still be royalty free and will avoid transcoding and privacy breach needs in cases where connecting to traditional video communication systems. Additionally, it will eliminate the need to download it as some sort of plug-in in cases the application vendor decides to use it.

Having said that, adding H.264 voluntarily to the browser doesn’t mean H.264 needs to become mandatory.

My choice for MTI would be VP8/9 accompanied with a strong recommendation to add H.264/265 when possible and this is due to 2 simple reasons:

  • Licensing and royalty considerations are extremely important for allowing proliferation of WebRTC applications and services. This alone is a good enough reason
  • VP8/9 is becoming the video codec of the web and that is the natural environment of WebRTC
Read more
WebRTC Architecture

WebRTC Standards: Why are They Important?

A year a go I wrote a post talking about Where Standards Matter for WebRTC. As Victor Pascual Avila and I are getting ready for the WebRTC Standards Update Webinar I thought it is a good time to get back to this topic and look at it from a different angle.

Where are the standards when it comes to the Web

There are many misconceptions about what exactly is in the scope of WebRTC and what isn’t. As a result of that, there are different opinions about the parts in WebRTC that should be standardized. This arises mainly when speaking with VoIP and telecom people as we (yes, I’m one of them) are used to the case where everything is standardized, from top to bottom.

Looking at this in perspective of the Web. When a Web developer builds an application there is only one area where standards apply to him, the things that need to run in the browser (i.e. HTML, CSS and JavaScript). Browsers must be compatible in this area, implement the same APIs and yield the same user experience. How information that is exchanged between the browser and the server is structured is completely up to the developer building the application.

This reality of a closed client-server world with standards for client side implementation that allows users to use whatever browser they choose is one of the things that enabled the speed of change and innovation we are all used to in the Web. This stands in contrast to the slow rate of advancement in the telecom world where all needs to be standard.

WebRTC is all about the Web

Taking the Web application example above and implementing it for WebRTC makes it seem very clear that communication between the client and the server doesn’t need to be standardized. How SDP, session context information, user specific data… are sent from the browser to the server is rightfully left for the application, as every application will have different requirements.

Having said that, things related to making sure WebRTC will run on all browsers must be handled through standards. This part will be the main focus of our coming Webinar.

WebRTC Architecture

The diagram above shows this quite clearly. The areas in WebRTC that are and should be standardized are only those related to the interfaces and capabilities of WebRTC itself. This in essence means:

  • The JavaScript APIs (northbound) – this makes sure a WebRTC application will run in any browser that supports WebRTC
  • On the wire protocols – in essence, this is how voice, video and data streams are exchanged peer-to-peer between browsers. Examples of such are transport protocols, security mechanisms chosen and mandatory voice and video codecs. If this wasn’t standardized, communication between browser of brand A would need to go through some mediation box in order to communicate with browser of brand B

If you are interested in hearing more about WebRTC standards, what are the latest advancements and what is still underwork join us for this free Webinar. To accommodate as many time zones as possible we will have 2 live sessions so head over to this information page and register for the one that best fits your preference.

If there are specific topics you would like to be covered in the Webinar or questions you would like to be answered please feel free to Contact Us.

Read more