SIP Interface Settings

A SIP Interface is an application layer interface logically residing "over" a network interface. The SIP interface defines the transport addresses (IP address and port) upon which the Oracle Enterprise Communications Broker receives and sends SIP messages. You can define a SIP interface for each network to which the Oracle Enterprise Communications Broker is connected. Note that these networks must be within the Oracle Enterprise Communications Broker's Network Interface subnet. SIP interfaces support UDP, TCP and TLS transport.

In addition to defining a SIP interface's network participation (Port), you can also define forking and other functionality (Interface settings).

Proxy Registrations

The Oracle Enterprise Communications Broker can proxy registrations when it receives REGISTERs for domains for which it is not a registrar. The user enables this functionality within the sip-interface. By default, the Oracle Enterprise Communications Broker rejects the registration.

The Oracle Enterprise Communications Broker's sip-interface configuration includes a checkbox titled Proxy Registrations, with which the user can enable this function. When checked, the Oracle Enterprise Communications Broker proxies the registration towards the intended registrar. When unchecked, the Oracle Enterprise Communications Broker responds with a 403: Unauthorized message.

Configure a SIP Interface

The SIP interface defines the signalling interface through which the Oracle Enterprise Communications Broker (OECB) receives and sends SIP messages.

Consider any SIP options that you want to add.

In the configuration, you specify how the OECB handles SIP messages and you can add SIP options.
  1. Access the SIP Interface configuration object.
    Configuration, SIP Interface, Interface.
  2. On the Modify Interface Settings page, do the following:
  3. Click OK.
  4. Save the configuration.

Restricting Session Initiation

The Oracle Enterprise Communications Broker can restrict the set of end stations that can initiate sessions to those originating via active session agents and previously registered users. By default, the Oracle Enterprise Communications Broker does not restrict session initiation. The user enables this functionality within the sip-port.

The Oracle Enterprise Communications Broker's sip-port configuration includes a checkbox titled Allow session agents and registered end-points with which the user can restrict session initiation. When checked, the Oracle Enterprise Communications Broker responds to session initiation by endpoints that are not behind an agent or not already registered with a 403: Unauthorized message.

Configure a SIP Interface Port

A SIP interface port configuration defines the transport address and protocol that the Oracle Enterprise Communications Broker (OECB) uses for sending and receiving messages through a SIP interface. You can apply a TLS profile to the configuration, and you can limit SIP requests from session agents and registered end points. You must configure at least one port per SIP interface. You can optionally configure multiple SIP ports per SIP interface. For example, suppose you configure the OECB to receive calls by way of TCP and to send calls by way UDP, you must configure a SIP port for each protocol.

Configure a TLS profile

In the following procedure, use step 4 to add more SIP interface ports.

  1. Access the Ports configuration object. Click Configuration, SIP Interface, Port.
  2. On the SIP Ports page, click Add, and do the following:
  3. Click OK.
    The system displays the SIP Ports page with a list of SIP interface ports you configured.
  4. Optional—Click Add to add another SIP interface port.
  5. Click Back.
    The system displays the Configuration tab, where you can do the following:
    • Continue configuring the OECB.
    • Save the configuration.

Optional—Configure SIP monitoring.

SIP Monitor and Trace Filter Configuration

The SIP Monitor and Trace function allows you to monitor SIP sessions for notable events and display the results in the Oracle Enterprise Communications Broker (OECB) SIP Notable Events summary. Such information may help you perform troubleshooting. For more targeted monitoring, you can configure filters on particular users and addresses on the OECB, and on a specific agent.

The OECB Configuration page includes the following objects for configuring SIP Monitoring filters:
  • The SIP Interface configuration page displays the Monitoring filters object in the navigation pane, which you use to configure individual filters.

    This screen capture shows the navigation pane of the Configuration tab, with the Monitoring Filters object highlighted, and displaying the filter config dialog.

  • The Monitoring object on the SIP interface configuration page displays the Monitoring filters element in the dialog. Use it to apply filters to the OECB.

    This screen capture shows the navigation pane on the Configuration tab with the Monitoring object selected, and the SIP monitoring configuration dialog.

  • The Add Agents configuration page displays theMonitoring filters configuration element to the Advanced section. Use it to apply filters to an agent.

    This screen capture shows the Monitoring Filters dialog that the system displays after you click Add in the SIP monitoring dialog.

  • Note:

    After the P-CZ2.0.0m4 release, the system does not support the former "Enable SIP Monitor and Trace" setting. You must re-configure SNMP event traps through the dialogs described in this topic.
Use the following filter configuration process for both new installations and upgrades.
  1. Create one or more filters in the Monitoring Filters object. You may use an asterisk character as a filter, if you want to monitor all session data.
  2. Add one or more filters to the Monitoring object.
  3. (Optional) Add one or more monitoring filters to an agent that you want to monitor.

SIP REFER

SIP REFER provides the Oracle Enterprise Communications Broker with the ability to terminate SIP REFER messages and perform attended or unattended call transfers. You can enable REFER termination at both the agent and SIP interface, with agent configuration taking precedence. You can also configure the SIP interface to send NOTIFY messages for provisional responses.

SIP REFER Method Call Transfer for ECB

The Oracle Enterprise Communications Broker supports a handling mode for the REFER method that automatically converts a received REFER method into an INVITE method. This allows the Oracle Enterprise Communications Broker to transfer a call without having to proxy the REFER back to the other UA.

The Oracle Enterprise Communications Broker has a configuration parameter giving it the ability to provision the handling of REFER methods as call transfers. The parameter is called Enable REFER termination. When this feature is enabled, the Oracle Enterprise Communications Broker creates an INVITE message whenever it receives a REFER. The Oracle Enterprise Communications Broker sends this INVITE message to the address in the Refer-To header. Included in the INVITE message is all the unmodified information contained in the REFER message. The previously negotiated SDP is used in the new INVITE message. NOTIFY and BYE messages are sent to the UA upon call transfer completion. The user configures this function at the SIP interface or agent with agent configuration taking precedence.

If a REFER method is received containing no Referred-By header, the Oracle Enterprise Communications Broker adds one, allowing the Oracle Enterprise Communications Broker to support all call agent screen applications.

This SIP REFER method call transfer feature supports the following:

  • Both unattended and attended call transfers.
  • Both successful and unsuccessful call transfers.
  • Early media from the Referred-To party to the transferee.
  • REFER method transfer from different sources.
  • The REFER event package as defined in RFC 3515. This applies for situations where multiple REFER methods are used within a single dialog.
  • Third party initiated REFER method signalling the transfer of a call by associating the REFER method to the dialogue via the REFER TargetDialog.

Unsuccessful Transfer Scenarios

The Oracle Enterprise Communications Broker does not successfully handle the following failed, unusual, and unexpected transfer scenarios:

  • The new INVITE to the Referred-To party gets challenged, the Oracle Enterprise Communications Broker does not answer the challenge. It is treated with the 401/407 response just as any other unsuccessful final response.
  • The header of the REFER message contains a method other than INVITE or contains URI-parameters or embedded headers not supported by the Oracle Enterprise Communications Broker.
  • The Oracle Enterprise Communications Broker shall allow the Referred-To URI that happens to resolve to the same next-hop as the original INVITE went to, to do so.
  • The Oracle Enterprise Communications Broker ignores any MIME attachment(s) within a REFER method.
  • The Oracle Enterprise Communications Broker recurses (when configured to do so) when the new INVITE sent to the Referred-To party receives a 3xx response.
  • The transferee indicated support for 100rel, and the original two parties agreed on using it, yet the Referred-To party does not support it.
  • The original parties negotiated SRTP keys.
  • The original parties agreed on a codec using a dynamic payload type, and the Referred-To party happens to use a different dynamic payload number for that codec.

Call Flows

The following ladder diagram shows an example of call flow for an unattended call transfer:

This ladder diagram shows unattended call transfer from the calling party to the ECB to the SIP Proxy to the IVR to the ACD/SIP server to the Agent and back.

The following ladder diagram shows an example call flow of an attended call transfer:

This ladder diagram shows the attended call transfer from the calling party to the ECB to the SIP Proxy to the IVR to the ACD/SIP server to the Agent and back.

Configure SIP REFER Method

The Oracle Enterprise Communications Broker (OECB) allows you to set REFER termination on a per-agent and/or SIP interface basis. Agent configuration takes precedence over SIP interface configuration.

SIP Interface configuration includes the Enable REFER termination checkbox. Select Enable REFER termination to allow this agent to support SIP REFER method call transfers.

Follow the procedure below to enable SIP REFER termination support, setting the SIP interface first, if applicable to your deployment:

  1. Click Configuration, SIP Interface.
    The OECB displays the Modify Interface settings dialog.
  2. Select Enable REFER termination.
  3. Click Configuration, Agent, Edit.
    The OECB displays the Modify Agents dialog.
  4. Select Enable REFER termination.
  5. Save and activate the configuration.

180 and 100 NOTIFY in REFER Call Transfers for the ECB

When you configure the Oracle Enterprise Communications Broker (OECB) to support REFER call transfers, you can enable it to send a NOTIFY message after it has sent either a 202 Accepted or sent a 180 Ringing message. If your network contains elements that comply with RFC 5589, and so expect the NOTIFY message after the 202 Accepted and each provisional 180 Ringing, you want to set the Send NOTIFY messages for REFER Provisional Responses to either initial or all, according to your needs.

Without this parameter changed from its default (none), the OECB does not return send the NOTIFY until it receives the 200 OK response from the agent being called. If the time between the REFER and the NOTIFY exceeds time limits, this sequencing can cause the OECB’s NOTIFY to go undetected by devices compliant with RFC 5589. Failures during the routing process can result.

The following ladder diagram shows how a sample call flow times out when the Send NOTIFY messages for REFER Provisional Responses parameter is not set.

The following ladder diagram shows how a sample call flow times out when the Send NOTIFY messages for REFER provisonal responses is not set. The call times out when too much time passes between the REFER, the second INVITE, and the answer,.

When you compare the call flow above to the following one depicting the scenario when the OECB has the Send NOTIFY messages for REFER Provisional Responses changed from its default, the difference is that the OECB now responds with a NOTIFY in response to the 202 Accepted and it sends another one after the 180 Ringing. This prevents the time out and allows the event to be diverted successfully.

The following ladder diagram shows how a sample call flow times out when the Send NOTIFY messages for REFER provisonal responses is set. The call does not time out when too much time passes between the REFER, the second INVITE, and the answer

Sample Messages

In compliance with RFC 5589, the NOTIFY message with 100 Trying as the message body looks like the sample below. Note that the expires value in the subscription state header is populated with a value that equals 2* TIMER C, where the default value of TIMER C is 180000 milliseconds.

NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 73 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: active;expires=360
Content-Type: message/sipfrag
Content-Length: ...
SIP/2.0 100 Trying

Also in compliance with RFC 5589, the NOTIFY message with 180 Ringing as the message body looks like the sample below. Again, the expires value in the subscription state header is populated with a value that equals 2* TIMER C, where the default value of TIMER C is 180000 milliseconds.

NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 73 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: active;expires=360
Content-Type: message/sipfrag
Content-Length: ...
SIP/2.0 180 Ringing

Also in compliance with RFC 5589, the NOTIFY message with 200 OK as the message body looks like the sample below.

NOTIFY sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 74 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag
Content-Length: ...
SIP/2.0 200 OK

180 and 100 NOTIFY Configuration

You can apply the Send NOTIFY messages for REFER Provisional Responses setting to the sip-interface. By default, the Oracle Enterprise Communications Broker (OECB) only sends the final result NOTIFY message.

Do the following to enable 100 and 180 NOTIFY messages in REFER call transfers.

  1. Click Configuration, SIP Interface.
    The OECB displays the Modify Interface settings dialog.
  2. In the Modify Interface settings dialog, select one of the following settings for the Send NOTIFY messages for REFER Provisional Responses parameter.
    • None—Disable NOTIFY for REFER provisional responses.

    • initial—Send an immediate 100 Trying NOTIFY, and the final result NOTIFY.

    • all—Send an immediate 100 Trying NOTIFY, plus a notify for each non-100 provisional messages the OECB receives; and the final result NOTIFY.

  3. Save and activate the configuration.