1.2.6. H.323 Call Scenario Via a Gateway

While the call scenario described in Section 1.2.4, Basic H.323 Call Scenario is useful for explaining the fundamentals of an H.323 call, is not a realistic call scenario. The IP addresses of both endpoints were defined to be known. Most Internet Service Providers (ISPs) allocate IP addresses to subscribers dynamically. This section describes the fundamentals of a more realistic example that involves a gateway.

A gateway provides a bridge between different technologies for example, an H.323 gateway (or IP gateway) provides a bridge between an IP network and the PSTN. Figure 3 shows a configuration that uses a gateway. User A is at a terminal, while user B is by a phone connected to the PSTN.

Figure 3. Basic H.323 Network with a Gateway

Figure 3 also shows a gatekeeper. The gatekeeper provides network services such as Registration, Admission and Status (RAS) and address mapping. When a gatekeeper is present, all endpoints managed by the gatekeeper must register with the gatekeeper at startup. The gatekeeper tracks which endpoints are accepting calls. The gatekeeper can perform other functions also, such as redirecting calls. For example, if a user does not answer the phone, the gatekeeper may redirect the call to an answering machine.

The call scenario in this example involves the following phases:

• Establishing Contact with the Gatekeeper
• Requesting Permission to Call
• Call Signaling and Data Exchange
• Call Termination

Establishing Contact with the Gatekeeper

The user at endpoint A attempts to locate a gatekeeper by sending out a Gatekeeper Request (GRQ) message and waiting for a response. When it receives a Gatekeeper Confirm (GCF) message, the endpoint registers with the Gatekeeper by sending the Registration Request (RRQ) message and waiting for a Registration Confirm (RCF) message. If more than one gatekeeper responds, endpoint A chooses only one of the responding gatekeepers. The next phase of the call scenario, Requesting Permission to Call, can now begin.

Requesting Permission to Call

After registering with the gatekeeper, endpoint A must request permission from the gatekeeper to initiate the call. To do this, endpoint A sends an Admission Request (ARQ) message to the gatekeeper. This message includes information such as:

• A sequence number
• A gatekeeper assigned identifier
• The type of call, in this example, point-to-point
• The call model to use, either direct or gatekeeper-routed
• The destination address, in this case, the phone number of endpoint B
• An estimation of the amount of bandwidth required. This parameter can be adjusted later by a Bandwidth Request (BRQ) message to the gatekeeper.

If the gatekeeper allows the call to proceed, it sends an Admission Confirm (ACF) message to endpoint A. The ACF message includes the following information:

• The call model used
• The transport address and port to use for call signaling (in this example, the IP address of the gateway)
• The allowed bandwidth

All setup has now been completed and the next phase of the scenario, Call Signaling, can begin.

Call Signaling and Data Exchange

Endpoint A can now sends the Setup message to the gateway. Since the destination phone is connected to an analog line (the PSTN), the gateway goes off-hook and dials the phone number using dual tone multifrequency (DTMF) digits. The gatekeeper therefore is converting the H.225.0 signaling into the signaling present on the PSTN. Depending on the location of the gateway, the number dialed may need to be converted. For example, if the gateway is located in Europe, then the international dial prefix will be removed.

As soon as the gateway is notified by the PSTN that the phone at endpoint B is ringing, it sends the H.225.0 Alerting message as a response to endpoint A. As soon as the phone is picked up at endpoint B, the H.225.0 Connect message is sent to endpoint A. As part of the Connect message, a transport address that allows endpoint A to negotiate codecs and media streams with endpoint B is sent.

The H.225.0 and H.245 signaling used to negotiate capability, initiate and call, and exchange data are the same as that described in the basic H.323 call scenario. See Section , Capability Exchange, Section , Call Initiation, and Section , Data Exchange for more information.

In this example the destination phone is analog, therefore, it requires the gateway to detect the ring, busy and connect conditions so it can respond appropriately.

Call Termination

As in the basic H.323 call scenario example, the endpoint that hangs up first needs to close all the channels that were open using the H.245 CloseLogicalChannel message. If the gateway terminates first, it sends an H.245 EndSessionCommand message to endpoint A and waits for the same message from endpoint A. The gateway then closes the H.245 channel.

When all channels between endpoint A and the gateway are closed, each must send a DisengageRequest (DRQ) message to the gatekeeper. This message lets the gatekeeper know that the bandwidth is being released. The gatekeeper sends a DisengageConfirm (DCF) message to both endpoint A and the gateway.

Click here to contact Telecom Support Resources