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 Oracle® Enterprise Session Border Controller 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 Oracle® Enterprise Session Border Controller 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 Oracle® Enterprise Session Border Controller’s ping request.
Details of this feature are as follows:
- The Oracle® Enterprise Session Border Controller 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 Oracle® Enterprise Session Border Controller 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 Oracle® Enterprise Session Border Controller 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 a the session agent’s response has a Retry-After header, the Oracle® Enterprise Session Border Controller 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 Oracle® Enterprise Session Border Controller’s ping request. Furthermore, the Oracle® Enterprise Session Border Controller 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 Oracle® Enterprise Session Border Controller’s ping request or any dialog-creating request.
When the Oracle® Enterprise Session Border Controller 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 Oracle® Enterprise Session Border Controller 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 Oracle® Enterprise Session Border Controller ignores the out-of-service list.
If there is no list of in-service responses for the session agent, then the Oracle® Enterprise Session Border Controller checks the out of service list. If it is configured and the Oracle® Enterprise Session Border Controller determines that there is a match, the Oracle® Enterprise Session Border Controller 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 Oracle® Enterprise Session Border Controller should route requests to them.
To summarize the two methods:
- keep-alive— Oracle® Enterprise Session Border Controller sends a ping message of a type you configure to the session agent in the absence of regular traffic. Available in Release C5.1.0 and in earlier releases.
- continuous—The Oracle® Enterprise Session Border Controller sends a ping message regardless of traffic state (regular or irregular); the Oracle® Enterprise Session Border Controller regularly sends a ping sent based on the configured ping interval timer. Available in Release C5.1.1p6 and in later releases.
By sending ping messages, the Oracle® Enterprise Session Border Controller 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 (available in Release C5.1.0 and before), the Oracle® Enterprise Session Border Controller starts sending a configured ping message to a session agent when traffic for that session agent has become irregular. The Oracle® Enterprise Session Border Controller 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 Oracle® Enterprise Session Border Controller considers any SIP response code successful.
- Transaction timeout—A transaction timeout happens when the session agent fails to send a response to the Oracle® Enterprise Session Border Controller’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 Oracle® Enterprise Session Border Controller 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 Oracle® Enterprise Session Border Controller 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 Oracle® Enterprise Session Border Controller 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 Oracle® Enterprise Session Border Controller 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 Oracle® Enterprise Session Border Controller 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. For backward compatibility, the default for the ping-send-mode parameter is keep-alive, or the functionality available in Release C5.1.0 and in earlier releases.
To configure the ping mode for a session agent:
