In a typical H.323 call setup scenario, after RAS messages are exchanged, H.225 setup messages are sent over a control channel. For example, in the figure below, both gateways are registered to the same gatekeeper, and the gatekeeper has chosen direct call signaling.
- Gateway 1 (the calling gateway) initiates the admission request (ARQ) (1)/admission confirmation (ACF) (2) exchange with that gatekeeper.
- The gatekeeper returns the call signaling channel address of Gateway 2 (the called gateway) in the ACF.
- Gateway 1 then sends the setup (3) message to Gateway 2 using that transport address.
- The setup is complete and the call is proceeding (4).
- If Gateway 2 wishes to accept the call, it initiates an ARQ (5)/ACF (6) exchange with the gatekeeper.
- The gatekeeper responses with ACF/ARJ (6).
- Gateway 2 sends an alerting (7) message to Gateway 1. (If Gateway 2 receives an admission reject [ARJ] (6) message instead of an ACF message, it sends a release complete message to Gateway 1 instead of the alerting message.)
- Gateway 2 responds with the connect (8) messege to Gateway 1
An H.245 control channel transport for use in H.245 signalling can send in any of the H.225 messeges: call proceeding, alerting, or connect.
|Figure 4 ||Both Gateways Registered to the Same Gatekeeper |
Fast connect allows endpoints to establish media channels without waiting for a separate H.245 connection to be opened. This streamlines the number of messages that are exchanged and the amount of processing that must be done before endpoint connections can be established. A high-level view of the fast-connect procedures within the H.323 protocol follows:
- The calling endpoint transmits a setup message containing the fastStart element that contains a sequence of encoded logical channel structures, each representing a different capability media type for both "send" and "receive" directions.
- The called endpoint selects one or more of the media types offered by the calling endpoint for the send and receive directions and returns its selections in a fastStart element in any H.225 message up to and including connect. At this point, the called endpoint must be prepared to receive media along any of the channels it selected.
- If H.245 procedures are needed and one or both of the endpoints do not support tunneling, a separate H.245 connection is used.
Fast connect is not explicitly configurable. All H.323 Version 2 VoIP endpoints are capable of initiating or accepting fast-connect calls. It is assumed that the gateway is capable of sending and receiving fast-connect procedures unless its corresponding dial peer has been configured for the Resource Reservation Protocol (RSVP). RSVP means the quality of service is set by the req-qos command to a value other than the default of best-effort. If the dial peer has been configured for RSVP, traditional "slow" connect procedures are followed, and the endpoint neither attempts to initiate fast connect nor responds to a fast-connect request from its peer.
A terminating endpoint can reject fast connect by simply omitting the fastStart element from all H.225 messages up to and including connect. In this case, normal H.245 procedures are followed and a separate H.245 TCP connection is established. So, if an endpoint does not support the fast-connect procedures, normal H.245 procedures are followed. In addition, certain conditions can cause a fast-connect call to fall back to normal H.245 procedures to complete the call.
Once a media connection has been opened (an audio path has been established), either endpoint has the option of switching to H.245 procedures (if they are needed) by using H.245 tunneling, whereby H.245 messages are encapsulated within the h245Control element of H.225 messages.
The dtmf-relay command is the only H.245-cognizant command that can initiate H.245-tunneling procedures from a fast-connect call. If H.245 tunneling is active on the call, switching to a separate H.245 connection is not supported.
A Cisco terminating endpoint accepts a fast-connect request only if a pair of symmetric codecs (codecs that in both directions are equivalent or identical) can be selected from a list that has been offered. The originating endpoint is constrained only by what it can send through the codec (or voice class codec list) associated with the dial peer.
If the Cisco originating endpoint has offered multiple codecs and the terminating endpoint selects a pair of asymmetric (mismatched) codecs, the originating endpoint initiates separate H.245 procedures to correct the asymmetric codec situation.
Fast connect is backward compatible with H.323 Version 1 configurations.