Original at http://blog.uppersideconferences.com/five-points-consider-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.

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.