IMS Implicit Service Route

The Oracle Communications Session Border Controller provides implicit service route support in situations where it is deployed between user equipment (UE) and the P-CSCF, and where the IMS core network does not support the Service-Route header.

When this feature is enabled, the Oracle Communications Session Border Controller sends requests to the P-CSCF and does not include the Service-Route header received in the 200 OK response (to a REGISTER message) as Route headers in subsequent requests. The Oracle Communications Session Border Controller also includes a Route header of the P-CSCF address in subsequent requests, and includes the loose-route parameter in the Route header. Because inclusion of the loose-route parameter is not needed in all cases, you can set this feature to strict in the SIP interface configuration.

Recent enhancements address the following issues:

  • Even when IMS is disabled for a SIP interface, the Oracle Communications Session Border Controller caches and uses the Service-Route headers from SIP REGISTER responses received from the REGISTER. Therefore, you must use SIP HMR to remove the Service-Route headers from the response, while having no mechanism to replace the Service-Routes from the REGISTER response with an implicit Service Route.
  • In the Oracle Communications Session Border Controller global SIP configuration, the presence of the option route-registrar-no-service-route sets the behavior for using the Service-Route header in the REGISTER request. The new enhancements greatly simplify the process of determining proper use of the header in both IMS and non-IMS environments.
  • You can configure the Oracle Communications Session Border Controller with an option to keep it from using the Service-Route header for REGISTER requests when sent to an out-of-service session agent. The enhancements make this behavior the default—because otherwise these REGISTER requests fail.
  • If the initial re-registration is challenged, the subsequent REGISTER will be sent to the same target as its prior REGISTER.

When implicit service route support is enabled, the Oracle Communications Session Border Controller stores the Service Route URIs from the Service-Route headers that are included in 200 OK responses to REGISTER messages. The Service Route URIs are included in the Route headers in subsequent Request messages, except for REGISTER messages.

The Oracle Communications Session Border Controller also supports the ability to keep the loose-route parameter from being included in the implicit Route URI that the Oracle Communications Session Border Controller generates and includes as a Route header in the Request messages.

Once an endpoint registers successfully, the Oracle Communications Session Border Controller caches the Service-Route header (if any) to use for routing all subsequent requests from the endpoint—with the exception of any subsequent REGSITER requests.

You can set whether or not you want the Oracle Communications Session Border Controller to route subsequent REGISTER requests using the cached Service Route, and whether the endpoint is engaged in an active session through the Oracle Communications Session Border Controller. If you decide not to use the Service Route for endpoints engaged in active sessions, then the Oracle Communications Session Border Controlleruses the local policy to make routing decisions.

For endpoints not in found in the Oracle Communications Session Border Controller’s registration cache, the Oracle Communications Session Border Controller again uses the local policy to make routing decisions.

IMS Implicit Service Route Configuration

To configure implicit service route support:

  1. In Superuser mode, type configure terminal and press Enter.
    ORACLE# configure terminal
  2. Type session-router and press Enter.
    ORACLE(configure)# session-router
  3. Type sip-interface and press Enter.
    ORACLE(session-router)# sip-interface
  4. implicit-service-route—To enabled implicit service route support, change this parameter from disabled to enabled. The default value is disabled. Supported values are:
    • absent | disabled (the default) | enabled | replace | strict

    • absent—An implicit service route to the session agent to which the REGISTER request was sent is constructed when the successful REGISTER response contains no Service-Route headers.

    • disabled (default)—Turns off the implicit service route feature; Oracle Communications Session Border Controller constructs service route the Service-Route headers in a successful REGSITER response.

    • enabled—Turns on this feature, meaning that an implicit service route to the session agent to which the REGISTER request was sent is inserted in front of Service-Route header in a successful REGISTER response; the inserted URI includes the ;lr parameter if the session agent has loose routing enabled.

    • replace—An implicit service route to the session agent to which the REGISTER request was sent is used to construct the service route. The Oracle Communications Session Border Controller ignores Service-Route headers in successful REGISTER responses.

    • strict—An implicit service route to the session agent to which the REGISTER request was sent is inserted in front of Service-Route header in a successful REGISTER response; the inserted URI does not the ;lr parameter if the session agent has loose routing enabled, overriding the loose routing behavior configured for the session agent.

      Save and activate your configuration.

IMS Service Route Configuration

To configure how you want the Service Route used:

  1. In Superuser mode, type configure terminal and press Enter.
    ORACLE# configure terminal
    ORACLE(configure)#
  2. Type session-router and press Enter.
    ORACLE(configure)# session-router
    ORACLE(session-router)#
  3. Type sip-config and press Enter.
    ORACLE(session-router)# sip-config
    ORACLE(sip-config)#
  4. register-service-route—Enter the way you want the Oracle Communications Session Border Controller to use the service route:
    • always—The Oracle Communications Session Border Controller always uses the cached service route for an endpoint for routing REGISTER requests.

    • never—The Oracle Communications Session Border Controller never uses the service route, and makes routing decisions based on local policies instead.

    • removal—The Oracle Communications Session Border Controller uses the cached service route for an endpoint when routing REGISTER requests that remove the endpoint’s contact. It uses the local policy for refresh and query REGISTER requests.

    • session—The Oracle Communications Session Border Controller uses the cached service route when routing REGISTER requests that appear while an endpoint has an active session traversing it. When an endpoint does not have an active session, the Oracle Communications Session Border Controller uses the local policy to make routing decisions.

    • session+removal—Combining the session and removal values, the Oracle Communications Session Border Controller uses the cached service route: when routing REGISTER requests that remove the endpoint’s contact and when REGISTER requests appear while while an endpoint has an active session traversing the system. Otherwise, the Oracle Communications Session Border Controller uses the local policy to make routing decisions.

  5. Save and activate your configuration.

Notes About Upgrading

There are Oracle Communications Session Border Controllers currently deployed that use the route-registrar-no-service-route option, and these enhancements provide for backward compatibility.

When you upgrade to a release that has the new register-service-route parameter in the SIP configuration, the system checks for the presence of the route-registrar-no-service-route option. If the system finds the option, then it translates the value configured for the option like this:

Old route-registrar-no-service-route value New register-service-route value
<empty> or all never
refresh removal
all, idle session
refresh; idle session+removal

You must save your configuration for these changes to take place, allowing you to fall back to the previous software image.