Add-On Conferencing

This section explains how to configure the add-on conferencing functionality. It also includes a description of the SIP B2BUA functionality related to the SIP add-on conferencing. This description includes information about Contact header mapping and processing and Refer-to header processing.

Overview

SIP add-on conferencing lets you:

  • Use the Oracle® Enterprise Session Border Controller’s add-on conferencing feature for network architectures in which the conference initiator is located on a different network than that of the media server.
  • Configure the Oracle® Enterprise Session Border Controller to enable Contact header mapping for the Refer-To header.

Caveats

The following caveats are associated with add-on conferencing:

  • Contact header mapping is not replicated on the standby Oracle® Enterprise Session Border Controller in an HA Oracle® Enterprise Session Border Controller pair architecture.
  • Upon switchover, any conferences in progress remain in progress, but no new parties can be invited to or join the conference.
  • By default, the Oracle® Enterprise Session Border Controller does not map SIP Contact headers for reasons of performance.

Add-On Conferencing Scenario

The add-on conferencing scenario described in the following example applies to a network architecture involving the Oracle® Enterprise Session Border Controller and a media server that is located on a different network from the other conference participants. In this scenario, the Oracle® Enterprise Session Border Controller resides on a standalone network that connects two additional, separate networks.

Some network architectures have a media server on a different network from the one on which the phones reside. In this scenario, all requests and/or responses going from the phones (Phone A, Phone B, or Phone C) to Media Server D and vice versa are translated according to their corresponding SIP-NAT. All headers subjected to NAT are encoded and decoded properly as they traverse the Oracle® Enterprise Session Border Controller, except for the Contact header. This exception occurs because the SIP process on the Oracle® Enterprise Session Border Controller runs as a SIP B2BUA and not as a SIP proxy.

The SIP B2BUA re-originates the Contact headers of the User Agents (UAs) participating in SIP sessions with local Contact headers to make sure that they receive all future in-dialog requests. For an in-dialog request, the B2BUA can identify the dialog and find the Contact URI of the other leg of the call.

The Oracle® Enterprise Session Border Controller add-on conferencing feature applies to situations when the Contact URI is used in another dialog. In such a case, the SIP B2BUA will not be able to find the correct dialog that retrieves the correct Contact URI of the other leg if it needs to replace the Contact URI.

Using the SIP add-on conferencing, the SIP B2BUA on the Oracle® Enterprise Session Border Controller can map the Contact headers it receives to the Contact headers it creates. It can also convert the Refer-To URI to the correct value required for forwarding the REFER request.

SIP B2BUA Functionality

This section describes the role of the Oracle® Enterprise Session Border Controller’s SIP B2BUA in the add-on conferencing scenario that requires Contact header mapping for the Refer-To header.

When the Oracle® Enterprise Session Border Controller starts up, the SIP B2BUA reads and parses the list of options in the SIP configuration. If the refer to uri prefix is an appropriate value (it is not an empty string), the Oracle® Enterprise Session Border Controller will have a text prefix value the media server can use to denote a conference ID in its Contact header. With this information, the SIP B2BUA sets up a Contact header mapping.

You configure the Oracle® Enterprise Session Border Controller to enable Contact header mapping for the Refer-To header by editing the SIP config options parameter. The SIP B2BUA on the Oracle® Enterprise Session Border Controller can then map the Contact headers it receives to the Contact headers it creates.

Contact Header Processing

The Contact header mapping matches a Contact header that contains the refer to URI prefix to the corresponding Contact header that the Oracle® Enterprise Session Border Controller’s SIP B2BUA re-originates. Contact headers that do not contain the refer to URI prefix are not mapped (so that performance of the Oracle® Enterprise Session Border Controller is minimally affected).

Only the Contact header in an INVITE request and its 200 OK response are checked for the refer to URI prefix and added to the Contact header mapping. Contact headers appearing in other SIP requests/responses are not checked.

Target Mapping and Conferences

If the Oracle® Enterprise Session Border Controller is configured to enable Contact header mapping for the Refer-To header, then Contact header target maps are established for each individual call. The Oracle® Enterprise Session Border Controller’s SIP B2BUA uses these maps to allow the media server to connect the conference initiator with the conferenced-in parties.

Prior to terminating the call (hanging up), the conference initiator can contact other parties and invite those additional parties to join the conference. These other parties can join the existing conference because the target mapping for the conference is still in effect on the Oracle® Enterprise Session Border Controller.

Once the conference initiator hangs up, the Oracle® Enterprise Session Border Controller discards the mapping from the conference.

Refer-To Header Processing

When a Refer-To header is present in a REFER request that arrives at the SIP B2BUA after the incoming request is properly translated according to its SIP-NAT, the SIP B2BUA follows these steps:

  1. The SIP B2BUA parses the Refer-To URI.
  2. If the user part of the Refer-To URI contains the refer to URI prefix, the SIP B2BUA searches the Contact header mapping for a match of the user part of the URI.

    If the user part of the Refer-To URI does not contain the refer to URI prefix, the SIP B2BUA leaves the existing Refer-To URI unchanged.

  3. If the user part of the Refer-To URI contains the refer to URI prefix and a match of the Refer-To URI is found, the SIP B2BUA replaces the existing Refer-To URI with the URI of the corresponding Contact URI stored in the matched record. This replacement enables the NAT function to properly decode the replacement URI and change it back to the form originally received by the Oracle® Enterprise Session Border Controller. As a result, the correct conference ID is restored in the Refer-To header prior to the request being sent to its next hop.

    If the user part of the Refer-To URI contains the refer to URI prefix but a matched URI cannot be found, the SIP B2BUA will leave the existing Refer-To URI unchanged and will write a WARNING level log message to record the failure.

Add-on Conferencing Configuration

  1. In Superuser mode, type configure terminal and press Enter.
    ORACLE# configure terminal
  2. Type session-router and press Enter to access the system-level configuration elements.
    ORACLE(configure)# session-router
  3. Type sip-config and press Enter. The system prompt changes to let you know that you can begin configuring individual parameters.
    ORACLE(session-router)# sip-config
    ORACLE(sip-config)#

    From this point, you can configure SIP config parameters. To view all SIP config parameters, enter a ? at the system prompt.

  4. Type options followed by a Space.
  5. After the Space, type the add-on conferencing information in the following format:
    options refer-to-uri-prefix=”conf=”

    For example:

    ORACLE(sip-config)# options refer-to-uri-prefix=”conf”
  6. Press Enter.