H.323 Routing

This section describes H.323 routing.

Egress Stack Selection

Egress stack selection includes static stack selection and policy-based stack selection

Static Stack Selection

In static stack selection, the outgoing stack is determined though the establishment of associated stacks in the h323 stack.

The incoming stack (configured in the h323 stack) uses its associated stack value to determine the associated outgoing stack. The associated stack value corresponds to the name of an h323 stack. This type of selection is referred to as static because the incoming stack always uses the stack specified in the associated stack as the outgoing stack; no other stacks are considered.

Policy-Based Stack Selection

The Oracle® Enterprise Session Border Controller performs dynamic, policy-based stack selection when an H.323 call arrives at the Oracle® Enterprise Session Border Controller and a configured associated outgoing stack cannot be found.

For policy-based stack selection, the Oracle® Enterprise Session Border Controller refers to local policies that contain address information that corresponds to incoming traffic. This information is contained in the local policy’s To address and From address fields. For the source, this information is matched with the Q.931 calling party number; if there is no calling party number, the H.323 source address is used. For the destination, this information is matched with the called party number; if there is no called party number, then the H.323 destination address is used.

After a local policy corresponding to the incoming traffic has been found, the Oracle® Enterprise Session Border Controller looks at the next hop value (a local policy attribute) and selects a local policy for the basis of stack selection. If the local policy look-up yields multiple local policies with the same next hop values, but with different cost values, the local policy with the lowest cost value is selected.

If a realm is not defined in the local policy, the next hop address is then matched against the address prefix values for the realms that are configured for the system. Thus, the Oracle® Enterprise Session Border Controller discovers the realm for this traffic. Using this realm information, the Oracle® Enterprise Session Border Controller performs stack selection. It uses the first configured H.323 stack in the Oracle® Enterprise Session Border Controller’s configuration that has a realm ID value matching the identifier field of the realm with the appropriate address prefix.

In the following example, the local policy matching yields a local policy with a next hop value of 169.125.4.1, which corresponds to RealmB. The outgoing stack selected is Stack 3 because it is the first stack to have been configured with RealmB as the realm ID.

Policy-Based Stack Selection

Registration Caching

The Oracle® Enterprise Session Border Controller can cache and proxy an H.225 RegistrationRequest (RRQ) between an H.323 endpoint and a gatekeeper. Registration caching serves two functions:

• It allows aggregation of RRQs sent to a gatekeeper stack and proxies those requests through the gateway stack. If the external gatekeeper associated with the gatekeeper stack supports additive registration, the requests will be consolidated. Furthermore, if the gatekeeper supports additive registration, the Oracle® Enterprise Session Border Controller will register in an additive manner, meaning that will send additive RRQs.
• It allows the gatekeeper stack to use the registration information to route calls from other realms to endpoints in its realms.

To perform registration caching, the Oracle® Enterprise Session Border Controller must be configured with at least two stacks. One of these stacks will receive registrations (gatekeeper stack), and one stack will proxy registrations (gateway stack). The Oracle® Enterprise Session Border Controller caches all successful registrations and uses the cache to route calls to the endpoints.

Gatekeeper Provided Routes

Gatekeeper provided routes includes back-to-back gateways, back-to-back gatekeeper and gateway, and interworking gatekeeper/gateway.

Back-to-Back Gateway

When the Oracle® Enterprise Session Border Controller is functioning as a back-to-back gateway (B2BGW), it appears as multiple H.323 gateways to multiple networks. Each Oracle® Enterprise Session Border Controller virtual gateway discovers and registers with a gatekeeper in its respective domain. Each gateway relies on its gatekeeper for admission and location services through the ARQ/ACF exchange. H.225 call control and H.245 messages are exchanged directly with the terminating gateway or gatekeeper. Routing policies are used to associate one virtual gateway with another.

The following diagram illustrates the back-to-back gateway.

Back-to-Back Gatekeeper and Gateway

For peering connections where both networks use inter-domain gatekeeper signaling, the Oracle® Enterprise Session Border Controller is configured as a back-to-back gatekeeper proxy and gateway mode of operation. The Oracle® Enterprise Session Border Controller responds and issues LRQs and LCFs/LRJs acting as a routed gatekeeper. Peered gatekeepers send LRQ to the RAS address of one of the Oracle® Enterprise Session Border Controller’s virtual gatekeepers and it responds by providing its call signaling address that performs the gateway functions. Routing policies are used to determine the egress virtual gatekeeper that then exchanges LRG/LCF to determine the call signaling address of the terminating gateway.

The following diagram illustrates the back-to-back gatekeeper and gateway.

Interworking Gatekeeper Gateway

In the interworking gatekeeper/gateway signaling mode of operation, the Oracle® Enterprise Session Border Controller interworks between the other two modes; presenting a routed gatekeeper interface to one zone and a gateway to the other.

The following diagram illustrates the interworking gatekeeper/gateway.