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 signaling interface through which the Oracle Enterprise Communications Broker (OECB) receives and sends SIP messages.
- Consider any SIP options that you want to add.
- Configure any inbound and outbound manipulation rules that you want to use with this interface.
- Configure any S8HR profiles that you want to use with this interface.
Configure SIP-config
Use SIP-config to set the parameters that apply to all SIP call traffic on the Oracle Enterprise Communications Broker (OECB).
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.
- Create the TLS profile that you want for this configuration.
In the following procedure, use step 4 to add more SIP interface ports.
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 SIP Interface
configuration page displays the
Monitoring
filters object in the navigation pane, which you use to configure
individual filters.
- 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.
- The Add Agents configuration
page displays theMonitoring filters
configuration element to the Advanced section. Use it to apply filters to an
agent.
-
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.
- 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.
- Add one or more filters to the Monitoring object.
- (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:

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

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:
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.

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.

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.