H.323 Call Establishment

In theexample of Figure 8-5, two terminals (H.323 endpoints) need to establish
a VoIP call between them, and different gatekeepers control the two
terminals. As a first step, the calling terminal requests permission from its
gatekeeper to establish the call. This is done with the Admission Request
(ARQ) message. The terminal indicates the type of call in question (twoparty
or multi-party), the endpoint’s own identifier, a call identifier (a
unique string), a call reference value (an integer value also used in call signaling
messages for the same call), and information regarding the other
party or parties to participate in the call. The information regarding other
parties to the call includes one or more aliases and/or signaling addresses.
One of the most important mandatory parameters in the ARQ is the bandwidth
parameter. This specifies the amount of bandwidth required in units
of 100 bps.
Note that the endpoint should request the total media stream bandwidth
needed, excluding overhead. Thus, if a two-party call is needed, with each
party sending voice at 64 Kbps, then the bandwidth required is 128 Kbps,
and the value carried in the bandwidth parameter is 1280. The purpose of
the bandwidth parameter is to enable the gatekeeper to reserve resources
for the call.
The gatekeeper indicates a successful admission by responding to the
endpoint with an AdmissionConfirm (ACF) message. This includes many of
the same parameters that are included in the ARQ. The difference is that,
when a given parameter is used in the ARQ, it is simply a request from the endpoint, whereas a given parameter value in the ACF is a firm order from
the gatekeeper. For example, the ACF includes the bandwidth parameter,
which may be a lower value than that requested in the ARQ, in which case the endpoint must stay within the bandwidth limitations imposed by the
gatekeeper.
Another parameter of particular interest in both the ARQ and the ACF
is the callModel parameter, which is optional in the ARQ and mandatory in
the ACF. In the ARQ, callModel indicates whether the endpoint wants to
send call signaling directly to the other party, or prefers that call signaling
be passed via the gatekeeper. In the ACF, it represents the gatekeeper’s
decision as to whether call signaling is to pass via the gatekeeper or directly
between the terminals. In the example of Figure 8-5, the calling gatekeeper
has chosen not to be in the path of the call signaling.
The Setup message is the first call-signaling message sent from one terminal
to the other to establish the call. The message must contain the Q.931
Protocol Discriminator, a Call ReferenceSetup, a Bearer Capability, and the
User-User information element. Although the Bearer Capability information
element is mandatory, the concept of a bearer, as used in the circuitswitched
world, does not map very well to an IP network. For example, no
B-channel exists in IP and the actual agreement between endpoints regarding
the bandwidth requirements is done as part of H.245 signaling, where
RTP information such as the payload type is exchanged. Consequently,
many of the fields in the Bearer Capability information element, as defined
in Q.931, are not used in H.225.0. Of those fields that are used in H.225.0,
many are used only when the call has originated from outside the H.323
network and has been received at a gateway, where the gateway performs a
mapping from the signaling received to the appropriate H.225.0 messages.
A number of parameters are included within the mandatory User-to-
User information element. These include the call identifier, the call type, a
conference identifier, and information about the originating endpoint.
Among the optional parameters, we may find a source alias, a destination
alias, an H.245 address for subsequent H.245 messages, and a destination
call-signaling address. The User-to-User information element is included in
all H.225.0 call-signaling messages. It is the inclusion of this information
element that enables Q.931 messages, originally designed for ISDN, to be
adapted for use with H.323.
The Call Proceeding message may optionally be sent by the recipient of
a Setup message to indicate that the Setup message has been received and
that call establishment procedures are underway. When sent, it usually precedes
the Alerting message, which indicates that the called device is “ringing.”
Strictly speaking, the Alerting message is optional.
In addition to Call Proceeding and Alert, we may also find the optional
Progress message (not shown). Ultimately, when the called party answers, the called terminal returns a Connect message. Although some of the messages
from the called party to the calling party, such as Call Proceeding and
Alerting, are optional, the Connect message must be sent if the call is to be
completed. The User-User information element contains the same set of
parameters as defined for the Call Proceeding, Progress, and Alert messages,
with the addition of the Conference Identifier. These parameters are
also used in a Setup message and their use in the Connect message is to
correlate this conference with that indicated in a Setup. Any H.245 address
sent in a Connect message should match that sent in any earlier Call Proceeding,
Alerting, or Progress messages. In fact, the called terminal must
include at least an H.245 signaling address to which H.245 messages must
be sent because H.245 messages are used to establish the media (that is,
voice) flow between the parties.
In the example of Figure 8-5, the H.245 message exchange begins after
the Connect message is returned. This message exchange could, in fact,
occur earlier than the Connect message. It is important to note that H.245
is not responsible for carrying the actual media. For example, there is no
such thing as an H.245 packet containing a sample of coded voice. That is
the job of RTP. Instead, H.245 is a control protocol that manages the establishment
and release of media sessions. H.245 does this through messaging
that enables the establishment of logical channels, where a logical channel
is a unidirectional RTP stream from one party to the other.
A logical channel is opened by sending an Open Logical Channel (OLC)
request message. This message contains a mandatory parameter called forwardLogicalChannelParameters,
which relates to the media to be sent in the
forward direction, that is, from the endpoint issuing this command. It contains
information such as the type of data to be sent (e.g. AMR-coded audio),
an RTP session ID, an RTP payload type, and an indication as to whether
silence suppression is to be used. If the recipient of the message wants to
accept the media to be sent, then it will return an OpenLogicalChannelAck
message containing the same logical channel number as received in the
request and a transport address to which the media stream should be sent.
Strictly speaking, a logical channel is unidirectional.Therefore, in order to
establish a two-way conversation, two logical channels must be opened—one
in each direction. According to the description just presented, this requires
four messages, which is rather cumbersome. Consequently, H.323 defines a
bidirectional logical channel. This is a means of establishing two logical
channels, one in each direction, in a slightly more efficient manner. Basically,
a bidirectional logical channel really means two logical channels that are
associated with each other. The establishment of these two channels can be achieved with just three H.245 messages rather than four. In order to do so,
the initial OLC message not only contains information regarding the media
that the calling endpoint wants to send, but it also contains reverse logical
channel parameters. These indicate the type of media that the endpoint is
willing to receive and to where that media should be sent.
Upon receipt of the request, the far endpoint may send an Open Logical
Channel Ack message containing the same logical channel number for the
forward logical channel, a logical channel number for the reverse logical
channel, and descriptions related to the media formats that it is willing to
send. These media formats should be chosen from the options originally
received in the request, thereby ensuring that the called end will only send
media that the calling end supports.
Upon receipt of the Open Logical Channel Ack, the originating endpoint
responds with an Open Logical Channel Confirm message to indicate that
all is well. RTP streams and RTCP messages can now flow in each direction.