SIP integration

This chapter is dedicated to the SIP integration capabilities of the Quobis communication platform. The Quobis communication platform provides integration for voice and SIP based on a dedicated roles on the Media Server focused on the media handler. So WebRTC and SIP are integrated as a single entity. There are several ways to integrate the platform with an existing SIP network:

  • SIP trunk integration: standard integration based on inbound/outbound calls, providing frictionless integration between WebRTC applications and an external SIP proxy.

  • Parallel SIP: a specific integration designed to lead the control of the dialplan and routing actions to an external SIP proxy.

SIP trunk integration

The SIP integration is done by the SIP proxy service. The platform users can be exposed to the SIP network using the SIP mappings. Standard integration based on inbound/outbound calls, providing frictionless integration between WebRTC applications and an external SIP proxy. The platform users will be identified on the SIP network with a SIP identity covered by the sipmappings service. During installation of the platform a SIP trunk is established manually on the SIP-proxy, to do that, you should configure your environment properly using the system configuration variables.

In summary, to enable the SIP integration you need to:

Routing of incoming calls with a SIP trunk setup

When a incoming call is received in the Quobis WAC via the SIP trunk, the QSS service will check the “To” field in the SIP invite message and will try to resolve its destination internally in order to know which user should be called. The QSS service will lookup for a SIP-mapping in the wac-core database that matches the “To” field:

  • If no match is found, the call will be then rejected with a “404 NOT FOUND” SIP message to the remote SIP party and no user will be called.

  • If there is a match, the QSS will route the call to the owner of this SIP-mapping. This owner can be an user (identified by a wac-user:uuid string) or a ringing-group (identified by a wac-group:uuid string).

Routing of outgoing calls with a SIP trunk setup

When a Quobis WAC user dials into a destination that does not match with another user or userGroup (for example, dialing a phone number) the QSS will check if this call can be routed via the external SIP trunk. In order to do so, the QSS.trunk service will apply a regex expression as set in the “trunk.match” configuration as explained here.

  • If the regex does not match, that means that the call is not allowed and the QSS will reject the call.

  • If the outgoing regex matches, the call is routed via the external SIP Trunk, setting this user SIP mapping as “From” field.

Headers in outgoing SIP calls

Since version 5.15, an outgoing SIP call will automatically include a set of SIP headers that could be used by the remote party:

  • X-WAC-Caller: caller’s WAC User ID

  • X-WAC-CallerDomain: caller’s WAC domain

  • X-WAC-Callee: callee SIP URI

  • X-WAC-Audiomixer: audiomixer hostname

  • X-WAC-SfuRoom: ID of the SFU videoroom

On the other hand, the applications can set another SIP header, X-WAC-Custom by setting this value in the Javascript SDK at inviteParticipant inside the context and must match the following regex: /^[a-zA-Z0-9:./-_@;<>=]{1,256}$/. If xWacCustom is not set, empty or does not match the regex filter, the value of the header X-WAC-Custom will be "None" (a warning log will be written in the latter case)

Example:

context:{
   xWacCustom: "myvalue-123456"
}

Parallel SIP integration

Parallel-sip is a Quobis Media Server feature that allows to reflect all Quobis application traffic on the customer SIP network. When this feature is enabled, the calls between WebRTC users are sent via SIP to VoIP network and, if the external network decides to forward the call to another WebRTC endpoint, Quobis platform will receive the call and locate the WebRTC user. Mainly it delegates all routing decisions (usually taken internally) to an external VoIP network. The benefits of this configuration are full SIP dialplan control, billing and control on a single point, signaling and traffic penalization and RTP and audio inspection. The following example shows a multiple-ringing scenario where some endpoints are on the provider network (VoLTE for example) and others on the Quobis platform (desktop or mobile apps).

_images/sip-parallel-integration.png

This SIP integration method starts with the standard SIP trunk integration, but it requires to enable the parallel SIP integration parameter.

This will enable the SIP signaling customization detailed on the SIP integration done by the QSS service. The outgoing INVITE request has a specific custom SIP header “X-WebRTC-Session” that contains an uuid, if it is returned in the incoming INVITE from SIP leg then Quobis can match the call from a WebRTC client and will add video using the Quobis MS. Quobis MS will send the audio to BroadSoft, so it is possible to manage a conference room in the SIP side or in the Quobis MS side.