Configuring a Rtcomm Gateway

The Rtcomm Gateway adds the capability for connecting Session Initiation Protocol (SIP) with Rtcomm WebRTC endpoints for the exchange of audio and video streams.

Stabilized feature: The rtcommGateway-1.0 feature is stabilized. There is no strategic alternative. You can continue to use the rtcommGateway-1.0 feature.

About this task

The Rtcomm Gateway (GW) is useful when you require federating between the Rtcomm network and different vendors' networks. The other network can be a network of WebRTC endpoints, which is using a different method for signaling, or it can also be a different network of Voice over IP (VOIP) devices or even the Public switched telephone network (PSTN). Such federation is possible as long as the other network provides an edge GW element that supports the widely adopted SIP protocol.

The Rtcomm Gateway supports both Interactive Connectivity Establishment (ICE) for SIP (based on RFC 5245) and trickle ICE for SIP (based on theIETF draft). This draft is still marked as a work in progress so this implementation might change in the future in accordance to this draft progress.

Procedure

Add the rtcommGateway-1.0 feature in the server.xml file to enable the Rtcomm Gateway capability.
```
<featureManager>
	  <feature>rtcommGateway-1.0</feature>
</featureManager>
```
The Rtcomm Gateway is configured in the rtcomm section. This configuration enables you to define the following:
1. Instructs the GW on where to direct the SIP message that is translated from an incoming Rtcomm signaling message. There are three options:
  - Nothing is configured (default): The GW tries to resolve the destination based on the SIP address that was provided as the target on the Rtcomm WebRTC client.
  - sipContainer=true: The GW sends the message to the internal Liberty SIP servlet container port. This message gets routed to a JSR 289 application that is installed on the Liberty server, according to the standard application router rules. For further details, see Session Initiation Protocol (SIP) applications in Liberty.
  - ExternalPR=host:port: Tells the GW to route the translated SIP message to an external destination of a SIP Proxy or Registrar.
2. Define the SIP endpoint for incoming SIP messages. Messages coming on the SIP endpoint get translated to Rtcomm signaling and delivered by the GW to the WebRTC endpoint, that is resolved from the SIP initial message requestURI header.
Review the following additional considerations for implementing Rtcomm Gateway.
1. Sending messages from Rtcomm WebRTC to SIP.
  - REGISTER: When sending an Rtcomm register message from the WebRTC client that is using the DOCUMENT message, it is possible to use a SIP address of record (AOR) as the client topic. If such a SIP URI is registered, the GW converts that to a SIP REGISTER request and tries to route it according to the rules defined by the configuration. The Contact header is constructed from a Rtcomm Gateway SIP endpoint address, as configured for the Liberty server, and the user name as set in the AOR.
  - Rtcomm START_SESSION message can be directed to a SIP address as well. In this case, the START_SESSION toEndpointID field is populated by a URI, which starts with either of 'sip', 'sips', or 'tel' scheme prefixes, then the message is translated to a SIP INVITE and sent according to the rules configured. All subsequent messages in the dialog are translated to SIP according to the signaling scenario defined and the relevant Request For Comments (RFC). This rule applies to both the Interactive Connectivity Establishment (ICE) and trickle ICE signaling scenarios.
2. Sending messages from SIP to Rtcomm WebRTC.
  The GW currently supports only INVITE dialogs. A SIP INVITE that is coming into one of the configured GW SIP endpoints is translated to an Rtcomm START_SESSION message and sent to the resolved WebRTC endpoint. The WebRTC endpoint is resolved according to the following rules:
  - Look for the INVITE requestURI SIP address. If the endpoint was registered as a client topic by a previous Rtcomm DOCUMENT message, then this is where the START_SESSION message is directed to. For example; if the Rtcomm endpoint was registered as sip:bob@x.y.z.w as a DOCUMENT topic, then any INVITE with sip:bob@x.y.z.w requestURI is converted to START_SESSION and directed to that MQTT topic.
  - If the previous step did not resolve a destination, look for only the user part in the SIP requestURI. If the endpoint was registered, the START_SESSION is directed to that topic. For example; if the Rtcomm endpoint was registered as bob, then for any <domain> in the requestURI is bob@domain.
    Note: Unsupported SIP requests return with a 405 error response.
3. Transcoding and advanced media server functionality.
  - The Rtcomm Gateway does not support handling the media plane and will not perform actions such as transcoding between SIP VOIP and WebRTC endpoints codecs. This means that at its basic use, the GW allows only federation between different WebRTC endpoints, or endpoints that use similar codecs and streaming protocols, such as the WebRTC standard.
  - To make full use of the Rtcomm Gateway capabilities, it is possible to augment the Liberty server with a feature that provides APIs for a media server connector based on the JSR 309 standard. With this feature, you can create and install an application on the Liberty server that uses a media server for transcoding and streaming protocol translation, in addition to many other advanced features such as recording, announcements playback, stream mixing for multi-party A/V conferences and many more. Details can be found in the JSR 309 specification.The application is using SIP Servlets (JSR 289) with JSR 309 and mediates between the SIP network and the Rtcomm WebRTC network. This application only requires the configuration of internal routing in the server.xml file; for example:
```
<rtcomm messageServerHost="<brokerhostname>" messageServerPort="<brokerhostport>"
             <gateway sipContainer="true"></gateway>
</rtcomm>
```
    Note: Make sure that the SIP ports where incoming SIP messages are directed to are those of the SIP Servlets container endpoints and not the GW endpoint. See Administering Session Initiation Protocol (SIP) in Liberty.

Example

In this example, the incoming WebRTC messages are directed to an external SIP endpoint that might be a proxy or registrar, such as 1.2.23.2:5063.

<rtcomm messageServerHost="<brokerhostname>" messageServerPort="<brokerhostport>"
   <gateway sipContainer="false" externalPR="1.2.23.2:5063" allowFromSipEndpointRef="webrtc2, webrtc"></gateway>
</rtcomm>

Incoming SIP messages can be on the webrtc and webrtc2 SIP endpoints. In the following example, webrtc is using the default ports that are 5060 and localhost.

<sipEndpoint id="webrtc"></sipEndpoint>
<sipEndpoint id="webrtc2" sipTCPPort="5067" sipUDPPort="5067" sipTLSPort="5068" host="*"></sipEndpoint>