1. Configuration Guide
  2. Session Routing and Load Balancing
  3. SIP Session Agents

SIP Session Agents

SIP session agents can include the following:

  • softswitches
  • SIP proxies
  • application servers
  • SIP gateways
  • SIP endpoints

In addition to functioning as a single logical next hop for a signaling message (for example, where a SIP INVITE is forwarded), session agents can provide information about next or previous hops for packets in a SIP agent, including providing a list of equivalent next hops.

You can use the session agent to describe one or more SIP next or previous hops. Through the configured carriers list, you can identify the preferred carriers to use for traffic coming from the session agent. This set of carriers will be matched against the local policy for requests coming from the session agent. You can also set constraints for specific hops.

Session Agent Status Based on SIP Response

The Oracle® Enterprise Session Border Controller can take session agents out of service based on SIP response codes that you configure, and you can also configure SIP response codes that will keep the session agent in service.

With this feature disabled, the ESBC determines session agents’ health by sending them ping messages using a SIP method that you configure. Commonly, the method is an OPTIONS request. If it receives any response from the session agent, then the ESBC deems that session agent available for use.

However, issues can arise when session agents are administratively out of service, but able to respond to OPTIONs requests. A session agent like this might only respond with a 200 OK when in service, and send a 4xx or 5xx message otherwise.

The session agent status feature lets you set the SIP response message that either takes a session agent out of service or allows it to remain in service when it responds to the ESBC’s ping request.

Details of this feature are as follows:

  • The ESBC only considers a session agent in service when it responds to a request method you set with the final response code that you also set. If a final response code is set, then provisional responses are not used for determining whether or not to take a session agent out of service. If the ESBC receives a final response code that does not match the session agent configuration, it treats the session agent as though it had not responded.
  • The ESBC takes a session agent out of service when it receives an error response for dialog creating request with a response code listed in the new out-service-response-codes parameter.

In the case where the session agent’s response has a Retry-After header, the ESBC tries to bring the session agent back into service after the period of time specified in the header. To do so, it sends another ping request.

There are two lists you can configure in the session agent configuration to determine status:

  • In-service list—Set in the ACLI ping-in-service-response-codes parameter, this list defines the response codes that keep a session agent in service when they appear in its response to the ESBC’s ping request. Furthermore, the ESBC takes the session agent out of service should a response code be used that does not appear on this list.
  • Out-of-service list—Set in the ACLI out-service-response-codes parameter, this list defines the response codes that take a session agent out of service when they appear in its response to the ESBC’s ping request or any dialog-creating request.

When the ESBC receives a session agent’s response to its ping request, it first checks to see if there is an in-service list of responses configured for that session agent. If the list is configured and the ESBC determines that there is a match, the session agent is deemed in service. Otherwise it takes the session agent out of service. In this way, the in-service list takes precedence over the out-of-service list. If you configure the in-service list, then the ESBC ignores the out-of-service list.

If there is no list of in-service responses for the session agent, then the ESBC checks the out of service list. If it is configured and the ESBC determines that there is a match, the ESBC removes that session agent from service. If there is no match, then the session agent is deemed in service.

SIP Session Agent Continuous Ping

You can configure the Oracle® Enterprise Session Border Controller to use either a keep-alive or continuous method for pinging SIP session agents to determine their health—i.e., whether or not the ESBC should route requests to them.

To summarize the two methods:

  • keep-alive— ESBC sends a ping message of a type you configure to the session agent in the absence of regular traffic.
  • continuous—The ESBC sends a ping message regardless of traffic state (regular or irregular); the ESBC regularly sends a ping sent based on the configured ping interval timer.

By sending ping messages, the ESBC monitors session agents’ health and can determine whether or not to take a session out of service (OOS), leave it in service, or bring it back into service after being OOS.

When you set it to use the keep-alive mode of pinging, the ESBC starts sending a configured ping message to a session agent when traffic for that session agent has become irregular. The ESBC only sends the ping if there are no SIP transactions with a session agent over a configurable period of time, to which the session agent’s response can have one of the following results:

  • Successful response—A successful response is either any SIP response code or any response code not found in the out-service-response-codes parameter; these leave the session agent in service. In addition, any successful response or any response in the ping-in-service-response-codes parameter can bring a session agent from OOS to in-service status.
  • Unsuccessful response—An unsuccessful response is any SIP response code configured in the out-service-response-codes parameter and takes the session agent sending it OOS. Because this parameter is blank by default, the ESBC considers any SIP response code successful.
  • Transaction timeout—A transaction timeout happens when the session agent fails to send a response to the ESBC’s request, resulting in the session agent’s being taken OOS.

Despite the fact that the keep-alive ping mode is a powerful tool for monitoring session agents’ health, you might want to use the continuous ping method if you are concerned about the ESBC not distinguishing between unsuccessful responses from next-hop session agents and ones from devices downstream from the next-hop session agent. For example, if a SIP hop beyond the session agent responds with a 503 Service Unavailable, the ESBC does not detect whether a session agent or the device beyond it generated the response.

When you use the continuous ping method, only the next-hop session agent responds—preventing the request from being sent to downstream devices. The ESBC also sends the ping in regular traffic conditions when in continuous ping mode, so it is certain the response comes from the next hop associated with the session agent. And in continuous ping mode, only entries for the ping-out-service-response-codes parameter and transaction timeouts bring session agents OOS.

By default, if the ESBC does not receive a response to the ping from the session-agent, it marks it as out-of-service. You can configure the number of ping failures that the ESBC can receive before it marks the session-agent as out-of-service. This is achieved by configuring the OPTIONS parameter in the session-agent with a ping-failure value, where value is the number of ping response failures. This is true for both the keep-alive and continuous-ping modes.

For example, set the Options parameter by typing options, followed by a Space, the option name: ping-failure-count=N (where N is the number of ping response failures before the SA is set to OOS) and press Enter. You may prepend the option parameter with a plus sign to add and not replace this option to the existing realm-config option list. 

ORACLE (session-agent) #options +ping-failure-count=3

The session-agent is set out of service after the third ping response failure.

To remove the ping-failure-count option configuration, enter options -ping 

ORACLE (session-agent) #options –ping

SIP SA Continuous Ping Configuration

You can set the ping mode in the session agent or session constraints configuration. The default for the ping-send-mode parameter is keep-alive.

Configure Ping Mode for Session Agents

  1. Access the session-agent configuration element.
    ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# session-agent
ORACLE(session-agent)
  2. If you are adding to an existing configuration, then you will need to select the configuration you want to edit.
  3. ping-send-mode—If to want to use continuous ping mode to send ping messages to session agents in regular traffic conditions, set this parameter to continuous. If you want to use the keep-alive mode, leave this parameter set to keep-alive (default).
  4. Save and activate your configuration.

Configure Ping Mode for Session Constraints

  1. Access the session-constraints configuration element.
    ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# session-constraints
ORACLE(session-agent)
  2. If you are adding to an existing configuration, then you will need to select the configuration you want to edit.
  3. ping-send-mode—If to want to use continuous ping mode to send ping messages to session agents in regular traffic conditions, set this parameter to continuous. If you want to use the keep-alive mode, leave this parameter set to keep-alive (default).
  4. Save and activate your configuration.