Experimentations performed with WONDER library

The WONDER library was used in different experimentations to validate the signalling on-the-fly concept and to evaluate what is the best approach to deliver new WebRTC services. Experimentations were performed by using a OpenIMS based testbed effectively operated by University of Patras in the OpenLab project. The Testbed was extended and configured to emulate four different WebRTC domains, namely:

1. imsserver.ece.upatras.gr domain that uses a WebSocket-based JSON signaling protocol that is translated into SIP protocol by a IMS-Signaling GW provided by Deutsche Telekom Labs. The IMS-Client acts as a SIP user agent and provides a JSON based API to the web-frontend. The main role of the IMS-client is to map this JSON API to SIP and vice-versa. Therefore there is no need for any SIP library in the browser.
2. The nodejs.wonder domain uses a JSON over WebSockets provided by a Node.js message server.
3. The asterisk.wonder domain uses SIP over WebSocket signaling protocol and it uses a non-IMS infrastructures backend based on Doubango SIPML5 and Webrtc2sip gateway solution integrated with Asterisk VoIP platform
4. The vertx.wonder domain uses a JSON over WebSockets signaling protocol provided by a vertx.io Message Server.

In general inter-domain experimentations were very successful, demonstrating that the signalling on-the-fly concept can be used to enable seamless interoperability between any WebRTC domains with no use of Network to Network Interface (NNI) standard protocols. A standard and protocol-agnostic Javascript API, like the WONDER API, should be used instead, promoting portability of Applications among different back-end solutions. Such approach, also benefits service providers by minimising dependencies between Applications and back-end vendors.

Until now, one of the rationales to use IMS based back-end solutions was the need to have NNI standard interfaces based on SIP to ensure full interoperability between different Service Provider domains. The successful demonstration of the signalling on-the-fly concept also means this rational is not valid anymore. At the end this means a web centric delivery approach using more agile and simpler architectures is feasible and paves the way for a future Web centric standard Service Architecture as an alternative to IMS. Looking into the summary experimentation results tables we may conclude Web centric delivery approach had more successful results than the IMS centric. This result can be seen as a surprise since IMS is a mature architecture with a large set of services available, while WebRTC is still in very early stages (not a standard yet). In reality WONDER experimentation didn’t take much advantage of existing services namely Presence and XDMS services due to the amount of integration effort it would demand. Nevertheless, this also indicates how IMS option implies further integration efforts when compared with the Web centric option.

Also, other relevant use cases like OSS/BSS related use cases were not covered by these experimentations which may affect the decision depending on existing deployed IMS assets already integrated with OSS/BSS systems.

Conversations involving multiple participants were experienced by using the Fully Meshed topology with Hosting. In this experimentation all peers have direct media and data streams established with all remaining peers and a single Hosting Messaging server is used i.e. all peers have a signaling channel established with the same Messaging Serve. The tests were successful performed in PTIN Web centric domain and DT Web centric domain for Enriched Conversations featuring Audio, Video, Chat, File Sharing and Screen Sharing. For IMS based domains the tests were not performed since the algorithm used would imply very high effort (months or even years) and probably it would not work with standard IMS endpoints.