Overview
Using H.323 on your Oracle Communications Session Border Controller, you can implement different signaling modes and use features to enhance H.323 capabilities. In the information that follows, you will find detailed explanations of the H.323 signaling mode and of the features available. This chapter gives operational details and later outlines the steps you need to take when features require configuration.
Signaling Modes of Operation
Your Oracle Communications Session Border Controller can operate in different H.323 signaling modes:
- Back-to-back gateway signaling
- Back-to-back gatekeeper proxy and gateway
- Interworking gatekeeper/gateway
Back-to-Back Gateway Signaling
This section explains how signaling takes place when the Oracle Communications Session Border Controller functions as a B2BGW for H.323. The following diagram illustrates the Oracle Communications Session Border Controller acting as a B2BGW.
When configured as a B2BGW, the Oracle Communications Session Border Controller appears as multiple H.323 gateways to multiple networks. You can think of the Oracle Communications Session Border Controller as having virtual gateways, that discovers and registers with a gatekeeper in its respective domain. In this configuration, you need to set the service mode (isgateway) parameter for the H.323 interface to enabled for two H.323 interfaces. These interfaces are related either through their outgoing interface (assoc-stack) parameters or through routing policies.
If you configure your Oracle Communications Session Border Controller to operate in this mode, it does not issue or respond to LRQs by either confirming them or rejecting them.
In the diagram above, the Oracle Communications Session Border Controller sends ARQs to the corresponding gatekeeper in its zone when a call is received on the associated interface. In this behavior, the Oracle Communications Session Border Controller acts as a gateway, complying with the H.323 standard, and registers with the configured gatekeeper in its assigned zone. You set all parameters related to the gateway registrations, such as gateway prefix numbers, in the H.323 interface configuration.
In this mode, you can also configure the Oracle Communications Session Border Controller to run like a gateway without a gatekeeper by turning off automatic discovery (auto-gk-discovery) for the remote gatekeeper. When the Oracle Communications Session Border Controller receives a Setup message, it does not send an ARQ and there is no registration for admission requests. Without automatic gateway discovery, the Oracle Communications Session Border Controller uses the local policy to find the appropriate destination for the call. This destination is normally the IPv4 address of the endpoint or gateway, using the well-known port 1720.
If you enable this capability, then the Oracle Communications Session Border Controller finds a gatekeeper.
Back-to-Back Gatekeeper Proxy and Gateway
This section explains how signaling takes place when the Oracle Communications Session Border Controller functions as a back-to-back gatekeeper proxy and gateway for H.323. The following diagram illustrates theOracle Communications Session Border Controller acting as a B2B gatekeeper proxy and gateway.
In this application, with the service mode (isgateway) parameter set to disabled, the Oracle Communications Session Border Controller responds to LRQs and issues LCFs and LRJs. It sends LRQs and LCFs/LRJs to the local IPv4 address for the H.323 interface. The Oracle Communications Session Border Controller responds to the LRQs by providing a signaling address that performs gateway functions.
When you use it as a back-to-back gatekeeper proxy and gateway, the Oracle Communications Session Border Controller does not issue ARQs. In addition, all parameters related to registration, such as gateway prefix numbers, are ignored.
When you do not configure a gatekeeper, the Oracle Communications Session Border Controller uses the local policy to find the appropriate destination for the call. If there is a matching local policy, the Oracle Communications Session Border Controller returns an LCF to the originating gateway. If no local policy matches, the Oracle Communications Session Border Controller rejects the call by sending an LRJ.
Interworking Gatekeeper-Gateway
This section explains how signaling takes place when the Oracle Communications Session Border Controller functions as an interworking gatekeeper-gateway for H.323. The following diagram shows the Oracle Communications Session Border Controller acting as an interworking gatekeeper-gateway.
![The OCSBC acting as an H323 interworking gatekeeper/gateway. The OCSBC acting as an H323 interworking gatekeeper/gateway.](img/h323-b2b-gatekeeper-gateway.png)
When you configure your Oracle Communications Session Border Controller for interworking gatekeeper-gateway mode, one H.323 interface behaves as a B2BGW and its associated interface for the corresponding network behaves like a gatekeeper proxy and gateway. The interface for the gatekeeper proxy and gateway issues and responds to LRQ messages on its network. If the Oracle Communications Session Border Controller knows the gatekeeper in the network of the gateway interface (Zone 2), it sends an LRQ to that gatekeeper. If the gatekeeper responds with an LCF or LRJ, the Oracle Communications Session Border Controller forwards it.
If the gatekeeper (in Zone 2) is unknown, then the Oracle Communications Session Border Controller responds to LRQs on the gatekeeper-gateway network (Zone 1) by using the local policy to determine the appropriate destination for the LRQ. If there is no local policy that matches, then the Oracle Communications Session Border Controller sends an LRJ.
For this configuration, the gateway interface has its service mode (isgateway) set to enabled, and the gatekeeper interface has its service mode (isgateway) set to disabled.