Key features of the WebRTC Application Controller

31 December 2015
by iago.soto | The architecture or modules of the WebRTC Application Controller may vary from one vendor to another. In this chapter we will focus in those elements that are common to all the different implementations. We can group these features in six points.

Abstraction Layer

All the WACs include an abstraction layer that helps to hide the complexity of the different implementations of the WebRTC API in browsers. This element is critical due to the fact that is mandatory to make applications work in a similar way with any devices and web-browsers, helping the web developer to avoid customizations related to the different types of endpoints. Another point to take into account is signaling complexity. Different vendors adopted different approaches, from standard signaling protocols to monolithic APIs or SDKs. Once more, it is important to prevent web developers to have problems with this and the WAC is the framework that make applications work with any gateway vendor with no changes. Different WAC vendors may vary in the terminology but this abstraction layer may include also the modules that handle authentication, billing, user provisioning. etc. that can be implemented in the WAC or federated with existing systems via connectors or APIs that will be explained later.

Connectors with existing services

The WACs are designed to deal with different existing systems of the core network of the service provider or enterprise. The implementation of real WebRTC solutions in these scenarios makes necessary the used of systems to deal with the authentication of users, service validation and exposure and billing reports. Common requests in terms of authentication demand validation with HSS (in case of IMS networks of telcos), active directories, LDAP or the use of OAuth or OpenID to leverage the services offered by Identity Providers such as Google and Yahoo. Some WACs include capacity to connect with different common vendors or solutions to manage authentication, so it is important to choose the one with the capacity to deal with the method we need to implement. These connectors could also be used to get the contact lists of the different users (for instance, from Microsoft Exchange platforms) or connect with policy servers and service exposure manager to get information about the privileges of the users and information about the operation expected by the WebRTC services.

Service API

The connection with OSS and BSS used to be done via server mode API. This allows systems integrators of operation and billing systems (in the case of service providers) to have some methods to request information about the deployed WebRTC services or just to feed the WAC with updated information about the subscribers. For instance, OSS will use this API to add and remove users, groups, user privileges,etc. In the case of BSS, they use the API to request information about the usage of the WebRTC service via call detailed records. Finally, WebRTC gateways can use also this API to ask the WAC about if a user that is demanding a WebRTC connection has been properly authenticated. If not, they will block the traffic. In this case, this is not possible to enable connectors for all the different implementation and customizations of OSS BSS, ACD or other internal systems, so these elements are the responsible to federate with the WAC via the exposed Service API.

Developer API

The WAC, as the element that acts as web server, is hosting all the different WebRTC applications. This element is designed to allow third parties to use their own applications. For this purpose, it offers its own API to allow third parties (web developers) to adapt or create their application that can run in any device and architecture. This API has methods to manage basic communications setting and actions (make or answer a call, etc). What makes the WAC interesting by comparison with other vendors is the fact that this API is based in industry standards and avoids vendor lock-in of traditional gateway vendors. Different bodies and associations are defining telecom and enterprise APIs (OMA, GSMA, ATIS, etc) that are being adopted by gateway and application controller vendors. These standard API guarantee that any application is going to work with no adaptations when you are using vendors that implement these methods. It’s important to note that some vendors are making announcements about the support of a standard API but they make some improvement (additional methods) to provide extended functionalities. If you want to be sure that the applications is going to work with any vendor, you must limit to use the standard methods and calls.

Storage database

An element always present in WebRTC Application Controllers is a database, that can be hosted in the same server or in an external element. A database is needed because WACs are called to manage services that require data storage. An example are the call detail records, where this information must be hosted for a period of time. In fact, the web application can request data from the CDR to show information to the users (think in a WebRTC corporate endpoint where one of the possibilities is to know details of the last calls. Chat history is another of the uses of the database. It is great to have information of the previous messages via chat (including those of previous sessions) before starting to write a new message .In addition, this database is going to be the responsible to store files that are transferred in the collaboration sessions. Finally, the WAC can deal with authentication if this feature is not federated with existing systems. Users and passwords can be stored locally in the WAC. Similar to this are the contact lists of the users that can be stored locally or connected with a Microsoft Exchange or others. In the first case the WAC will use the database to store this information.

Management tools and stats

The WAC include a module to manage records and stats, where general and local administrators can get information about the behaviour of the different web applications (concurrent calls ongoing, etc) and, in the case of the manager of the WAC, get detailed KPIs about the performance of the systems (use of memory, etc). Finally, it provides a user interface (usually based on web of CLI) to help all the different types of administrators to deal with the configuration of the services, from providing parameters to define a service to and specific user to remove a complete service or company in case of WAC managers.
Next article

Quobis to demonstrate Sippo WAC at WebRTC conference Paris

Vigo, Galicia, Spain, 24th November 2015.- Quobis, the leader in WebRTC applications for service providers and enterprise, today announced its participatio[...]