H.323 LRQ Alternate Routing

There are networks where the Oracle® Enterprise Session Border Controller is positioned so that it needs to send an H.225 LRQ request to one signaling entity, and then fall back to another signaling entity when there are no resources available on the first. This might be the case when network contain elements that have limited amounts of channels and/or ports.

To handle situations like this one, the Oracle® Enterprise Session Border Controller can be configured for H.323 LRQ alternate routing.

Without this feature enabled, the Oracle® Enterprise Session Border Controller performs H.323 alternate routing for an H.323 call by finding the alternate route for a local policy when the call setup using H.225/Q.931 fails. Some network configurations, however, require that an LRQ message be sent to a gatekeeper prior to call setup in order to request the destination call signaling address—meaning that the Oracle® Enterprise Session Border Controller will release the call if it does not receive an LCF for that LRQ.

With H.323 LRQ alternate routing enabled, the Oracle® Enterprise Session Border Controller can route the call even when it does not receive the LCF.

When the Oracle® Enterprise Session Border Controller routes an H.323 call using a local policy and the applicable route specifies gatekeeper/session agent as the next hop, the Oracle® Enterprise Session Border Controller must send that gatekeeper an LRQ to request the destination for the call signaling address. After it sends the LRQ, the Oracle® Enterprise Session Border Controller might receive either an LCF or an LRJ, or it might receive no response at all. Upon failure—either the receipt of an LRJ or no response within a timeout period—the Oracle® Enterprise Session Border Controller tries alternate routes (additional routing policies) until the call is either set up or the routing list ends. For each alternate route, if the next hop is a gatekeeper/session agent, the Oracle® Enterprise Session Border Controller sends an LRQ to the gatekeeper in order to request the destination call signaling address. Otherwise, the Oracle® Enterprise Session Border Controller simply sets up the call.

For a designated period of time, the Oracle® Enterprise Session Border Controller waits for the a response to the LRQ from the gatekeeper. This timeout period is configured by setting two options in the global H.323 configuration: ras-tmo (number of seconds the Oracle® Enterprise Session Border Controller waits before retransmitting a RAS message; default is 4) and maxRasRetries (maximum number of times the Oracle® Enterprise Session Border Controller retransmits the RAS; default is 1). The Oracle® Enterprise Session Border Controller calculates the LRQ timeout period by multiplying the ras-tmo by the maxRasRetries and adding one (ras-tmo x maxRasRetries +1).

If an out of service session agent is part of a route, the Oracle® Enterprise Session Border Controller skips it when using alternate routing and uses other routes for the policy.

A session agent might go out of service when it exceeds the maximum number of consecutive transaction timeouts to the maximum number of allowable transaction timeouts. Applicable session agent constrain parameter of note are:

trans-timeouts—Maximum number of allowable transaction timeouts (default is 5)
ttr-no-response—Dictates when the SA (Session Agent) should be put back in service after the SA is taken OOS (Out Of Service) because it did not respond to the Oracle® Enterprise Session Border Controller
in-service-period—Amount of time that elapses before a session agent is put back in service after the ttr-no-response period has passed

By default, the Oracle® Enterprise Session Border Controller continues to send LRQ messages to a session agent even if the session agent has already sent an LRJ. However, you might want to place a session agent out of service when it has sent a certain number of LRJs; doing so allows alternate routing to take place faster, but this is an optional feature.

To configure an LRJ threshold, you add the max-lrj value to an H.323 session agent’s options parameter; instructions for how to set it and the required syntax appear below. If you do not set this option, then the Oracle® Enterprise Session Border Controller will not put session agents out of service for matters related to LRJs.

If you do set this option (to a non-zero value), then the Oracle® Enterprise Session Border Controller keeps a count of the LRJs received from a session agent. When it receives an LCF from a session agent, the Oracle® Enterprise Session Border Controller resets the counter to zero. This count is used internally only and is not accessible through statistics displays.

If a session agent exceeds the maximum number of LRJs and goes out of service, it remains in that state until the ttr-no-response period has passed and it has transitioned through the in-service-period time. If the ttr-no-response period is zero, then the session agent is never put out of service.