The SIP interface defines the signaling interface. You can define a SIP interface for each network or realm to which the Oracle Communications 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

A SIP port defines the transport address and protocol the Oracle Communications 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 Communications Session Border Controller will send and receive messages. For TCP, it defines the address and port upon which the Oracle Communications 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 Communications Session Border Controller using TCP, which it needs to send out as UDP, two SIP ports are needed.

The Oracle Communications 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 Communications Session Border Controller’s addresses added. As a result, all subsequent requests are routed through the Oracle Communications Session Border Controller.

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 Communications Session Border Controllerto perform a global redirect action in response to Redirect messages. Or you can retain the default behavior where the Oracle Communications 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 Communications 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 Communications 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.

The Oracle Communications 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 Communications Session Border Controller can understand and support the privacy headers and provide the capability for anonymous packets

The Oracle Communications 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 Communications Session Border Controller is being operated (B2BUA or the proxy), the appropriate actions are performed.

The Oracle Communications 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.

Call Duration Calculation

Call duration is calculated as the time between (t1) when the OCSBC receives the 200OK for the INVITE from terminating endpoint, and (t2) the time when OCSBC 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 OCSBC receives the BYE message originally from the endpoint ending the call.

Figure 5-1 Call Duration Calculation Example - Ladder Diagram

Table 5-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.

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 Communications 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 Communications Session Border Controller will attempt on redirect.

The Oracle Communications Session Border Controller currently provides the “flow-time-limit” timer to terminate long duration calls. However, this timer is reset whenever the Oracle Communications 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 Communications 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).

This feature allows you to reserve network resources for a session before the called party is alerted by establishing preconditions for individual call legs. Currently, the Oracle Communications Session Border Controller transparently passes precondition attributes in SIP signaling and the UEs negotiate preconditions end to end. However, some networks support the SIP preconditions and other networks do not. To help provide precondition interworking between these networks, the Oracle Communications Session Border Controller supports SIP preconditions on a per call leg basis.

Some architectures require minimizing the chance of session establishment failure after alerting the called party. One source of failure is the inability to reserve network resources for a session, which can cause media clipping and "ghost rings". The solution is to allow preconditions to reserve network resources for the session before alerting the called party. A precondition is a set of constraints about the session which are introduced in the offer. The recipient of the offer generates an answer, but does not alert the user or otherwise proceed with session establishment until the preconditions are met. This can be known through a local event (such as a confirmation of a resource reservation), or through a new offer sent by the caller. The concept of preconditions is explained in RFC 3312, updated by RFC 4032, and also 3GPP TS 24.229.

When appropriately configured, the Oracle Communications Session Border Controller inserts SDP into an outgoing INVITE when the corresponding incoming INVITE has none. Because no SDP information is available for the session, the Oracle Communications Session Border Controller uses a media profile from a previously configured list to determine the content to insert. You cannot enable asymmetric preconditions without first enabling PRACK interworking by setting the value of sip-interface, options to 100rel-interworking. The OCSBC does precondition interworking by creating SDP offers or answers before the actual ones have reached the UE; thus, transcoding policies are needed to cover the cases where different codecs are negotiated. However, in cases where different codecs are not expected, interworking works without defining codec policies. When codec policies are not defined and a final SDP answer comes with a different codec, the OCSBC will drop the call with 488 Not Acceptable.

To establish preconditions interworking, you must first enable it on the SIP interface with the parameter asymmetric-preconditions and then define when the initial offer will be sent to the endpoint that doesn’t support preconditions with the parameter asymmetric-preconditions-mode. When the value of asymmetric-preconditions-mode is send-with-nodelay, the OCSBC forwards the INVITE as soon as it is received; however, it strips the precondition option tag from the Require and Supported header fields and also removes the preconditions related SDP. This triggers preconditions interworking on the calling side of the OCSBC. Responses received from the called party are queued until resource reservation is complete on the calling side. When resource reservation is complete, all buffered responses from the called party are sent to the calling party (after, if necessary, removing the SDP as in PRACK interworking) and the call proceeds as normal. When the value of asymmetric-preconditions-mode is send-with-delay on the egress, the initial INVITE forwarded to the called party is held until preconditions are met by the calling party. For offerless 18x INVITEs, that is, when the incoming INVITE has no STP, the OCSBC inserts the SDP, as configured in the media profile names listed in add-sdp-profiles-in-msg, in the 18x (183) response towards the UE.

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-interface and press Enter. The system prompt changes to let you know that you can begin configuring individual parameters.

   ORACLE(session-router)# sip-interface
   ORACLE(sip-interface)#

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

4. state—Enable or disable the SIP interface. The default is enabled. The valid values are:

   • enabled | disabled

5. realm-id—Enter the name of the realm to which the SIP interface is connected.
6. sip-ports—Access the sip-ports subelement.
7. carriers—Enter the list of carriers related to the SIP interface.

   Entries in this field can be from 1 to 24 characters in length and can consist of any alphabetical character (Aa-Zz), numerical character (0-9), or punctuation mark (! ”$ % ^ & * ( ) + - = < > ? ‘ | { } [ ] @ / \ ‘ ~ , . _ : ; ) or any combination of alphabetical characters, numerical characters, or punctuation marks. For example, both 1-0288 and acme_carrier are valid carrier field formats

8. proxy-mode—Enter an option for the proxy mode parameter. Valid values are:

   • proxy—Forward all SIP requests to selected targets.

   • redirect—Send a SIP 3xx redirect response with the selected target(s) in the Contact header.

   • record-route—Forward requests to selected target(s) and insert a Record-Route header with the Oracle Communications Session Border Controller’s address. For stateless and transaction mode only.

9. redirect-action—Enter the value for the redirect action. Valid values are:

   • proxy—Send the SIP request back to the previous hop.

   • recurse—Recurses on the Contacts in the response.

     The designated proxy action will apply to SIP 3xx responses received from non-session agents and to 3xx responses received from session agents without configured SIP Redirect message actions (for example, session agents without values for the redirect action field).

10. contact-mode—Set the Contact header routing mode, which determines how the contact address from a private network is formatted.

    For example, whether a maddr parameter equal to the Oracle Communications Session Border Controller’s SIP proxy needs to be added to a URI present in a Contact header.

    The default is none. The valid values are:

    • none—The address portion of the header becomes the public address of that private realm.

    • maddr—The address portion of the header will be set to the IP address of the Oracle Communications Session Border Controller’s B2BUA.

    • strict—The contents of the Request-URI is destroyed when a Record-Route header is present.

    • loose—The Record-Route header is included in a Request, which means the destination of the request is separated from the set of proxies that need to be visited along the way.

11. nat-traversal—Define the type of HNT enabled for SIP. The default is none. Valid values are:

    • none—HNT function is disabled for SIP.

    • rport—SIP HNT function only applies to endpoints that include the rport parameter in the Via header. HNT applies when the sent-by of the topmost VIA matches the Contact-URI host address, both of which must be different from the received Layer 3 address.

    • always—SIP HNT applies to requests when the sent-by of the topmost VIA matches the Contact-URI host address, both of which must be different from the received Layer 3 address. (Even when the rport parameter is not present.)

12. nat-interval—Set the expiration time in seconds for the Oracle Communications Session Border Controller’s cached registration entry for an HNT endpoint. The default is 30. The valid range is:

    • Minimum—0

    • Maximum—999999999

      Oracle recommends setting the NAT interval to one-third of the NAT binding lifetime. A NAT binding lifetime is the network connection inactivity timeout. The value is configured (or hardwired) in the NAT device (firewall). This timer is used to cause the UA to send REGISTER messages frequently enough to retain the port binding in the NAT. Retaining the binding lets inbound requests to be sent through the NAT.

13. tcp-nat-interval—Set the registration cache expiration time in seconds to use for endpoints behind a NAT device that register using TCP. On upgrade, the Oracle Communications Session Border Controller assigns this parameter the same value as the existing NAT interval. The default is 90. The valid range is:

    • Minimum—0

    • Maximum—999999999

      The Oracle Communications Session Border Controller uses the value you set for the TCP NAT interval as the expiration value passed back in SIP REGISTER (200 OK) responses to endpoints behind a NAT that register over TCP. The NAT interval value with which you are familiar from previous releases is used for endpoints behind a NAT that register over UDP. Requiring endpoints that register over TCP to send refresh requests as frequently as those registering over UDP puts unnecessary load on the Oracle Communications Session Border Controller. By adding a separate configuration for the TCP NAT interval, the load is reduced.

      For upgrade and backward compatibility with Oracle Communications Session Border Controller releases prior to Release 4.1, when the tcpNatInterval is not present in the XML for a SIP interface configuration, the value of the NAT interval (natInterval) is used for the TCP NAT interval as well.

14. registration-caching—Enable for use with all UAs, not just those that are behind NATs. The default is disabled. The valid values are:

    • enabled | disabled

      If enabled, the Oracle Communications Session Border Controller caches the Contact header in the UA’s REGISTER request when it is addressed to one of the following:

    • Oracle Communications Session Border Controller

    • registrar domain value

    • registrar host value

      The Oracle Communications Session Border Controller then generates a Contact header with the Oracle Communications Session Border Controller’s address as the host part of the URI and sends the REGISTER to the destination defined by the registrar host value.

      Whether or not SIP HNT functionality is enabled affects the value of the user part of the URI sent in the Contact header:

    • HNT enabled: the Oracle Communications Session Border Controller takes the user part of the URI in the From header of the request and appends a cookie to make the user unique. A cookie is information that the server stores on the client side of a client-server communication so that the information can be used in the future.

    • HNT disabled: the user part of the Contact header is taken from the URI in the From header and no cookie is appended. This is the default behavior of the Oracle Communications Session Border Controller.

      When the registrar receives a request that matches the address-of-record (the To header in the REGISTER message), it sends the matching request to the Oracle Communications Session Border Controller, which is the Contact address. Then, the Oracle Communications Session Border Controller forwards the request to the Contact-URI it cached from the original REGISTER message.

15. min-reg-expire—Set the time in seconds for the SIP interface. The value you enter here sets the minimum registration expiration time in seconds for HNT registration caching. The default is 300. The valid range is:

    • Minimum—0

    • Maximum—999999999

      This value defines the minimum expiration value the Oracle Communications Session Border Controller places in each REGISTER message it sends to the real registrar. In HNT, the Oracle Communications Session Border Controller caches the registration after receiving a response from the real registrar and sets the expiration time to the NAT interval value.

      Some UAs might change the registration expiration value they use in subsequent requests to the value specified in this field. This change causes the Oracle Communications Session Border Controller to send frequent registrations on to the real registrar.

16. registration-interval—Set the Oracle Communications Session Border Controller’s cached registration entry interval for a non-HNT endpoint. Enter the expiration time in seconds that you want the Oracle Communications Session Border Controller to use in the REGISTER response message sent back to the UA. The UA then refreshes its registration by sending another REGISTER message before that time expires. The default is 3600. The valid range is:

    • Minimum—0

      A registration interval of zero causes the Oracle Communications Session Border Controller to pass back the expiration time set by and returned in the registration response from the registrar.

    • Maximum—999999999

      If the expiration time you set is less than the expiration time set by and returned from the real registrar, the Oracle Communications Session Border Controller responds to the refresh request directly rather than forwarding it to the registrar.

      Although the registration interval applies to non-HNT registration cache entries, and the loosely related NAT interval applies to HNT registration cache entries, you can use the two in combination. Using a combination of the two means you can implement HNT and non-HNT architectures on the same Oracle Communications Session Border Controller. You can then define a longer interval time in the registration interval field to reduce the network traffic and load caused by excess REGISTER messages because there is no NAT binding to maintain.

17. route-to-registrar—Enable routing to the registrar to send all requests that match a cached registration to the destination defined for the registrar host; used when the Request-URI matches the registrar host value or the registrar domain value, not the Oracle Communications Session Border Controller’s address. Because the registrar host is the real registrar, it should send the requests back to the Oracle Communications Session Border Controller with the Oracle Communications Session Border Controller’s address in the Request-URI. The default is disabled. The valid values are:

    • enabled | disabled

      For example, you should enable routing to the registrar if your network uses a N Oracle Communications Session Border Controller and needs requests to go through its service proxy, which is defined in the registrar host field.

18. teluri-scheme—Enable to convert SIP URIs to tel (resources identified by telephone numbers) URIs.

    If enabled, the requests generated on this SIP interface by the Oracle Communications Session Border Controller will have a tel URI scheme instead of the SIP URI scheme. Only the Request, From, and To URIs are changed to the tel scheme. After the dialog is established, the URIs are not changed. The default is disabled. The valid values are:

    • enabled | disabled

19. uri-fqdn-domain—Change the host part of the URIs to the FQDN value set here. If set to enabled, and used with an FQDN domain/host, the requests generated by the Oracle Communications Session Border Controller on this SIP interface will have the host part of the URI set to this FQDN value. Only the Request, To, and From URIs are changed. After the dialog is established, the URIs are not changed.
20. trust-mode—Set the trust mode for the SIP interface, which is checked by the Oracle Communications Session Border Controller when it receives a message to determine whether the message source is trusted. The default is all. Available options are:

    • all—Trust all SIP elements (sources and destinations) in the realm(s), except untrusted session agents. Untrusted session agents are those that have the trust-me parameter set to disabled.

    • agents-only—Trust only trusted session agents. Trusted session agents are those that have the trust-me parameter set to enabled.

    • realm-prefix—Trust only trusted session agents, and source and destination IP addresses that match the IP interface’s realm (or subrealm) address prefix. Only realms with non-zero address prefixes are considered.

    • registered—Trust only trusted session agents and registered endpoints. Registered endpoints are those with an entry in the Oracle Communications Session Border Controller’s registration cache.

    • none—Trust nothing.

      Session agents must have one or more of the following:

    • global realm

    • same realm as the SIP interface

    • realm that is a subrealm of the SIP interface’s realm

21. trans-expire—Set the TTL expiration timer in seconds for SIP transactions. This timer controls the following timers specified in RFC 3261:

    • Timer B—SIP INVITE transaction timeout

    • Timer F—non-INVITE transaction timeout

    • Timer H—Wait time for ACK receipt

    • Timer TEE—Used to transmit final responses before receiving an ACK

      The default is 0. If you leave this parameter set to the default, then the Oracle Communications Session Border Controller uses the timer value from the global SIP configuration. The valid range is:

    • Minimum—0

    • Maximum—999999999

22. invite-expire—Set the TTL expiration timer in seconds for a SIP client/server transaction after receiving a provisional response.

    You set this timer for the client and the sever by configuring it on the SIP interface corresponding to the core or access side.

    The default is 0. If you leave this parameter set to the default, then the Oracle Communications Session Border Controller uses the timer value from the global SIP configuration. The valid range is:

    • Minimum—0

    • Maximum—999999999

23. max-redirect-contacts—Set the maximum number of contacts or routes for the Oracle Communications Session Border Controller to attempt in when it receives a SIP Redirect (3xx Response). The default is 0. If you leave this parameter set to the default, then the Oracle Communications Session Border Controllerwill exercise no restrictions on the number of contacts or routes. The valid range is:

    • Minimum—0

    • Maximum—10

24. response-map—Enter the name of the SIP response map configuration that you want to apply to this SIP interfaces for outgoing responses. This parameter is blank by default.
25. local-response-map—Enter the name of the SIP response map configuration that you want to apply to this SIP interfaces for locally-generated SIP responses. This parameter is blank by default.
26. options—Optional.