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 Registration
By default, the Oracle Enterprise Communications Broker (Communications Broker) rejects a REGISTER request from a domain for which it is not the registrar. You can enable the Communications Broker to proxy such registration requests by way of the Proxy Registration control in the SIP Config configuration.
In the SIP Config configuration, select Proxy Registration to tell the Communications Broker to proxy the registration towards the intended registrar. When you deselect Proxy Registration, the Communications Broker responds with a 403: Unauthorized message.
Global SIP Timers
Note:
you can also set timers and counters per SIP interface.
Overview
SIP timers define the transaction expiration timers, retransmission intervals when UDP is used as a transport, and the lifetime of dynamic TCP connections. The retransmission and expiration timers correspond to the timers defined in RFC 3261.
- init timer: is the initial request retransmission interval. It corresponds to Timer T1 in RFC 3261.
This timer is used when sending requests over UDP. If the response is not received within this interval, the request is retransmitted. The retransmission interval is doubled after each retransmission.
- max timer: is the maximum retransmission interval for non-INVITE requests. It corresponds to Timer T2 in RFC 3261.
The retransmission interval is doubled after each retransmission. If the resulting retransmission interval exceeds the max timer, it is set to the max timer value.
- trans expire: is the transaction expiration timer. This value is used for timers B, D, F, H and J as defined in RFC 3261.
- invite expire: defines the transaction expiration time for an INVITE transaction after a provisional response has been received. This corresponds to timer C in RFC 3261.
If a final response is not received within this time, the INVITE is cancelled. In accordance with RFC 3261, the timer is reset to the invite expire value when any additional provisional responses are received.
- Inactive dynamic conn timer defines the idle time of a dynamic TCP connection before the connection is torn down. Idle is defined as not transporting any traffic. There is no timer in RFC 3261 corresponding to this function.
SIP Timers Discreet Configuration
Previous releases controlled various SIP timers with a single setting, Trans Expire, available in both SIP Config and SIP Interface modes. When executed in SIP Config mode, the command essentially established a global default transaction expiration timer value. Executed at the SIP Interface level, the command established a local, interface-specific value that overrides the global default.
Specific timers controlled by Trans Expire are as follows:
- Timer B, the INVITE transaction timeout timer, defined in Section 17.1.1.2 and Appendix A of RFC 3261, SIP: Session Initiation Protocol.
- Timer D, the Wait-Time for response retransmitals timer, defined in Section 17.1.1.2 and Appendix A of RFC 3261, SIP: Session Initiation Protocol.
- Timer F, the non-INVITE transaction timeout timer, defined in Section 17.1.2.2 and Appendix A of RFC 3261, SIP: Session Initiation Protocol.
- Timer H, the Wait-Time for ACK receipt timer, defined in Section 17.2.1 and Appendix A of RFC 3261, SIP: Session Initiation Protocol.
- Timer J, the Wait-Time for non-INVITE requests timer, defined in Section 17.2.2 and Appendix A of RFC 3261, SIP: Session Initiation Protocol.
The Initial Inv Trans Expire parameter enables user control over SIP Timer B for initial INVITE transactions. Other timers, namely B for non-initial INVITEs, D, F, H, and J remain under the control of Trans Expire.
Use Initial Inv Trans Expire in the SIP Config to establish a global, default transaction timeout value (expressed in seconds) used exclusively for initial INVITE transactions.
Allowable values are integers within the range 0 (the default) through 999999999. The default value, 0, indicates that a dedicated INVITE Timer B is not enabled. Non-default integer values enable a dedicated Timer B and set the timer value.
The default value retains compatibility with previous operational behavior in that Timers B, D, F, H, and J all remain subject to the single timer value set by Trans Expire. However, when Initial Inv Trans Expire is set to a supported non-zero value, SIP Timer B as it applies to initial INVITEs, assumes that value rather than the value assigned by Trans Expire. This functionality is available in both SIP Config and in SIP Interface objects.
If a dedicated Timer B is set in the SIP Config, you can use initial-inv-trans-expire in the SIP Interface to establish a local interface-specific Timer B timeout value that overrides the global default value.
Timer to Tear Down Long Duration Calls
In most call scenarios, long duration calls are terminated with the expiration of this timer, but there are some cases where a call can stay connected for a longer duration. For example, if a user connects to an IVR service and does not hang up the phone receiver properly, there is no way for the network provider to free up the IVR resources if the user devices send session updating requests. To prevent this situation, set the Session Max Life Limit timer in the SIP Config, which starts when the call or session is established and does not reset for any session update, keep-alive or system switchover. On expiry, the call is torn down if it’s in established state.
The Session Max Life Limit parameter can be provisioned in the following configuration elements, in order of precedence from highest to lowest: Session Agent, Realm Config, SIP Interface, and SIP Config. Its range of values is {0-2073600} seconds with an additional special case value of “Unlimited”, which is treated as the highest possible value. The default value is 0 (no timer).
Difference between 0 and Unlimited
No timer is created when Session Max Life Limit is configured to either the value 0 or “Unlimited”, so no timeout can occur. The difference between the two values is how they are handled when determining which value of Session Max Life Limit to use when there are several specified within the various configuration elements.
When a session is created the timer examines both the ingress side and the egress side and, in cases where both sides have a configured value for Session Max Life Limit, uses the side with the lower (stricter) value. On each side, the system reviews the configuration elements relevant to the session and uses the value of Session Max Life Limit from the configuration element with the highest precedence (Session Agent, then Realm Config, then SIP Interface, and lastlySIP Config).
- When the value is set to 0, the configuration element is ignored and the next configuration element in the precedence chain is looked at.
- A value between 1 and 2073600 (24 days) or the value “Unlimited” is treated as a valid configured value. In this case the system will not move onto the next element in the precedence chain and the value is used in the final comparison between the egress and ingress values. The value “Unlimited” is viewed as the highest possible value, and therefore is considered greater than any other value it is compared against.
For example, on the ingress side the value of Session Max Life Limit in Realm Config is set to 86400 and the value of Session Max Life Limit in Session Agent is set to "Unlimited". The Session Agent value has a higher precedence than the Session Agent value so, therefore, the value “Unlimited” is used for the ingress side. On the egress side the value of Session Max Life Limit in Realm Config is set to 43200 and the value of Session Max Life Limit in Session Agent is set to 0 (no timer), so the value of Session Max Life Limit in Realm Config is used. When compared against the ingress side the value 43200 is less than “Unlimited”; therefore, the value set for the timer is 43200.
Add a SIP Interface
The SIP interface defines the signaling interface through which the Oracle Enterprise Communications Broker (Communications Broker) 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 SIP Config
Use SIP Config to set the parameters that apply to all SIP call traffic on the Oracle Enterprise Communications Broker (Communications Broker).
Restricting Session Initiation
The Oracle Enterprise Communications Broker (Communications Broker) can restrict the set of end stations that can initiate sessions to those originating through active session agents and previously registered users. By default, the Communications Broker does not restrict session initiation. You can enable the functionality in the SIP Port configuration.
The SIP Port configuration includes theAllow Session Agents and Registered End-Points control that you use to restrict session initiation. When selected, the Communications Brokerresponds 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 (Communications Broker) 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 Communications Broker 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 (Communications Broker) 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 Communications Broker, 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.
Figure 3-2 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
Communications Broker.
Figure 3-3 Modify Filter Config
- The Add Agents configuration page displays the
Monitoring
Filters configuration element to the Advanced section. Use it to
apply filters to an agent.
Figure 3-4 Monitoring Filters
-
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 Real Config, with agent configuration taking precedence. You can also configure the Refer Notify Provisional parameter to send NOTIFY messages for provisional responses.
SIP REFER Method Call Transfer for Communications Broker
The Communications Broker supports a handling mode for the REFER method that automatically converts a received REFER method into an INVITE method. This allows the Communications Broker to transfer a call without having to proxy the REFER back to the other User Agent (UA).
The Communications Broker provides the Enable REFER Termination parameter for provisioning the handling of REFER methods as call transfers. When you enable ISP REFER Method Call Transfer, the Communications Broker creates an INVITE message whenever it receives a REFER. The Communications Broker sends the INVITE message to the address in the Refer-To header. The INVITE message includes all of the unmodified information contained in the REFER message. The Communications Broker uses the previously negotiated SDP in the new INVITE message, and sends the NOTIFY and BYE messages to the UA upon call transfer completion. You configure this function at the SIP interface or agent with agent configuration taking precedence.
When a REFER method is received containing no Referred-By header, the Communications Broker adds one, allowing the Communications Broker to support all call agent screen applications.
The 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 signaling the transfer of a call by associating the REFER method to the dialogue through the REFER TargetDialog.
Unsuccessful Transfer Scenarios
The Oracle Enterprise Communications Broker (Communications Broker) does not successfully handle the following unsuccessful, unusual, and unexpected transfer scenarios:
- The new INVITE to the Referred-To party gets challenged, the 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 Communications Broker.
- The Communications Broker allows the Referred-To URI that happens to resolve to the same next-hop as the original INVITE went to, to do so.
- The Communications Broker ignores any MIME attachments within a REFER method.
- The 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 (Communications Broker) allows you to set REFER termination on a per-agent and SIP interface basis. Agent configuration takes precedence over the SIP interface configuration.
Configure the SIP Interface.
Select Enable REFER Termination in the SIP Interface configuration to allow the specified agent to support SIP REFER method call transfers.
Use the following procedure to enable SIP REFER termination support.
Dynamic REFER Support
In the simplest scenarios, the Communications Broker supports Dynamic REFER,also known as REFER-initiated call transfer, either by proxying the REFER to the other User Agent in the dialog, or by terminating the received REFER and issuing a new INVITE to the referred party. In addition, the Communications Broker provides dynamic refer support, which determines on a call-by-call basis whether to proxy the REFER to the next hop, or terminate the REFER and issue an INVITE. You configure dynamic REFER with the Refer Call Transfer parameter to the applicable Session Agent or Realm, and Dyn Refer Term in the applicable Realm.
Table 3-5 Refer-call-transfer
| Refer-call Transfer | Description | Action |
|---|---|---|
| Enabled | To configure non-dynamic REFER | Enable the Refer Call Transfer parameter on the source agent for Re-INVITE |
| Dynamic | To configure Dynamic REFER | you set the Refer Call Transfer parameter in the applicable source agent to Dynamic |
| Disabled | To configure Proxy Mode | Disable the Refer Call Transfer parameter on the source agent for proxy mode |
You also enable the Dyn Refer Term parameter in the target Realm Config.
The Communications Broker also includes a Refer Call Transfer setting in the Realm Config. If the REFER comes from a source that is not an agent, the Communications Broker uses the realm's Refer Call Transfer setting to determine how to handle the refer. Behavior is the same whether configured on session agent or realm.
The overall behavior proceeds as follows:
- When you set the source agent's Refer Call Transfer parameter to Disabled (the default), all received REFERs are simply proxied to the peer User Agent.
- When you set the source agent's Refer Call Transfer parameter to Enabled, the Communications Broker terminates all REFERs, generates a new INVITE, and sends the INVITE to the address in the Refer-To header.
- When you set the source agent's Refer Call Transfer parameter to Dynamic, the Communications Broker determines REFER handling on a call-by-call basis
This Communications Broker processing for non-dynamic and dynamic REFER proceeds as follows:
- Determine whether the REFER comes from a session agent.
- If the REFER comes from a session agent, check the Refer Call
Transfer value for the session agent from which the REFER was received:
- If the value is disabled, proxy the REFER to the peer User Agent, to complete REFER processing.
- If the value is enabled, terminate the REFER and issue an new INVITE to the referred party, to complete REFER processing.
- If the value is dynamic, identify the next hop egress realm.
- If the REFER does not come from a session agent, the Communications Broker checks the ingress realm's Refer Call Transfer value. Behavior is the same whether configured on session agent or realm.
- When the Communications Broker
determines the next hop, it check the Dyn Refer Term value for that
egress realm.
- If Dyn Refer Term is Disabled (the default), proxy the REFER to the next hop to complete REFER processing.
- If Dyn Refer Term is Enabled, terminate the REFER and issue an new INVITE to the referred party to complete REFER processing.
Note:
The Communications Broker identifies the next hop realm based on either the Refer-To header or Based on the routing configuration, with the routing table taking higher priority.Supported Scenarios
In the basic scenario for REFER initiated call transfer, a call is established between two User Agents (Alice and Bob). User Agent Bob then sends a REFER request to transfer the call to a third User Agent Eva. With dynamic call-transfer enabled, the Communications Broker prevents the REFER from being sent to Alice and generates the INVITE to Eva.
- If the INVITE to Eva succeeds, the Communications Broker sends a re-INVITE to Alice modifying the SIP session as described in Section 14 of RFC 3261, SIP: Session Initiation Protocol. At this point the Communications Broker cancels the original dialog between the Communications Broker and Bob.
- If the INVITE to Eva fails, call disposition depends on whether or not Bob issued a BYE after the REFER call transfer. If the Communications Broker did receive a BYE from Bob (for instance, a blind transfer), it proxies the BYE to A. Otherwise, the Communications Broker retains the original SIP session and media session, thus allowing Bob to re-establish the call with Alice by sending a re-INVITE. In this case, the Communications Broker sets a timer (32 seconds), and then sends a BYE.
- If a REFER method is received containing no Referred-By header, the Communications Broker adds one, allowing the Communications Broker to support all call agent screen applications.
In addition, the 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 within the destination realm
- 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.
- The Referred-To party can be both in a different realm (and thus a different steering pool) from the referrer, and in the same realm
- The associated latching should not prohibit the Referred-To party from being latched to while the referee is still sending media.
The Communications Broker does not successfully handle the following anomalous transfer scenarios:
- The new INVITE to the Referred-To party gets challenged — the 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 Communications Broker.
- The 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 Communications Broker ignores any MIME attachment(s) within a REFER method.
- The 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.
180 and 100 NOTIFY in REFER Call Transfers for the Communications Broker
When you configure the Communications Broker to support REFER call transfers, you can enable it to send a NOTIFY message after it sends either a 202 Accepted or a 180 Ringing message. If your network contains elements that comply with RFC 5589, and therefore expect the NOTIFY message after the 202 Accepted and each provisional 180 Ringing, set the Send NOTIFY messages for REFER Provisional Responses to either Initial or All, according to your deployment needs.
Without this parameter changed from its default (None), the Communications Broker 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 Communications Broker’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 Communications Broker has the Send NOTIFY Messages for REFER Provisional Responses changed from its default, the difference is that the Communications Broker now responds with a NOTIFY in response to the 202 Accepted and it sends another one after the 180 Ringing. This prevents the timeout 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 TryingAlso 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 RingingAlso 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 OK180 and 100 NOTIFY Configuration
You can specify the provisional mode for sending Notify messages using the Refer Notify Provisional setting in the Realm Config or the Session Agent configuration objects. By default, the Oracle Enterprise Communications Broker (Communications Broker) sends only the final result NOTIFY message.
Do the following to enable 100 and 180 NOTIFY messages in REFER call transfers.
- Navigate to either the Session Agent or Realm Config configuration objects.
- On the Realm Config/Session Agent page, in the Add Realm Config/Add Agents page, select a setting for the Refer Notify Provisional parameter.
- Select any one of the
following:
-
None—No internediate Notify messages need to be sent.
-
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 Communications Broker receives; and the final result NOTIFY.
-
- Save and activate the configuration.