Dynamic Sessions Agents for Home-Remote S-CSCF Liveliness

For IMS applications, you can configure your Oracle Communications Session Border Controller to create session agents dynamically for remote S-CSCFs on in-coming service routes. Dynamic session agents inherit properties of the static session agents with which they are associated, and the Oracle Communications Session Border Controller takes them out of service when they are deemed no longer responsive according to the liveliness mechanism you set.

Discovery

The Oracle Communications Session Border Controller, acting as a P-CSCF, can discover remote S-CSCFs using Service-Route header that returns with a 200 OK response from the registrar for a REGISTER request from the endpoint. The system takes the top Service Route from the response and uses it as the first hop in the egress route for the endpoint. Because the creation of dynamic session agents is based on the Service Route returned in the 200 OK, there is no impact to handling AoRs with multiple contacts.

In addition, the system stores the Service Route header data with the endpoint’s registration cache. If the Service Route is an FQDN, a DNS look-up is used to provide the route to the S-CSCF.

Creation

For your Oracle Communications Session Border Controller to create session agents dynamically, you must enable the create-dynamic-sa in the global SIP configuration. This parameter defaults to disabled, meaning that no dynamic session agents will be created.

When you set the parameter to enabled, the Oracle Communications Session Border Controller decides whether or not to create dynamic session agents in the following ways. The system will create up to five (5) dynamic session agents.

  • If the Service Route is an IP address, the Oracle Communications Session Border Controller attempts to find an exact match for that IP address against pre-existing session agents. If no exact match appears, the system will not create dynamic session agents.
  • If the Service Route is an FQDN and matches an existing session agent, the Oracle Communications Session Border Controller assigns the remote S-CSCF to that session agent.

    Service Routes with FQDNs might not match any session agents. However, the Service Route’s FQDN can match the DNS suffix of a wildcard session agent. When this wildcard matching occurs, the Oracle Communications Session Border Controller creates a new dynamic session agent with the original wildcard session agent as its parent. The new dynamic session agent inherits all configuration properties of the parent session agent.

  • If the Service Route is neither an IP address nor an FQDN and the system is unable to match any statically defined or wildcard session agents, then the Service Route is not associated with any session agents.

Property Inheritance

Because dynamic session agents are created on the basis of static or wildcarded session agents, you can think of them as children of the original--or parent--session agent. This relationship means that the child, dynamic session agent inherits the configuration properties of its parent, static or wildcard session agent.

These inherited configuration properties and their effects are:

  • The FQDN’s DNS resolution of the new dynamic session agent to IP addresses.
  • Monitoring for liveliness via your configuration settings for the ping method and interval, transaction timeout, or OOS response. The dynamic session agent also inherits its parent’s criteria for being taken out of service, with the exception that a dynamic session agent will not be taken out of service until it expires on its own. This gives the dynamic session agent time to return to service.
  • The setting for ping-all-address, which when enabled causes new routes (internal session agents) fork and makes the dynamic session agent the parent. The system caps the limit of five routes (or internal session agents) per dynamic session agent. If the FQDN resolves to more than five IP addresses, the system only uses the first five to create routes (internal session agents), and then pings the internal session agents.
  • Suppression of the heartbeat (or ping) of the IP address in the presence of traffic. If traffic to a specific IP address stops, then the Oracle Communications Session Border Controller resumes pinging within the time you set for the ping-interval.
  • The setting for the invalidate-registration option. If the dynamic child session agent goes out of service, the corresponding registration cache entries of users that have the Service Route pointing to this session agent will be invalidated.

    This invalidation means that the next REGISTER request from that user will not receive a local response. Any other services this user requires will not use the Service Route information stored in its registration cache. Instead, the system will route it to the next hop as determined by other means, such as the local policy. At this time, the user would must be re-registered by the registrar, a process that might return a new Service Route to be updated in the registration cache.

Deletion

The Oracle Communications Session Border Controller needs to delete dynamic session agents no longer in use. But dynamic session agents should not be deleted too soon, in case they return to service. So, deletion occurs according to the process this section describes.

For each dynamically created session agent, the Oracle Communications Session Border Controller assigns and tracks the last registration expiry time. It determines this time by doubling the registered endpoint’s core side expiry. Where X is the last registration expiry value and Y is the registered endpoint’s core side expiry, the Oracle Communications Session Border Controller performs checks according to this criteria:

X > (2 * Y)

The the system updates the expiry time with the greater value. This way, whenever the dynamic session agent re-registers, it will have an updated expiry timer value.

Timeouts can also cause dynamic session agents to be deleted. Pings, status changes, transaction timeouts, DNS expiries and other system occurrences can trigger timeouts. When the Oracle Communications Session Border Controller detects that a timeout has occurred, the dynamic session agent is deleted.

How to Wildcard a Session Agent

You can create a wildcard session agent using the session agent’s hostname parameter when configured with an FQDN.

To configure a wildcard session agent:

  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 session-agent and press Enter.
    ORACLE(session-router)# session-agent
    ORACLE(session-agent)#

    If you are wildcarding and existing session agent, you have to select the configuration before you make changes.

  4. hostname—To wildcard a session agent, you simply replace the value you want to wildcard with an asterisk (*). Also note that your value must lead with the asterisk (*), as in the following example.
    ORACLE(session-router)# hostname *xyz.com
    ORACLE(session-agent)#
  5. Save and activate your configuration.

Enabling the Global SIP Configuration for Dynamic Session Agents

To use dynamic session agents for remote S-CSCFs on in-coming service routes, you need to set the create-dynamic-sa parameter in the global SIP configuration to enabled.

To configure the ping mode for a session agent:

  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)#

    If you are adding this support to a pre-existing SIP configuration, you have to select the configuration before you make changes.

  4. create-dynamic-sa—To support the creation of dynamic session agents for remote S-CSCFs on in-coming service routes, change this parameter from disabled (default) to enabled.
  5. Save and activate your configuration.