Configuring Liberty Real-Time Communications

<featureManager>
       <feature>rtcomm-1.0</feature>
</featureManager>

<rtcomm/>

• Rtcomm MQTT Broker Connection Details: (host: localhost and port: 1883)
• Rtcomm root topic path: /rtcomm/
• SSL is disabled

<rtcomm messageServerHost="<brokerhostname>" messageServerPort="<brokerportname>" />

<rtcomm rtcommTopicPath="/rtcomm/"/>

You must pass the name and path you configured into the rtcomm client library on initialization along with the message broker address. The server creates the topic name and appends it to the topic path.

<rtcomm sharedSubscriptionPath="$SharedSubscription/rtcomm/">

Shared subscriptions must be configured when using call queues. Call queues rely on shared subscriptions to distribute messages across all the queue listeners. For example, if multiple help-desk agents are all listening on a single queue, shared subscriptions are used to distribute calls to one agent at a time.

Configuring backend services with the Rtcomm Feature

The Rtcomm Feature supports a number of backend services that include the following:

• Interactive Connectivity Establishment (ICE) server configuration: Specifies URLs that are sent to and used by the Rtcomm WebRTC clients when negotiating peer media sessions.
• Call Queue support: Rtcomm can be configured to support shared call queues, and enables the user to create a shared call queue where many agents can subscribe to a specific call queue and respond to customer calls. For example, you can dial into customer support for a specific product. Many agents can subscribe to the queue, but only one agent is chosen to respond to each call.
• Rtcomm Gateway: Adds the capability for connecting Session Initiation Protocol (SIP) with Rtcomm WebRTC endpoints for the exchange of audio and video streams. For further details on configuring an Rtcomm Gateway, see Configuring a Rtcomm Gateway.
• Alternate Endpoint Routing: Specifies that the user wants to route new sessions through an alternative endpoint.

Interactive Connectivity Establishment (ICE) Server Configuration

ICE is a technique that is used in computer networking that involves NATs (Network Address Translators) in Internet applications, such as, Voice over Internet Protocol (VoIP), peer-to-peer communications, video, instant messaging and other interactive media. In such applications, NAT traversal is an important component to facilitate communications that involve hosts on private network installations, often located behind firewalls.

The Node Controller provides ICE server configuration as a way to notify Rtcomm client nodes which ICE servers they can use when setting up peer-to-peer sessions with another client. WebRTC relies heavily on ICE servers to traverse firewalls, and being in production deployments it is critical to include support for ICE to ensure the highest possible probability for connecting endpoints.

The ICE server configuration is accessed through a service query request that is published to the connector topic name associated with a Rtcomm Feature. For more information about the Rtcomm service query, see the protocol details, GitHub lib.rtcomm.clientjs.

To configure various types of ICE servers, add the following property to the rtcomm configuration line in your server.xml file:

<rtcomm>
    		  <iceServerURL>stun:example1.hostname.com:8880</iceServerURL>
    		  <iceServerURL>stun:example2.hostname.com:8881</iceServerURL>
</rtcomm>

Third-Party Call Control

You can find all protocol details that define the message formats that are related to third-party call control in the GitHub repository. The lib.rtcomm.node-red related open source components are used to interact with these services.

Call Queue Support

Call queues provide a round-robin style interaction where many users can subscribe to a queue and another user can call the queue. Only one of the subscribed users will receive the call. This feature is enabled by defining queues and enabling Shared Subscriptions as previously shown in step two.

In order to configure call queues, configure the shared subscription path that is prepended to the rtcommTopicPath. This path is required by message brokers when using shared subscriptions. You can define the callQueues that are supported by adding the following configuration lines to the server.xml file:

<rtcomm sharedSubscriptionPath="$SharedSubscription/rtcomm/">
    <callQueue description="refrigerator" callQueueID="callQueueID2" timeout="500s"></callQueue>
</rtcomm>

The user can create as many unique call queues as they need. When configured, the shared subscription path plus the rtcomm topic path plus the topic name ("$SharedSubscription/rtcomm//rtcomm/callQueue") is subscribed to by agents to receive call requests from the server.

The following configuration items are available for each queue:

• Configure description: Specifies the verbal description of this call queue instance. This verbal description is returned in service query responses and can be used to better inform the client about the queue.
• Configure callQueueID: The endpoint ID that is associated with the call queue topic name, and that is the destination endpoint ID that a caller uses to call into a specific queue.
• Configure timeout: The number of seconds to wait before terminating a call that is waiting in a queue.

Alternate Endpoint Routing

Specifies that the user wants to route new sessions through an alternative endpoint. Using this option, you can subscribe to the alternateEndpointRouting topic name, such as /rtcomm/alternateEndpointRouting and are able to route new sessions to the proper endpoint. To enable this capability, add the following configuration line to the server.xml file:

<rtcomm alternateEndpointRoutingEnabled="true"/>

SSL configuration for Rtcomm

Make sure the environment is configured to use SSL between the Rtcomm Feature and the MQTT broker.

The SSL reference is the ID of the SSL configuration that is used to connect to the SSL-enabled MQTT Broker.

<rtcomm sslEnabled="true" sslRef="mySSLConfig" />