Quobis has been integrating SIP networks using both proprietary solutions (Oracle, Ribbon, AudioCodes) as well as Open Source technologies (Kamailio, Asterisk, FreeSwitch) since 2006. When building the Quobis Communication Platform core called Quobis WAC (Web Application Controller) we decided to tap into this experience. We work with various 3rd party technologies to create a platform that would be able to talk to any of those solutions just as much as we usually work with them in an independent manner.

This allows both Telcos and large enterprises finding in Quobis WAC the perfect ally for exploring the capabilities of WebRTC technology without having to sacrifice any of their existing communications solutions based on SIP Networks. This is the key aspect of the Quobis WAC, reusing the existing “legacy” networks and expanding them with the features found in modern Unified Communications solutions  such as multiparty audio, video, chat, screen sharing among others. To deliver these features Quobis WAC needs to interwork with SIP networks in various ways.

In order to do so, the IB (Interconnection Broker) is used along with the SIP Identities. The IB is an internal role of the Quobis WAC, designed to allow integration in voice SIP networks. The SIP Identities are a basic user parameter that, attached to Quobis WAC entities (such users or groups), allows the IB to properly identify the calls and conferences and handle their signaling accordingly.

In this post, we will explain the three integration options currently offered by Quobis Communications Platform using the Quobis WAC:

• Sip Trunk
• SIP REGISTER
• ParallelSIP

The most basic integration is via SIP trunk. In this case the IB of the Quobis WAC acts as a SIP-WebRTC gateway routing the calls to and towards the SIP network in order to reach PSTN destinations.

This simple integration provides all expected characteristics of a SIP trunk such as:

• Header customization
• Transcoding
• Ad-hoc triggers
• IP Authentication
• Call encryption and authentication

Let’s see a few call examples. First, one call between two WebRTC endpoints (two apps, one browser and one mobile). Another example with a call between a WebRTC endpoint and finally, a SIP number and a call between a WebRTC user and a PSTN endpoint.

In the case of calls between two app users using Quobis Communication Platform, the signaling will stay within the Quobis WAC. Every interaction will be handled internally, so the signaling will never reach out to the SIP network.

In the case an App user interacts with a user in the SIP network, the signaling will go through a SIP trunk. It does not matter whether it is an incoming or outgoing call, the IB as a key element of the infrastructure will accept the calls and route them towards the correct endpoint.

If the call comes from outside the SIP corporate network, the Quobis WAC will allocate the destination WAC entity (it can be a user or a conferencing room) and will route the call accordingly. If the users are registered in various devices these will ring as well.

A more advanced solution would be to reflect the WebRTC endpoints as regular users of the SIP network. By delegating the user registry as a SIP REGISTER we can provide presence and also make the apps behave like another endpoint for the network.

This sort of integration allows us to decide what to do with the call signaling; we can delegate them to the SIP network, or we can keep them inside Quobis Communications Platform, allowing only outgoing SIP or PSTN calls to go outside the platform and towards the existing network.

Figure an app (ie. Quobis Collaborator). When the app makes login, it is done through HTTPs and Websockets, at this moment, the IB (part of the Quobis WAC), will send the registration info present on the SIP identity to the external SIP REGISTER. This will provide contact info and presence to the SIP network. At the same time the Quobis WAC keeps all the information from the assigned endpoints and their availability, this way when an user receives a call rules can be applied regarding which devices are to ring in the case that this user has presence active in various devices

As an implementation detail, every WebRTC endpoint will share the same IP as contact, which is the Interconnection Broker IP, this means that all the incoming  calls will have the IB as destination. This element, along with the WAC internal elements, will resend and adapt the signaling and the media so the call is correctly routed to the destination WebRTC endpoint.

This last integration alternative uses our Quobis’s own proprietary technology. Using our experience with SIP Networks, we have developed a solution that acts as an OTT (over the top) solution. The Quobis Communication Platform handle all the media with the twist that all signaling and audio media is handled by the SIP network..

In this scenario, we are fully leveraging the existing network assets and to do so we use ParallelSip to decouple the video media, the audio media and the signaling. The platform sends to the SIP network what is supposed to work with which is handling audio media and signaling whilst Quobis WAC deals with the rest of the media and WebRTC signaling that the network is not supposed to handle.

This approach allows us to use every functionality that the SIP network has already built in (OSS, TAS, AAA,…) without requiring any change. All the great features offered by an operator like: call forwarding, call barring, voicemail, IVRs, accounting, billing systems, performance data… All of those functionalities are directly usable. A new array of devices using apps (like a browser) will work in conjunction with the existing SIP phones. The behavior will be unchanged, for example you can use the same short codes, using the same admin interfaces or the same user provisioning.

This integration method works best in complex networks. For example, in a contact center scenario a Click to Call button could be embedded in an app or browser and use the current automatic call distributor (ACD) to route the calls received from that app within the Contact Center network. Because the audio and video streams are separated, the Contact Center can use all the network assets it is currently using such as call recorder, billing tools or BIs designed to work in voice only networks. 

In Quobis we are committed to taking advantage of the existing resources our customers have in place, using the pre existing infrastructure when designing a solution is a key element of sustainability in network evolution.

This mantra and our extensive experience working with VoIP networks provides us with the right tools to solve the gaps between new technologies (like WebRTC) and the traditional and still majoritary traditional networks.

From a simple SIP trunk to ParallelSIP, we offer tailor made solutions for communication use cases with always a mind in maintaining in the network all the existing elements that still provide value.

 If you are looking for options on how to integrate new features on your IMS (or enterprise) SIP network, contact us. Enabling video in an existing SIP network, offering APIs and SDKs in order to allow third parties to create their own app solutions does not need to be a nightmare. If you would like to discuss a new potential use case, or you are looking at other potential features for your SIP network, feel free to contact us.