SIP Interfaces
This section explains how to configure a SIP interface. The SIP interface defines the transport addresses (IP address and port) upon which theOracle® Enterprise Session Border Controller receives and sends SIP messages.
Overview
The SIP interface defines the signaling interface. You can define a SIP interface for each network or realm to which the Oracle® Enterprise Session Border Controller is connected. SIP interfaces support both UDP and TCP transport, as well as multiple SIP ports (transport addresses). The SIP interface also lets Hosted NAT Traversal (HNT) be used in any realm.
The SIP interface configuration process involves configuring the following features:
- address and transport protocols (SIP ports)
- redirect action
- proxy mode
- trust mode
About SIP Ports
A SIP port defines the transport address and protocol the Oracle® Enterprise Session Border Controller will use for a SIP interface for the realm. A SIP interface will have one or more SIP ports to define the IP address and port upon which the Oracle® Enterprise Session Border Controller will send and receive messages. For TCP, it defines the address and port upon which the Oracle® Enterprise Session Border Controller will listen for inbound TCP connections for a specific realm.
You need to define at least one SIP port, on which the SIP proxy will listen for connections. If using both UDP and TCP, you must configure more than one port. For example, if a call is sent to the Oracle® Enterprise Session Border Controller using TCP, which it needs to send out as UDP, two SIP ports are needed.
Preferred SIP Port
When a SIP interface contains multiple SIP ports of the same transport protocol, a preferred SIP port for each transport protocol is selected for outgoing requests when the specific SIP port cannot be determined. When forwarding a request that matched a cached registration entry (HNT or normal registration caching), the SIP port upon which the original REGISTER message arrived is used. Otherwise, the preferred SIP port for the selected transport protocol is used. When selecting the preferred SIP port, the default SIP port of 5060 will be selected over other non-default ports.
For SIP interfaces using the SIP NAT function, the preferred SIP port address and port will take precedence over the external address of the SIP NAT when they do not match. If both TCP and UDP SIP ports are defined, the address and port of the preferred UDP port is used.
Proxy Mode
The Oracle® Enterprise Session Border Controller’s proxy mode determines whether it forwards requests received on the SIP interface to target(s) selected from local policy; or sends a send a redirect response to the previous hop. Sending the redirect response causes the previous hop to contact the targets directly.
If the source of the request matches a session agent with a proxy mode already defined, that mode overrides the proxy mode defined in the SIP interface.
You can configure the proxy mode to use the Record-Route option. Requests for stateless and transaction operation modes are forwarded with a Record-Route header that has the Oracle® Enterprise Session Border Controller’s addresses added. As a result, all subsequent requests are routed through the Oracle® Enterprise Session Border Controller.
Redirect Action
The redirect action is the action the SIP proxy takes when it receives a SIP Redirect (3xx) response on the SIP interface. If the target of the request is a session agent with redirect action defined, its redirect action overrides the SIP interface’s.
You can set the Oracle® Enterprise Session Border Controllerto perform a global redirect action in response to Redirect messages. Or you can retain the default behavior where the Oracle® Enterprise Session Border Controller sends SIP Redirect responses back to the previous hop (proxy back to the UAC) when the UAS is not a session agent.
The default behavior of the Oracle® Enterprise Session Border Controller is to recurse on SIP Redirect responses received from the user agent server (UAS) and send a new request to the Contact headers contained in the SIP Redirect response.
Instead of this default behavior, the Oracle® Enterprise Session Border Controller can proxy the SIP Redirect response back to the user agent client (UAC) using the value in the session agent’s redirect action field (when the UAS is a session agent). If there are too many UASes to define as individual session agents or if the UASs are HNT endpoints, and SIP Redirect responses need to be proxied for UASs that are not session agents; you can set the default behavior at the SIP Interface level.
SIP maddr Resolution
Release S-C6.2.0 provides enhanced resolution of addresses found in SIP contact headers, or in the maddr (multicast address) parameter of SIP 3xx REDIRECT messages. Previous releases resolved these addresses as either a host address or as a session agent name. With Release 6.2.0 these addresses can also be resolved as session agent group (SAG) names.
Support for SAG-based resolution is provide by a new sip-config parameter, sag-lookup-on-redirect. By default, SAG lookup is disabled, providing compatibility with prior releases.
The following sample SIP REDIRECT and ACLI configuration fragment illustrate enhanced processing.
Status-Line: SIP/2.0 302 Moved
Message Header
Via: SIP/2.0/UDP
192.168.200.224:5060;branch=z9hG4bKa0fs40009o90sc8oo780.1
From: <sip:1111@192.168.1.222:6000>;tag=1
To: sut <sip:2223@192.168.1.224:5060>;tag=11
Call-ID: 1-28515@192.168.1.222
CSeq: 1 INVITE
Contact: <sip:1111@192.168.1.223;maddr=test.acmepacket.com>
Privacy: user;id;critical;session
P-Preferred-Identity: sipp <sip:sipp@192.168.200.222:5060>
P-Asserted-Identity: abc.com
Subject: abc
Proxy-Require: privacy,prack,abc
Content-Length: 0
session-group
group-name test.acmepacket.com
description
state enabled
app-protocol SIP
strategy Hunt
dest
192.168.200.222
192.168.200.223
...
...In this case, when the Oracle® Enterprise Session Border Controller receives the 302, it resolves the information from maddr to a SAG name. In the above example, it will resolve to the configured SAG – test.acmepacket.com. The destinations configured in SAG test.acmepacket.com will be used to route the call.
SAG-based address resolution is based on the following set of processing rules.
Trust Mode
The Oracle® Enterprise Session Border Controller supports the Calling Identity privacy requirements based on RFC 3323 and RFC 3325. The trust mode in the SIP interface determines whether the source and destination of a request is a trusted entity. With the implementation of this feature, the Oracle® Enterprise Session Border Controller can understand and support the privacy headers and provide the capability for anonymous packets
The Oracle® Enterprise Session Border Controller, which acts as a boundary device between the trusted platform and the untrusted Internet, understands the following headers:
- Privacy Header
- P-Asserted-Identity Header
- P-Preferred-Identity Header
Depending on the value of these headers and the mode in which the Oracle® Enterprise Session Border Controller is being operated (B2BUA or the proxy), the appropriate actions are performed.
About the Process
On receiving a message, the Oracle® Enterprise Session Border Controller checks whether the message source is trusted or not. It checks the SIP interface’s trust mode value and, if the source is a session agent, the session agent’s trust me value. Depending on these values, the Oracle® Enterprise Session Border Controller decides whether the request’s or response’s source is trusted. If it receives message from a trusted source and the message contains the P-Asserted-Identity header field, the Oracle® Enterprise Session Border Controller passes this message to the outgoing side. The outgoing side then decides what needs to be done with this request or response.
If the request or the response is received from an untrusted source, the Privacy header value is id (privacy is requested), and the P-Asserted-Identity header field is included, the Oracle® Enterprise Session Border Controller strips the Privacy and the P-Asserted-Identity headers and passes the request or the response to the outgoing side.
If the request or the response contains the P-Preferred-Identity header and the message source is untrusted, the Oracle® Enterprise Session Border Controller strips the P-Preferred-Identity header from the request or the response and passes the message to the outgoing side.
If the source is trusted or privacy is not requested (the value of the Privacy Header is not id) and the request or the response contains the P-Preferred-Identity header, the Oracle® Enterprise Session Border Controller performs the following actions:
- inserts the P-Asserted-Identity header field with the value taken from the P-Preferred-Identity header field
- deletes the P-Preferred-Identity header value
- passes this request or the response to the Outgoing side for the appropriate action, depending on the whether the destination is trusted or not
After the Oracle® Enterprise Session Border Controller passes the request or the response to the outgoing side, it checks whether the destination is trusted by checking the SIP interface’s trust mode value and the session agent’s trust me value (if the destination is configured as session agent).
- The destination is trusted
The Oracle® Enterprise Session Border Controller does nothing with the request or the response and passes it to the destination. If the P_Asserted_Identity headers are present, they are passed to the session agent (if the destination is configured as session agent).
- The destination is untrusted
The Oracle® Enterprise Session Border Controller looks at the value of the Privacy header. If set to id, the Oracle® Enterprise Session Border Controller removes all the P-Asserted-Identity headers (if present). It strips the Proxy-Require header if it is set to privacy. The Oracle® Enterprise Session Border Controller also sets the From field of SIP header to Anonymous and strips the Privacy header.
If the Privacy header is set to none, the Oracle® Enterprise Session Border Controller does not remove the P-Asserted-Identity header fields.
If there is no Privacy header field, the SD will not remove the P-Asserted-Identity headers.
To implement this feature, you need to configure the session agent’s trust me parameter to enabled (if the message source is a session agent) and the SIP interface’s trust mode to the appropriate value.
Call Duration Counters
The Oracle® Enterprise Session Border Controller maintains aggregate call duration in seconds for the current period, lifetime total and the lifetime-period-maximum. These counters are maintained for each session agent, realm, SIP Interface, and globally across the system. The call duration counter can count up to a 32 bit value, after which time it rolls over.
- show sipd agents
- show sipd realms
- show sipd interface
- show sipd status
Call Duration Calculation
Call duration is calculated as the time between (t1) when the ESBC receives the 200OK for the INVITE from terminating endpoint, and (t2) the time when ESBC receives the final 200OK for the BYE message from terminating endpoint, regardless of whether media is released. If the set-disconnect-time-on-bye parameter is enabled in the sip-config, then the call termination time (t2') is when the ESBC receives the BYE message originally from the endpoint ending the call.
Figure 4-1 Call Duration Calculation Example - Ladder Diagram
Table 4-1 Call Duration Calculation Example - Results
| Element | Inbound Duration (sec) | Outbound Duration (sec) |
|---|---|---|
| Session Agent: SA-1 | t2 - t1 | 0 |
| Session Agent: SA-2 | 0 | t2 - t1 |
| Realm: InRealm | t2 - t1 | 0 |
| Ream: OutRealm | 0 | t2 - t1 |
| Interface: 1.1.1.1 | t2 - t1 | 0 |
| Interface: 2.2.2.2 | 0 | t2 - t1 |
The global system call duration for the previous example is t2' - t1 seconds if the set-disconnect-time-on-bye parameter is enabled.
Configurable Timers and Counters
SIP timers and counters can be set in the global SIP configuration, and two can be specific for individual SIP interfaces.
You can set the expiration times for SIP messages, and you can set a counter that restricts the number of contacts that the Oracle® Enterprise Session Border Controller tries when it receives a REDIRECT. These are similar to two parameters in the global SIP configuration, trans-expire and invite-expire. You can also set a parameter that defines how many contacts/routes the Oracle® Enterprise Session Border Controller will attempt on redirect.
Timer to Tear Down Long Duration Calls
The Oracle® Enterprise Session Border Controller currently provides the “flow-time-limit” timer to terminate long duration calls. However, this timer is reset whenever the Oracle® Enterprise Session Border Controller receives a Re-INVITE or UPDATE message, even when it is provided for the session timer. This feature adds a non-resettable timer that, when enabled and upon expiration, tears down long duration calls.
When the “flow-time-limit” timer for terminating long media flow expires, the Oracle® Enterprise Session Border Controller sends a SIP BYE or H323 Release Complete message to tear down the long call. However, this timer is reset whenever the SBC receives a Re-INVITE or UPDATE message. 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, this feature adds a new timer session-max-life-limit, which starts when the call or session is established and does not reset for any session update, keep-alive or SBC switchover. On expiry, the call is torn down if it’s in established state.
The new timer session-max-life-limit 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 SBC 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 SBC 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. The value 0 is skipped over and completely ignored.
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 realm-config 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.
Timer to Tear Down Long Duration Calls Configuration
Use the following procedure to configure, in the session-agent, realm-config, sip-interface, and sip-config configuration elements, a non-resettable timer that, when enabled and upon expiration, tears down long duration calls.