Documente Academic
Documente Profesional
Documente Cultură
ITU-T H.323
TELECOMMUNICATION (12/2009)
STANDARDIZATION SECTOR
OF ITU
Summary
Recommendation ITU-T H.323 describes terminals and other entities that provide multimedia
communications services over Packet-Based Networks (PBN) which may not provide a guaranteed
Quality of Service. H.323 entities may provide real-time audio, video and/or data communications.
Support for audio is mandatory, while data and video are optional, but if supported, the ability to use
a specified common mode of operation is required, so that all terminals supporting that media type
can interwork.
The packet-based network over which H.323 entities communicate may be a point-to-point
connection, a single network segment, or an internetwork having multiple segments with complex
topologies.
H.323 entities may be used in point-to-point, multipoint, or broadcast (as described in
Rec. ITU-T H.332) configurations. They may interwork with H.310 terminals on B-ISDN, H.320
terminals on N-ISDN, H.321 terminals on B-ISDN, H.322 terminals on Guaranteed Quality of
Service LANs, H.324 terminals on GSTN and wireless networks, V.70 terminals on GSTN, and
voice terminals on GSTN or ISDN through the use of Gateways.
H.323 entities may be integrated into personal computers or implemented in stand-alone devices
such as videotelephones.
Note that the title of H.323 (1996) was "Visual telephone systems and equipment for local area
networks which provide a non-guaranteed quality of service". The title changed in Version 2 to be
consistent with its expanded scope.
Products claiming compliance with Version 1 of H.323 shall comply with all of the mandatory
requirements of H.323 (1996) which references Rec. ITU-T H.225.0 (1996) and Rec. ITU-T H.245
(1997). Version 1 products shall be identified by H.225.0 messages containing a protocolIdentifier
= {itu-t(0) recommendation(0) h(8) 2250 version(0) 1} and H.245 messages containing a
protocolIdentifier = {itu-t(0) recommendation(0) h(8) 245 version(0) 2}.
Products claiming compliance with Version 2 of H.323 shall comply with all of the mandatory
requirements of this Recommendation, H.323 (1998), which references Rec. ITU-T H.225.0 (1998)
and Rec. ITU-T H.245 (1998 or later). Version 2 products shall be identified by H.225.0 messages
containing a protocolIdentifier = {itu-t(0) recommendation(0) h(8) 2250 version(0) 2} and H.245
messages containing a protocolIdentifier = {itu-t(0) recommendation(0) h(8) 245 version(0) x},
where "x" is 3 or higher.
Products claiming compliance with Version 3 of H.323 shall comply with all of the mandatory
requirements of this Recommendation, H.323 (1999), which references Rec. ITU-T H.225.0 (1999)
and Rec. ITU-T H.245 (1999 or later). Version 3 products shall be identified by H.225.0 messages
containing a protocolIdentifier = {itu-t(0) recommendation(0) h(8) 2250 version(0) 3} and H.245
messages containing a protocolIdentifier = {itu-t(0) recommendation(0) h(8) 245 version(0) x},
where "x" is 5 or higher.
Products claiming compliance with Version 4 of H.323 shall comply with all of the mandatory
requirements of this Recommendation, H.323 (2000), which references Rec. ITU-T H.225.0 (2000)
and Rec. ITU-T H.245 (2000 or later). Version 4 products shall be identified by H.225.0 messages
containing a protocolIdentifier = {itu-t(0) recommendation(0) h(8) 2250 version(0) 4} and H.245
messages containing a protocolIdentifier = {itu-t(0) recommendation(0) h(8) 245 version(0) x},
where "x" is 7 or higher.
History
Edition Recommendation Approval Study Group
1.0 ITU-T H.323 1996-11-11 16
2.0 ITU-T H.323 1998-02-06 16
2.1 ITU-T H.323 Annex D 1998-09-25 16
2.2 ITU-T H.323 Annex E 1999-05-27 16
2.3 ITU-T H.323 Annex F 1999-05-27 16
3.0 ITU-T H.323 1999-09-30 16
3.1 ITU-T H.323 Annex G 2000-02-17 16
4.0 ITU-T H.323 2000-11-17 16
4.1 ITU-T H.323 Annex M3 2001-07-29 16
4.2 ITU-T H.323 Annex Q 2001-07-29 16
4.3 ITU-T H.323 Annex R 2001-07-29 16
4.4 ITU-T H.323 Annex P 2003-01-13 16
5.0 ITU-T H.323 2003-07-14 16
5.1 ITU-T H.323 (2003) Amend. 1 2005-01-08 16
5.2 ITU-T H.323 (2003) Amend. 2 2005-01-13 16
6.0 ITU-T H.323 2006-06-13 16
7.0 ITU-T H.323 v7 2009-12-14 16
NOTE
In this Recommendation, the expression "Administration" is used for conciseness to indicate both a
telecommunication administration and a recognized operating agency.
Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain
mandatory provisions (to ensure e.g., interoperability or applicability) and compliance with the
Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some
other obligatory language such as "must" and the negative equivalents are used to express requirements. The
use of such words does not suggest that compliance with the Recommendation is required of any party.
ITU 2010
All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the
prior written permission of ITU.
1 Scope
This Recommendation covers the technical requirements for multimedia communications systems
in those situations where the underlying transport is a Packet-Based Network (PBN) which may not
provide a guaranteed Quality of Service (QoS). These packet-based networks may include Local
Area Networks, Enterprise Area Networks, Metropolitan Area Networks, Intra-Networks and
Inter-Networks (including the Internet). They also include dial up connections or point-to-point
connections over the GSTN or ISDN which use an underlying packet-based transport such as PPP.
These networks may consist of a single network segment, or they may have complex topologies
which incorporate many network segments interconnected by other communications links.
This Recommendation describes the components of an H.323 system. This includes Terminals,
Gateways, Gatekeepers, Multipoint Controllers, Multipoint Processors and Multipoint Control
Units. Control messages and procedures within this Recommendation define how these components
communicate. Detailed descriptions of these components are contained in clause 6.
H.323 terminals provide audio and optionally video and data communications capability in
point-to-point or multipoint conferences. Interworking with other H-series terminals, GSTN or
ISDN voice terminals, or GSTN or ISDN data terminals is accomplished using Gateways.
See Figure 1. Gatekeepers provide admission control and address translation services. Multipoint
Controllers, Multipoint Processors and Multipoint Control Units provide support for multipoint
conferences.
The scope of H.323 does not include the network interface, the physical network or the transport
protocol used on the network. Examples of these networks include but are not limited to:
– Ethernet (IEEE 802.3);
– Fast Ethernet (IEEE 802.3u);
– FDDI;
– Token Ring (IEEE 802.5);
– ATM.
Packet-based network
(Note)
ITU-T H.323 ITU-T H.323 ITU-T H.323 ITU-T H.323
gatekeeper gateway terminal terminal
Guaranteed
GSTN QoS N-ISDN B-ISDN
LAN ITU-T H.310
terminal
operating in
H.321 mode
ITU-T V.70 ITU-T H.324 Speech ITU-T H.322 Speech ITU-T H.320 ITU-T H.321 ITU-T H.321
terminal terminal terminal terminal terminal terminal terminal terminal
NOTE – A gateway may support one or more of the GSTN, N-ISDN and/or B-ISDN connections. H.323(06-06)_F01
2 References
The following ITU-T Recommendations and other references contain provisions which, through
reference in this text, constitute provisions of this Recommendation. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision;
users of this Recommendation are therefore encouraged to investigate the possibility of applying the
most recent edition of the Recommendations and other references listed below. A list of the
currently valid ITU-T Recommendations is regularly published. The reference to a document within
this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
[1] Recommendation ITU-T H.225.0 (2009), Call signalling protocols and media stream
packetization for packet-based multimedia communication systems.
[2] Recommendation ITU-T H.245 (2009), Control protocol for multimedia communication.
[3] Recommendation ITU-T G.711 (1988), Pulse code modulation (PCM) of voice frequencies.
[4] Recommendation ITU-T G.722 (1988), 7 kHz audio-coding within 64 kbit/s.
[5] Recommendation ITU-T G.723.1 (2006), Dual rate speech coder for multimedia
communications transmitting at 5.3 and 6.3 kbit/s.
[6] Recommendation ITU-T G.728 (1992), Coding of speech at 16 kbit/s using low-delay code
excited linear prediction.
[7] Recommendation ITU-T G.729 (1996), Coding of speech at 8 kbit/s using
conjugate-structure algebraic-code-excited linear prediction (CS-ACELP).
3 Definitions
For the purposes of this Recommendation, the definitions given in clause 3/H.225.0 [1] and
clause 3/H.245 [2] apply, along with those in this clause. These definitions apply to the
packet-based network side only. Other terms may be appropriate when referring to the Switched
Circuit Network (SCN) side. See clause 5, Conventions, for information on the use of terms in this
Recommendation.
3.1 access gateway: A Gateway that connects one network to another network (such as an
SS7 network to a QSIG network) and performs some interworking function between the different
networks.
3.2 active MC: An MC that has won the master-slave determination procedure and is currently
providing the multipoint control function for the conference.
3.3 ad hoc multipoint conference: An Ad Hoc Multipoint conference was a point-to-point
conference that had been expanded into a multipoint conference at some time during the call. This
can be done if one or more of the terminals in the initial point-to-point conference contains an MC,
if the call is made using a Gatekeeper that includes MC functionality, or if the initial call is made
through an MCU as a multipoint call between only two terminals.
3.4 addressable: An H.323 entity on the network having a Transport Address is addressable.
Not the same as being callable. A terminal, Gateway, or MCU is addressable and callable. A
Gatekeeper is addressable but not callable. An MC or MP is neither callable nor addressable but is
contained within an endpoint or Gatekeeper that is. In a composite Gateway, both the MGC and the
MG are addressable, but only the MGC is callable.
3.5 audio mute: Suppressing of the audio signal of a single or all source(s). Send muting
means that the originator of an audio stream mutes its microphone and/or does not transmit any
audio signal at all. Receive mute means that the receiving terminal ignores a particular incoming
audio stream or mutes its loudspeaker.
3.6 broadcast conference: A Broadcast conference is one in which there is one transmitter of
media streams and many receivers. There is no bidirectional transmission of control or media
streams. Such conferences should be implemented using network transport multicast facilities, if
available. Also see Rec. ITU-T H.332 [23].
3.7 broadcast panel conference: A Broadcast Panel conference is a combination of a
Multipoint conference and a Broadcast conference. In this conference, several terminals are
engaged in a multipoint conference, while many other terminals are only receiving the media
streams. There is bidirectional transmission between the terminals in the multipoint portion of the
conference and no bidirectional transmission between them and the listening terminals. Also see
Rec. ITU-T H.332.
3.8 call: Point-to-point multimedia communication between two H.323 endpoints. The call
begins with the call set-up procedure and ends with the call termination procedure. The call consists
of the collection of reliable and unreliable channels between the endpoints. A call may be directly
between two endpoints or may include other H.323 entities such as a Gatekeeper or MC. In case of
interworking with some SCN endpoints via a Gateway, all the channels terminate at the Gateway
where they are converted to the appropriate representation for the SCN end system. Typically, a call
is between two users for the purpose of communication, but may include signalling-only calls. An
endpoint may be capable of supporting multiple simultaneous calls.
3.32 multicast: A process of transmitting PDUs or a media stream from one source to many
destinations. The actual mechanism (i.e., IP multicast, multi-unicast, etc.) for this process may be
different for different network technologies.
3.33 multipoint conference: A Multipoint conference is a conference between three or more
terminals. The terminals may be on the network or on the SCN. The multipoint conference shall
always be controlled by an MC. Various multipoint conference types are defined in this subclause
but they all require a single MC per conference. They may also involve one or more H.231 MCUs
on the SCN. A terminal on the network may also participate in an SCN multipoint conference by
connecting via a Gateway to an SCN-MCU. This does not require the use of an MC.
3.34 multipoint control unit: The Multipoint Control Unit (MCU) is an endpoint on the
network which provides the capability for three or more terminals and Gateways to participate in a
multipoint conference. It may also connect two terminals in a point-to-point conference which may
later develop into a multipoint conference. The MCU generally operates in the fashion of an H.231
MCU; however, an audio processor is not mandatory. The MCU consists of two parts: a mandatory
Multipoint Controller and optional Multipoint Processors. In the simplest case, an MCU may
consist only of an MC with no MPs. An MCU may also be brought into a conference by the
Gatekeeper without being explicitly called by one of the endpoints.
3.35 multipoint controller: The Multipoint Controller (MC) is an H.323 entity on the network
which provides for the control of three or more terminals participating in a multipoint conference. It
may also connect two terminals in a point-to-point conference which may later develop into a
multipoint conference. The MC provides for capability negotiation with all terminals to achieve
common levels of communications. It may also control conference resources such as who is
multicasting video. The MC does not perform mixing or switching of audio, video and data.
3.36 multipoint processor: The Multipoint Processor (MP) is an H.323 entity on the network
which provides for the centralized processing of audio, video and/or data streams in a multipoint
conference. The MP provides for the mixing, switching or other processing of media streams under
the control of the MC. The MP may process a single media stream or multiple media streams
depending on the type of conference supported.
3.37 multi-unicast: A process of transferring PDUs or a media stream where an endpoint sends
more than one copy of a media stream, but to different endpoints. This may be necessary in
networks which do not support multicast.
3.38 object identifier: A globally unique value associated with an object to unambiguously
identify it.
Figure 3 – Zone
6 System description
This Recommendation describes the elements of the H.323 components. These are Terminals,
Gateways, Gatekeepers, MCs and MCUs. These components communicate through the
transmission of Information Streams. The characteristics of these components are described in this
clause.
Video codec
Video I/O equipment ITU-T H.261,
ITU-T H.263
Receive
Audio codec path
ITU-T G.711, delay
Audio I/O equipment
ITU-T G.722,
ITU-T G.723,
ITU-T G.728,
ITU-T G.729 Network
interface
User data applications ITU-T H.225.0
ITU-T T.120, etc. layer
System control
ITU-T H.245
control
RAS control
ITU-T H.225.0
H.323(06-06)_F04
Gateway A
Gateway B
Network
Gateway C
Gateway D
H.323(06-06)_F05
X B1 C D SCN Z
ITU-T H.245 High layer SCN
signalling
signalling resource signalling
transport
termination control termination termination
B2 H.323(06-06)_F06
X ITU-T H.225.0
signalling A
termination
Low layer
resource
control
Packet and
Y circuit Z
media
termination
MGC
SCN
ITU-T H.245 High layer SCN D signalling
signalling resource signalling
transport
termination control termination termination
ITU-T H.225.0
signalling
termination
H.323(06-06)_F07
MG
Low layer
resource
control
Packet and
circuit
media
termination
RAS
signalling
termination
ITU-T H.225.0
signalling
termination
A C
MG
Packet and
Low layer
circuit
media signalling
termination
termination
H.323(06-06)_F08
SCN
RAS High layer SCN D
signalling
signalling resource signalling
transport
termination control termination termination
H.323(06-06)_F09
B A
MG
Packet and
ITU-T H.245
circuit
signalling
media
termination
termination
B A C
MG
Packet and
ITU-T H.245 Low layer
circuit
signalling media signalling
termination termination
termination
H.323(06-06)_F10
Higher
ITU-T H.245 High layer
layer
signalling resource
signalling
termination control
termination
ITU-T H.225.0
signalling
termination
A D
MG
Low layer
resource
control
Lower
layer
signalling
Packet and termination
circuit
media
termination
H.323(06-06)_F11
Tunnelled Tunnelled
QSIG BE BE ISUP
ISUP Annex C/
ITU-T H.246
interface
ITU-T H.323
Media
GK
controller GK routed
(MGC) ITU-T H.225.0
ITU-T H.248
Figure 16 illustrates the same application in which the service provider access Gateway is also
decomposed. In this case, interface A is used to control the channel associated signalling. The
MGCs communicate with each other using interface X. In this particular case, if there is no
signalling backhaul between the MG and the MGC, the amount of information on the call available
to the MGC will be limited to what is defined by Rec. ITU-T H.248.1. In this example, X is H.225.0
and the MGC on the right is performing Annex E/H.246 ISUP interworking.
In considering which of these approaches might be best for a particular application, the following
factors should be considered:
• Number of lines to be connected.
• Cost of trunks.
• Homologation issues.
• Capacity of the MGC.
• Number of access Gateways relative to trunking Gateways.
• Type of CAS protocols to be supported.
• Service provider call processing architecture.
• Network design.
For access Gateways, the application environment will determine whether a decomposed Gateway,
an H.323 terminal using H.450.x, an Annex L stimulus terminal, or a composite Gateway is the
most appropriate.
6.3.2.4 Enterprise trunking gateways
Figure 17 illustrates an enterprise gateway that is used between PBXs in a private voice network.
The packet network is used instead of leased lines to connect the PBXs. In this case, QSIG is used
for signalling between the PBXs. Since QSIG is a facility associated signalling type, the signalling
may be backhauled from the Media Gateway to the Media Gateway Controller via interface C.
Interface A is used between the MGC and MG for gateway control. MGCs communicate between
each other over interface X, which may be H.225.0 tunnelling QSIG according to Annex M1.
ITU-T H.323
endpoint MGC
X
C A
Media
flow
MG
ISDN
PRI
H.323(06-06)_F19
Another enterprise access application uses H.248 to manage terminals, but appears as a composite
Gateway to composite Gateways on other premises as shown in Figure 20. In this example, H.450.x
is used to provide supplementary services interworking.
An additional enterprise access application uses Annex L to manage terminals, but appears as a
composite Gateway to composite Gateways on other premises as shown in Figure 21. In this
example, H.450.x may be used to provide supplementary services interworking. In this example, X1
is H.225.0 with H.450, while X2 is H.225.0 with Annex L stimulus signalling.
It should be noted that the Annex L terminals of Figure 21 may interwork with the H.248 managed
terminals of Figure 20 using H.450.x. These configurations allow extensive feature innovation on
the enterprise while supporting inter-enterprise interoperability using H.450.x. Note that Gatekeeper
routed call signalling is used in Figure 21 in the enterprise Gatekeeper managing the Annex L
terminals, although the other enterprise Gateways may use the direct call model and have a different
Gatekeeper.
7 Call signalling
Call signalling is the messages and procedures used to establish a call, request changes in
bandwidth of the call, get status of the endpoints in the call, and disconnect the call. Call signalling
uses messages defined in Rec. ITU-T H.225.0 and the procedures described in clause 8. This clause
describes some call signalling concepts.
In order to provide redundancy in systems which use a Gatekeeper, the Gatekeeper may indicate
alternate Gatekeepers that may be used in the event of a primary Gatekeeper failure. This list of
alternate Gatekeepers is provided in the alternateGatekeeper field of the GCF/GRJ and RCF/RRJ
messages. The endpoint may also use the Assigned Gatekeeper procedures to re-register with its
primary Gatekeeper when it becomes available again. The Gatekeeper may provide the endpoint
with the address of its Assigned Gatekeeper in the assignedGatekeeper field of the GCF/GRJ and
RCF/RRJ messages.
An endpoint may cancel its registration by sending an Unregister Request (URQ) message to the
Gatekeeper. This allows an endpoint to change the alias address associated with its Transport
Address or vice versa. The Gatekeeper shall respond with either an Unregister Confirmation (UCF)
message or an Unregister Reject (URJ) message according to Gatekeeper policy.
If the endpoint sends a URQ message containing a list of alias addresses, the Gatekeeper shall only
unregister the listed aliases if it chooses to accept the request. If the endpoint sends a URQ message
that does not contain any alias addresses, the Gatekeeper shall unregister all aliases, if any, for the
endpoint if it chooses to accept the request.
A Gatekeeper may cancel the registration of an endpoint by sending an Unregister Request
(URQ) message to the endpoint. The endpoint shall respond with an Unregister Confirmation
(UCF) message. The endpoint shall attempt to re-register with a Gatekeeper prior to initiating any
calls. This may require the endpoint to register with a new Gatekeeper.
If the Gatekeeper sends a URQ message containing a list of alias addresses, the endpoint shall
assume that only those alias addresses are unregistered. A URQ that contains no aliases shall
indicate a request to unregister the endpoint.
An endpoint which is not registered with a Gatekeeper is called an unregistered endpoint. This type
of endpoint does not request admission permission from a Gatekeeper and so cannot participate in
admissions control, bandwidth control, address translation and other functions performed by the
Gatekeeper.
7.2.2.1 Use of lightweight RRQ
An endpoint's registration with a Gatekeeper may have a finite life. An endpoint may request a
timeToLive in the RRQ message to the Gatekeeper. The Gatekeeper may respond with an RCF
containing the same timeToLive, a longer timeToLive, or a shorter timeToLive. If the endpoint
cannot accommodate a larger timeToLive proposed by the Gatekeeper, the endpoint shall use the
largest timeToLive value that it can support and that is less than the timeToLive proposed by the
Gatekeeper. After this time, the registration shall be expired. The timeToLive is expressed in
seconds. Prior to the expiration time, the endpoint may send an RRQ message having the keepAlive
In the scenario shown in Figure 31, both endpoints are registered to the same Gatekeeper, and the
Gatekeeper has chosen to route the call signalling. Endpoint 1 (calling endpoint) initiates the
ARQ (1)/ACF (2) exchange with that Gatekeeper. The Gatekeeper shall return a Call Signalling
Channel Transport Address of itself in the ACF. Endpoint 1 then sends the Setup (3) message using
that Transport Address. The Gatekeeper then sends the Setup (4) message to Endpoint 2. If
Endpoint 2 wishes to accept the call, it initiates an ARQ (6)/ACF (7) exchange with the Gatekeeper.
It is possible that an ARJ (7) is received by Endpoint 2, in which case it sends Release Complete to
the Gatekeeper. Endpoint 2 responds with the Connect (9) message which contains an
H.245 Control Channel Transport Address for use in H.245 signalling. The Gatekeeper sends the
Connect (10) message to Endpoint 1 which may contain the Endpoint 2 H.245 Control Channel
Transport Address or a Gatekeeper H.245 Control Channel Transport Address, based on whether
the Gatekeeper chooses to route the H.245 Control Channel or not.
In the scenario shown in Figure 35, Endpoint 1 (calling endpoint) is not registered with a
Gatekeeper, Endpoint 2 (called endpoint) is registered with a Gatekeeper, and the Gatekeeper has
chosen to route the call signalling. Endpoint 1 (calling endpoint) sends a Setup (1) message to the
well-known Call Signalling Channel Transport Address of Endpoint 2. If Endpoint 2 wishes to
accept the call, it initiates the ARQ (3)/ACF (4) exchange with that Gatekeeper. If acceptable, the
Gatekeeper shall return a Call Signalling Channel Transport Address of itself in the ARJ (4) with a
cause code of routeCallToGatekeeper. Endpoint 2 replies to Endpoint 1 with a Facility (5)
message containing the Call Signalling Transport Address of its Gatekeeper. Endpoint 1 then sends
the Release Complete (6) message to Endpoint 2. Endpoint 1 sends a Setup (7) message to the
Gatekeeper's Call Signalling Channel Transport Address. The Gatekeeper sends the Setup (8)
message to Endpoint 2. Endpoint 2 initiates the ARQ (9)/ACF (10) exchange with that Gatekeeper.
Endpoint 2 then responds with the Connect (12) message which contains its H.245 Control Channel
Transport Address for use in H.245 signalling. The Gatekeeper sends the Connect (13) message to
Endpoint 1 which may contain the Endpoint 2 H.245 Control Channel Transport Address or a
Gatekeeper H.245 Control Channel Transport Address, based on whether the Gatekeeper chooses to
route the H.245 Control Channel or not.
In the scenario shown in Figure 37, both endpoints are registered to different Gatekeepers, the
calling endpoint's Gatekeeper chooses direct call signalling, and the called endpoint's Gatekeeper
chooses to route the call signalling. Endpoint 1 (calling endpoint) initiates the ARQ (1)/ACF (2)
exchange with Gatekeeper 1. Gatekeeper 1 may return the Call Signalling Channel Transport
Address of Endpoint 2 (called endpoint) in the ACF (2) if Gatekeeper 1 has a method of
communicating with Gatekeeper 2. Endpoint 1 then sends the Setup (3) message to either the
Transport Address returned by the Gatekeeper (if available) or to the well-known Call Signalling
Channel Transport Address of Endpoint 2. If Endpoint 2 wishes to accept the call, it initiates the
ARQ (5)/ACF (6) exchange with Gatekeeper 2. If acceptable, Gatekeeper 2 shall return a Call
Signalling Channel Transport Address of itself in the ARJ (6) with a cause code of
routeCallToGatekeeper. Endpoint 2 replies to Endpoint 1 with a Facility (7) message containing
the Call Signalling Transport Address of Gatekeeper 2. Endpoint 1 then sends the Release Complete
(8) message to Endpoint 2. Endpoint 1 shall send a DRQ (9) to Gatekeeper 1 which responds with
DCF (10). Endpoint 1 then initiates a new ARQ (11)/ACF (12) exchange with Gatekeeper 1.
Endpoint 1 sends a Setup (13) message to the Gatekeeper's Call Signalling Channel Transport
Address. Gatekeeper 2 sends the Setup (14) message to Endpoint 2. Endpoint 2 initiates the
ARQ (15)/ACF (16) exchange with Gatekeeper 2. Endpoint 2 then responds with the Connect (18)
message which contains its H.245 Control Channel Transport Address for use in H.245 signalling.
Gatekeeper 2 sends the Connect (19) message to Endpoint 1 which may contain the Endpoint 2
H.245 Control Channel Transport Address or a Gatekeeper 2 H.245 Control Channel Transport
Address, based on whether the Gatekeeper chooses to route the H.245 Control Channel or not.
In the scenario shown in Figure 38, both endpoints are registered to different Gatekeepers, the
calling endpoint's Gatekeeper chooses to route the call signalling, and the called endpoint's
Gatekeeper chooses direct call signalling. Endpoint 1 (calling endpoint) initiates the
ARQ (1)/ACF (2) exchange with Gatekeeper 1. Gatekeeper 1 shall return a Call Signalling Channel
Transport Address of itself in the ACF (2). Endpoint 1 then sends the Setup (3) message using that
Transport Address. Gatekeeper 1 then sends the Setup (4) message containing its Call Signalling
Channel Transport Address to the well-known Call Signalling Channel Transport Address of
Endpoint 2. If Endpoint 2 wishes to accept the call, it initiates the ARQ (6)/ACF (7) exchange with
Gatekeeper 2. It is possible that an ARJ (7) is received by Endpoint 2, in which case it sends
Release Complete to Endpoint 1. Endpoint 2 responds to Gatekeeper 1 with the Connect (9)
message which contains its H.245 Control Channel Transport Address for use in H.245 signalling.
Gatekeeper 1 sends the Connect (10) message to Endpoint 1 which may contain the Endpoint 2
H.245 Control Channel Transport Address or a Gatekeeper 1 H.245 Control Channel Transport
Address, based on whether the Gatekeeper chooses to route the H.245 Control Channel or not.
In the scenario shown in Figure 39, both endpoints are registered to different Gatekeepers, and both
Gatekeepers choose to route the call signalling. Endpoint 1 (calling endpoint) initiates the
ARQ (1)/ACF (2) exchange with Gatekeeper 1. Gatekeeper 1 shall return a Call Signalling Channel
Transport Address of itself in the ACF (2). Endpoint 1 then sends the Setup (3) message using that
Transport Address. Gatekeeper 1 then sends the Setup (4) message to the well-known Call
Signalling Channel Transport Address of Endpoint 2. If Endpoint 2 wishes to accept the call, it
initiates the ARQ (6)/ACF (7) exchange with Gatekeeper 2. If acceptable, Gatekeeper 2 shall return
a Call Signalling Channel Transport Address of itself in the ARJ (7) with a cause code of
routeCallToGatekeeper. Endpoint 2 replies to Gatekeeper 1 with a Facility (8) message containing
the Call Signalling Transport Address of Gatekeeper 2. Gatekeeper 1 then sends the Release
Complete (9) message to Endpoint 2. Gatekeeper 1 sends a Setup (10) message to Gatekeeper 2's
Call Signalling Channel Transport Address. Gatekeeper 2 sends the Setup (11) message to Endpoint
2. Endpoint 2 initiates the ARQ (12)/ACF (13) exchange with Gatekeeper 2. Endpoint 2 then
responds to Gatekeeper 2 with the Connect (15) message which contains its H.245 Control Channel
Transport Address for use in H.245 signalling. Gatekeeper 2 sends the Connect (16) message to
Gatekeeper 1 which may contain the Endpoint 2 H.245 Control Channel Transport Address or a
Gatekeeper 2 H.245 Control Channel Transport Address, based on whether the Gatekeeper 2
chooses to route the H.245 Control Channel or not. Gatekeeper 1 sends the Connect (17) message to
Endpoint 1 which may contain the H.245 Control Channel Transport Address sent by Gatekeeper 2
or a Gatekeeper 1 H.245 Control Channel Transport Address, based on whether the Gatekeeper 1
chooses to route the H.245 Control Channel or not.
destinationAddress = conferenceAlias
destCallSignalAddress = MC(U) transport address
destinationInfo = conferenceAlias
callIdentifier = some value N
conferenceID = 0 (since the CID is unknown)
The Gatekeeper shall return the Call Signalling Channel Transport Address of Endpoint 2 (called
endpoint, containing the MC) in the ACF. Endpoint 1 then sends the Setup (3) message to
Endpoint 2 using that Transport Address and the following fields:
destinationAddress = conferenceAlias
destCallSignalAddress = address supplied by ACF
conferenceID = 0
conferenceGoal = join
Endpoint 1 completes the call by informing its Gatekeeper of the correct CID. Endpoint 1 sends an
IRR to the Gatekeeper with the following fields:
destinationAddress = conferenceAlias
destCallSignalAddress = MC(U) transport address
conferenceID = CID of the conference
conferenceGoal = create or invite
The calling entity shall recognize that the parallelH245Control field was not understood when
either it receives a Connect message and still has not received a response to the initial
terminalCapabilitySet message, the first H.245 message received from the called entity is not a
tunnelled terminalCapabilitySetAck message, or fastStart or fastConnectRefused is received
and no response has been received for the terminalCapabilitySet message. Figure 42 shows a
message exchange between an endpoint that sends the parallelH245Control field and a called
endpoint that does not understand the field.
H.323(06-06)_F42
If Endpoint 1 wishes to increase its transmitted bit rate on a logical channel from Endpoint 2, which
it previously flow controlled to a lower bit rate, Endpoint 1 first determines if the call bandwidth
will be exceeded. See Figure 44. If it will, Endpoint 1 shall request a bandwidth change from
Gatekeeper 1. When the call bandwidth is sufficient to support the change, Endpoint 1 sends a
flowControlCommand (3) to indicate the new upper limit on bit rate for the channel. If Endpoint 2
decides to increase the bit rate on the channel, it must first assure that its call bandwidth is not
exceeded by the change. If it is, Endpoint 2 shall request a call bandwidth change (4 and 5) with its
Gatekeeper. When the call bandwidth is sufficient to support the channel, Endpoint 2 will send the
closeLogicalChannel (6) message to close the logical channel. It then reopens the logical channel
using the openLogicalChannel (7) specifying the new bit rate. Endpoint 1 should then accept the
channel with the new bit rate, and it replies with an openLogicalChannelAck (8).
The H.245 Control Channel topology for the Gatekeeper routed call signalling model appears as:
In either case an MC must be present in the conference at the time of expansion to any number
greater than 2 endpoints. Note that in the Gatekeeper routed model, the MC may be located in the
Gatekeeper and/or one of the endpoints.
The procedures required to create a point-to-point conference and then expand the conference
through invite and join, for each call model, is covered in the following subclauses. Procedures for
the calling endpoint to discover a list of conferences that the called entity can provide are also
covered.
It should be noted that the call is ended by a failure of the entity that is providing the MC.
After a point-to-point conference has been established using procedures A1 to A4, an endpoint
(Endpoint 3) wishing to join a conference may attempt to connect with an endpoint that does not
contain the Active MC in the conference. In this case, the following procedure shall be used:
9.2 Visual telephone terminals over the ISDN (Rec. ITU-T H.320)
Interoperation with visual telephone terminals over the ISDN (Rec. ITU-T H.320) can be provided
by:
– using a H.323-H.320 Gateway.
The Gateway should consider the following issues:
– Video format conversion. (If desired, H.261 is mandatory for both terminal types.)
– Audio code conversion. (If desired, G.711 is mandatory for both terminal types.)
– Data protocol conversion.
– Bit stream conversion. (H.225.0 to/from H.221.)
9.4 Visual telephone terminals over mobile radio (Annex C/H.324, a.k.a. "H.324/M")
For further study.
9.5 Visual telephone terminals over ATM (H.321 and H.310 RAST)
Interoperation with visual telephone terminals over ATM networks (H.321 and H.310 RAST
terminals operating in H.320/H.321 interworking mode) can be provided by two methods:
1) using a H.323-H.321 Gateway;
2) using a H.323-H.320 Gateway, assuming that there exists an I.580 ISDN/ATM
Interworking Unit in the network.
The Gateway should consider the following issues:
– Video format conversion. (If desired, H.261 is mandatory for both terminal types.)
– Data protocol conversion.
– Audio code conversion. (If desired, G.711 is mandatory for both terminal types.)
– Bit stream conversion. (H.225.0 to/from H.221.)
– Control conversion. (H.245 to/from H.242.)
– Call Control Signalling conversion.
9.7 Simultaneous voice and data terminals over GSTN (Rec. ITU-T V.70)
Interoperation with Simultaneous Voice and Data Terminals over GSTN (Rec. ITU-T V.70) can be
provided by:
– using a H.323-V.70 Gateway.
The Gateway should consider the following issues:
– Audio code conversion. (G.711 to/from Annex A/G.729.)
– Data protocol conversion.
– Bit stream conversion. (H.225.0 to/from V.76/V.75.)
– Control conversion. (Both terminals use H.245.)
– Call Control Signalling conversion.
10 Optional enhancements
10.1 Encryption
Authentication and security for H.323 systems is optional; however, if it is provided, it shall be
provided in accordance with Rec. ITU-T H.235.0 and the documents it references.
ITU-T
H.323
Network network B Network
A1 GATEWAY GATEWAY A2
Signalling tunnel
H.323(06-06)_F53
In some cases, the tunnel termination may be located in a Gatekeeper, as illustrated in Figure 54.
Clause 10.4.2 describes Gatekeeper intervention in a tunnel.
ITU-T
H.323
Network network B
A1 GATEWAY GATEKEEPER
Signalling tunnel
H.323(06-06)_F54
10.5 Use of RTP payload for DTMF digits, telephony tones and telephony signals
It is possible to carry DTMF tones, fax-related tones, standard subscriber line tones,
country-specific tones and trunk events using a distinct dynamic RTP payload type in the same
RTP stream as the media. Many applications, such as IVR systems and voice systems rely on
synchronization of DTMF input.
RFC 4733 [56] describes means for transporting these tones and events over RTP. An endpoint may
indicate support for receiving these RFC 4733 tones and events by including the
receiveRTPAudioTelephonyEventCapability or the receiveRTPAudioToneCapability in the
terminal capability set. Alternatively, an endpoint may indicate support for RFC 4733 tones and
events by including the audioTelephonyEvent or the audioToneAudioCapability in the terminal
capability set. When using fast connect procedures, these capabilities can be sent using
parallelH245 procedures of 8.2.4.
Named telephone events are a logical description of DTMF tones, fax-related tones, standard
subscriber line tone, country-specific tones and trunk events. A decimal number identifies each
event. When telephone events are used, support for the following DTMF is mandatory: 0-9, #, *, A,
B, C, D. All others are optional.
Telephony tones are a description of the waveform properties. This is useful in cases where it is
necessary to accurately reproduce non-standard tones.
11 Maintenance
The following rules apply to the use of H.245 messages by H.323 endpoints:
• An endpoint shall not malfunction or otherwise be adversely affected by receiving H.245
messages that it does not recognize. An endpoint receiving an unrecognized request,
response, or command shall return "function not supported". (This is not required for
indications.)
• The following abbreviations are used in Tables A.1 to A.12:
M Mandatory.
O Optional.
F Forbidden to transmit.
• A message marked as mandatory for the receiving endpoint indicates that the endpoint shall
accept the message and take the appropriate action. A message marked as mandatory for the
transmitting endpoint indicates that the endpoint shall generate the message under the
appropriate circumstances.
B.1 Scope
This annex describes enhancements within the framework of the H.323 specification, to incorporate
layered video codecs. The described procedure is scalable for multipoint conferences.
B.2 Introduction
Layered video coding is a technique that allows the video information to be transmitted in multiple
data streams in order to achieve scalability. These may provide bandwidth scalability, temporal
scalability, SNR scalability, and/or spatial scalability. Annex O/H.263 describes the use of layered
coding within H.263. Conferences can take advantage of this feature to service connected endpoints
that have different capabilities, using one bitstream. This will allow more efficient use of network
bandwidth.
In this case, the endpoints are attached to the base layer of video and the enhancement layers up to
the total bandwidth desired. Each enhancement layer is on a separate logical channel. The endpoints
are burdened with recombination of the layers to create the video stream. The sending endpoint
must have capability for the combined bandwidth of all streams it sources. In this case, each
endpoint may have communicated a different set of capabilities. The MC will examine the
capabilities and QoS and create a layering model that is likely to provide the best use of the
endpoints capabilities and bandwidth. This layering is indicated in the
communicationModeCommand by the indication of sessionDependency in the
communicationModeTableEntry. The sessionDependency field is set by the MC to indicate
when a session is dependent on another session for meaningful decoding of its data. This
information will be translated into logicalChannelNumbers when opening a dependent logical
channel, according to the actual logical channels that are opened.
In the above case, using the MC Decision model, the MC will then offer the endpoints the logical
channels that correspond to the layers that match the endpoint's capabilities. The MC will offer
Endpoint 1 only the logical channel corresponding to the Base Video Layer. Endpoint 2 will be
offered the logical channels corresponding to base video and enhancement video Layer 1. Endpoint
three is offered three logical channels corresponding to the base video and two enhancements
layers, and Endpoint 4 is offered all video logical channels.
In the MC impartial case, the MC will offer all logical channels, to all endpoints, that are within
their dataType capabilities. The endpoints will refuse any logical channel that will cause them to
exceed their bandwidth capabilities.
A second layering model is shown in Figure B.3. In this model each logical channel contains a
totally independent video stream.
H.323 on ATM
(This annex forms an integral part of this Recommendation)
C.1 Introduction
This is an optional enhancement allowing H.323 endpoints to establish QoS-based media streams
on ATM networks using AAL 5.
C.2 Scope
This annex specifies an improved method of using H.323 on AAL 5. H.323 can always be used on
ATM by making use of an IP over ATM method. However, this is less efficient than using
AAL 5 Virtual Channels (VCs) directly for the transport of the audio and video streams of H.323.
When the media streams flow directly on AAL 5, they can benefit from a QoS-based ATM VC.
This annex retains the use of a packet network protocol for H.245 and H.225.0 communications to
ensure interoperability with H.323 endpoints that are using a packet network protocol for all
streams (whether over ATM or other media). Interoperability with legacy H.323 endpoints is
achieved, without the use of a Gateway, by first requiring the basic mode of operation, in which an
endpoint sends media streams on a datagram service using a packet network protocol, for example
UDP/IP over ATM. In basic mode, unless a packet network protocol infrastructure has been
upgraded, QoS may not be available from the network.
C.2.1 Point-to-point conferencing
This annex specifies a method of point-to-point communication between two H.323 endpoints using
AAL 5 VCs for the media streams. The protocol necessary for entering into this mode is specified,
as are information elements to be used in ATM signalling.
C.2.2 MCU-based multipoint
It follows that multipoint MCU-based communications can occur among several H.323 endpoints
using AAL 5 VCs for the media streams. Currently no support is specified for the
H.323 Decentralized Multipoint using ATM point-to-multipoint capability. This is left for further
study.
C.2.3 H.323 interoperability with endpoints using IP
Interoperability is guaranteed with an endpoint using IP for the entire H.323 connection. This annex
defines methods that allow an endpoint to detect if support is present for the option of using
AAL 5 directly. An endpoint conforming to this annex must accept that the audio and video streams
may occur on either AAL 5 VCs or UDP/IP ports.
C.3 Architecture
The basic protocol architecture of the system is shown in Figure C.1. It uses IP on ATM for
delivery of the H.225.0 and H.245 messages and for the RTCP part of the audio and video streams.
It uses AAL 5 directly for the RTP part of the audio and video streams.
NOTE – The H.323 media streams, compressed into variable length packets according to
Rec. ITU-T H.225.0, are easily mapped to AAL 5. It would be difficult to map them to AAL 1, and this
alternative has no clear benefit.
IP
Table C.2 – Association of ATCs with QoS classes (from Table 3/I.356)
ATM Transfer DBR, SBR1, DBR, SBR1, SBR2, SBR3,
Any ATC
Capabilities (ATC) ABT/DT, ABT/IT ABT/DT, ABT/IT ABR
Applicable QoS class Class 1 Class 2 Class 3 U class
(stringent) (tolerant) (bi-level)
ABR: Available Bit Rate; ABT/DT: ATM Block Transfer/Delayed Transmission; ABT/IT: ATM Block
Transfer/Immediate Transmission; DBR: Deterministic Bit Rate; SBR1: Statistical Bit Rate
configuration 1; SBR2: Statistical Bit Rate configuration 2; SBR3: Statistical Bit Rate configuration 3.
H.323 version 3 (or later) endpoints shall set the IE action indicator of the GIT information element
to "clear call", according to 4.5.1/Q.2931. In this case, if the terminating endpoint does not support
GIT information element coding it will reject the call with the cause value 100 for Invalid
information element content according to 5.7.2/Q.2931. If the ATM VC setup attempt is rejected
because the terminating endpoint does not understand GIT it will reject the VC call setup with cause
number 99 Information element non-existent or not implemented, according to 5.7.2/Q.2931.
It should be noted that the portNumber field in H.245 is only 16 bits in length.
The B-HLI is only used for backward compatibility with H.323 version 2 endpoints, as described
in C.3.7.2.
D.1 Introduction
Currently, facsimile and speech are typically sent using the PSTN with the same calling and
addressing infrastructure. It is highly desirable to continue this approach in the context of this
Recommendation. From a high level, facsimile can be viewed as another kind of real-time traffic
similar to a particular speech coder. This seems appropriate, as facsimile entering the packet world
via a gateway from the PSTN should logically be treated in a fashion similar to speech if the
customer expects a real-time, assured end-to-end transmission service. The conversion of facsimile
to email or other store-and-forward methods represents a new service that is beyond the scope of
this Recommendation, which is a real-time protocol. It is recognized that manufacturers may wish
to provide a gateway that falls back to a store-and-forward service when the real-time facsimile call
fails. It is beyond the scope of this Recommendation when and how this decision is made, or by
what means a store-and-forward facsimile service is implemented.
Rec. ITU-T T.38 [55] defines an Internet facsimile protocol consisting of messages and data
exchanged between Facsimile Gateways connected via an IP network. This annex uses
Rec. ITU-T T.38. Communication between the Gateways and G3/G4 Facsimile terminals is beyond
the scope of Rec. ITU-T T.38. The reference model for T.38 is shown in Figure D.1 with three
scenarios. In the first scenario, the two traditional Group 3 Facsimile Equipment (G3FE) terminals
are virtually connected through the Gateways once the PSTN calls are established. All T.30 [54]
session establishment and capabilities negotiation is carried out between the terminals. In the
second scenario, the traditional Group 3 Facsimile (IAF) terminal is connected with an Internet
Aware Fax terminal (IAF).
The IAF is directly connected to the IP network. In the third scenario, the two IAFs are directly
connected to the IP network. In all the scenarios, T.38 packets are used on the IP network to
communicate T.4/T.30 facsimile information. The transport of T.38 packets is either on TCP/IP,
UDP/IP (facsimile UDP transport layer, UDPTL), or RTP using the H.323 mechanism.
D.2 Scope
The scope of this annex is to use H.323 procedures to transfer T.38 packets in real time over the
IP network. H.323 entities supporting facsimile capabilities shall use T.38 to support real-time
facsimile services as described in this annex.
H.323 facsimile capable endpoints shall support the usage of TCP and UDPTL as described in
Rec. ITU-T T.38 and may optionally support RTP. Annex B/T.38 describes a T.38-only capable
terminal that supports a subset of H.245 messages using H.245 tunnelling. However, the
T.38/Annex B terminal can interwork with an H.323/Annex D terminal using 8.1.7, "Fast Connect
Procedure", and 8.2.1, "Encapsulation of H.245 Messages within H.225.0 call signalling Messages"
procedures in this Recommendation. T.38/Annex B terminals interwork with H.323 terminals
without being conformant to this Recommendation. An H.323 terminal that supports the procedures
of this annex shall interwork with T.38/Annex B terminals.
In the above example, T.38 channels are proposed as UDPTL or TCP. To propose a unidirectional
logical channel that utilizes RTP for transport of T.38 packets, the Open Logical Channel's
dataType parameter shall be set to audioData and shall include the H.245 Generic Audio
Capability for T.38 as specified in Annex G/T.38.
In the above example, T.38 channels are proposed as UDPTL or TCP. To propose a unidirectional
logical channel that utilizes RTP for transport of T.38 packets, the Open Logical Channel's
dataType parameter shall be set to audioData and shall include the H.245 Generic Audio
Capability for T.38 as specified in Annex G/T.38.
Figure D.9 illustrates a successful switchover from voice to fax using H.245 tunnelling for two
unidirectional media channels.
When using a bidirectional fax channel (for TCP only), the request mode command is not
necessary: the endpoint that detected the tone shall close its open channels, request the reverse
channels to be closed by the other endpoint, and open a bidirectional T.38 channel. Upon reception
of the request channel close command, the remote end shall close its audio channel. After
acknowledgements have been received for each of the T.38 open logical channels, fax transmission
and reception takes place.
Figure D.10 illustrates a successful switchover from voice to fax when a separate H.245 channel is
already open for one bidirectional media channel.
Figure D.11 illustrates a successful switchover from voice to fax using H.245 tunnelling for one
bidirectional media channel.
Should either endpoint wish to return to an audio call after the fax transmission has ended, the
Mode Request procedure shall be initiated using an audio codec as a parameter. The above
procedure also applies to traditional H.245 logical channel signalling cases, in the event that Fast
Connect cannot be established between the two endpoints.
E.1 Scope
This annex describes a packetization format and a set of procedures (some of which are optional)
that can be used to implement UDP and TCP-based protocols. The first part of this annex describes
the signalling framework and wire-protocol, and subsequent clauses detail specific use cases. The
only profile currently specified in this revision is for transporting H.225.0 call signalling messages.
This annex is designed to operate in engineered networks and use the security services provided by
H.323 (e.g., H.235.0, IPSec). This annex should not be used over the public Internet, due to security
and traffic considerations.
E.1.1 Introduction
E.1.1.1 Multiplexed transport
This annex provides a multiplexed transport layer that can be used to transmit multiple protocols
(with optional reliability) in the same PDU. Often-used protocols have specific code points (also
called "payload types"). Other protocols can be carried and identified using the OBJECT
IDENTIFIER typed payloads.
E.1.1.2 Multiple payloads in a single PDU
Annex E PDUs can contain multiple "payloads", each a different protocol and targeted at a different
session (the definition of a "session" is protocol dependent). Note that there is no implicit relation
between payloads when they arrive in the same PDU.
E.1.1.3 Flexible header options
Annex E PDU and Payload headers are configurable. Minimum header size can be as small as
8 octets, and may grow up to 20 octets when all optional fields are present.
E.1.1.4 Ack message
Messages carried using UDP can get lost. If the application needs assurance that a sent message
arrived successfully, it may request an Ack message for the PDU.
A sender shall specify in the ackRequested field whether it wants to receive an Ack message for a
PDU being sent, and the receiver shall reply with an Ack Payload if the ackRequested field is set.
NOTE – Ack messages shall be sent by the Annex E transport layer, not by the application using the
Annex E stack. The specific Ack behaviour is mandated by the signalling model the Annex E stack is
instructed to use by the application.
E.1.1.5 Nack message
A Nack message shall be used to signify some error condition. Such errors may be the inability to
support a specific payload type, the arrival of a malformed PDU, and others. These messages may
or may not have the effect of dropping an ongoing call.
NOTE – Nack messages are to be sent by the Annex E transport layer, not by the application using the
Annex E stack.
When there is a known round-trip message interval value from a previous transmission, timer T-R1
should be set to that round-trip message interval value +10%.
E.1.1.9 Connection keep-alive
When running over TCP, the presence of a persistent TCP connection can ensure that one side is
aware of the remote side failures (by observing TCP failures). When running over UDP, there is no
such "state" associated, and another procedure must be used.
I-Am-Alive timers
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
VERSION 6 M H L A SEQNUM
PAYLOAD(s) 0, ..., N–1
0
0 1 2 3 4 5 6 7
T S A R
Value Interpretation
0 I-Am-Alive message
1 Ack message
2 Nack message
3 Restart Message
4..255 Reserved for future use
0 1 2 3
0 1 2 3 4 5 6 7 0
1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
T S A R TRANSPORT MESSAGE = 0 VALIDITY
COOKIE LENGTH P COOKIE OCTET 0 COOKIE OCTET N–1
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
T S A R TRANSPORT MESSAGE = 1 ACK COUNT
SEQNUM 0 RESERVED
SEQNUM N–1 RESERVED
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
PAYLOAD TYPE RESERVED ALTERNATE PORT
ALTERNATE IP ADDRESS
0 1 2 3
0 1 2 3 4 5 6 7 0
1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
OBJECT IDENTIFIER OBJECT IDENTIFIER OBJECT IDENTIFIER OBJECT IDENTIFIER
LENGTH OCTET 0 OCTET 1 OCTET N–1
ALTERNATE IP ADDRESS
ALTERNATE PORT
If the IP address is set to zero, the IP address of the sender shall be used (as identified by the
TCP/IP layer). If the UDP port is set to zero, the port transmitted from shall be used (as identified
by the TCP/IP layer).
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
T = 00 S A RESERVED TRANSPORT MESSAGE = 4 RESERVED
Value Interpretation
0 Octet-stream contains a call signalling message as defined in Rec. ITU-T H.225.0
1..255 Reserved for future use
0 1 2 3
0 1 2 3 4 5 6 7 0 1 23 4 5 6 7 0 1 2 3 4
5 6 7 0 1 2 3 4 5 6 7
T S A R TYPE PAYLOAD LENGTH
PAYLOAD OCTET 0 PAYLOAD OCTET 1 PAYLOAD OCTET 2 PAYLOAD OCTET N–1
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 75 6
0 1 2 3 4 5 6 7
T S A
R TYPE SESSION
PAYLOAD LENGTH PAYLOAD OCTET 0 PAYLOAD OCTET 1
PAYLOAD OCTET 2 PAYLOAD OCTET 3 PAYLOAD OCTET 4 PAYLOAD OCTET N–1
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2
3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
T S A R TYPE SESSION
SOURCE/DESTINATION ADDRESS
PAYLOAD LENGTH PAYLOAD OCTET 0 PAYLOAD OCTET 1
PAYLOAD OCTET 2 PAYLOAD OCTET 3 PAYLOAD OCTET 4 PAYLOAD OCTET N–1
0 1 2 3
0 1 2 3 4 5 6 7 0 1 23 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
T S A R TYPE PAYLOAD LENGTH
SOURCE/DESTINATION ADDRESS
PAYLOAD OCTET 0 PAYLOAD OCTET 1 PAYLOAD OCTET 2 PAYLOAD OCTET N–1
0 1 2 3
0 1 2 3 4 5 6 7 0
1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
T S N R OBJECT IDENTIFIER OBJECT IDENTIFIER OBJECT IDENTIFIER
LENGTH OCTET 0 OCTET N–1
PAYLOAD LENGTH PAYLOAD OCTET 0 PAYLOAD OCTET N–1
0 1 2 3
0 1 2 3 4 5 6 7 0
1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
T S N
R OBJECT IDENTIFIER OBJECT IDENTIFIER OBJECT IDENTIFIER
LENGTH OCTET 0 OCTET N–1
SESSION PAYLOAD LENGTH
PAYLOAD OCTET 0 PAYLOAD OCTET 1 PAYLOAD OCTET 2 PAYLOAD OCTET N–1
0 1 2 3
0 1 2 3 4 5 6 7 0
1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
T S N R OBJECT IDENTIFIER OBJECT IDENTIFIER OBJECT IDENTIFIER
LENGTH OCTET 0 OCTET N–1
SOURCE/DESTINATION ADDRESS
PAYLOAD LENGTH PAYLOAD OCTET 0 PAYLOAD OCTET N–1
PAYLOAD OCTET 2 PAYLOAD OCTET 3 PAYLOAD OCTET 4 PAYLOAD OCTET N–1
The Annex E layers should retransmit a lost packet if it does not get a reply after some time. The
precise retransmission procedure is detailed in E.1.1.8.
E.2.2.2 Mixed TCP and UDP procedure
The procedures for TCP-based and UDP-based call setup are not mutually exclusive. If UDP-based
and TCP-based call setup are carried out in parallel, then the procedure in this clause shall be used.
In the mixed procedure, the originator transmits the SETUP message over UDP, and simultaneously
establishes a TCP connection. If the originator has not received a response to the UDP SETUP
when the TCP connection is established, then it also transmits the SETUP messages over the
TCP connection. If a callee receives the same SETUP message over UDP and over TCP, then it
shall respond using either transport protocol (usually the one which arrived first) but not both.
If the originator receives a response over UDP then the TCP connection shall be released and
communication continues over UDP. If the originator receives a response over TCP (for example
because the remote peer does not support the Annex E procedures), then communication continues
over TCP, UDP-based communication shall no longer be used for this call.
A callee that supports this annex shall select the transport protocol according to which arrives first:
TCP Setup message, or UDP Setup message. Note these messages may be reordered in delivery.
This ensures that if the UDP procedure fails, usual TCP-based procedures can take over
immediately (see Figure E.25):
This means that backwards compatibility when calling Rec. ITU-T H.323 version 1 (1996) or 2
(1998) entities is transparent, as the v1/v2 H.323 application will not be aware of the UDP packet.
NOTE – It is recommended for entities that initiate a call and do not know if the remote side supports
Annex E operations to use the procedure detailed above. If the calling entity knows by some means that the
remote callee supports UDP-based operations, it may use a UDP-only call setup.
E.2.3 Specifics
E.2.3.1 Message identification
H.225.0 over Annex E payloads shall use static payload type 0 (zero).
E.2.3.2 Well-known port
UDP port 2517 shall be used for the well-known port. Entities may transmit from any random port.
A single H.323 entity on a physical device shall use a single, distinct UDP port as the advertised
port for receiving messages. However, it may utilize a distinct port on each interface if the physical
device has multiple network interfaces.
F.1 Introduction
Simple Endpoint Types, i.e., devices manufactured for a single purpose, may comprise a significant
fraction of the overall set of H.323-capable end systems. In contrast to full-featured H.323 devices
(many implementations of which are PC-based), the so-called Simple Endpoint Types (SETs) may
be implemented in inexpensive stand-alone boxes, the most prominent example being the simple
telephone.
NOTE – Sample application scenarios for such systems were found to include:
1) palmtop computer with audio communications capabilities (voice, file transfer, fax, etc.);
2) telephone with an RJ-45 connector;
3) text telephones (using Rec. ITU-T T.140);
4) cellular IP phone;
5) mobile system with integrated voice and data communications (UMTS, IMT-2000).
All these systems have in common that they support a relatively fixed set of functionality: voice
and/or rudimentary (i.e., not T.120) data communication facilities. It is important to note that this
functionality does not need to be extended for the respective system's purpose: a telephone set
without (an elaborate) display does not need to support video functionality, neither does it require
data conferencing capabilities.
All of these systems have a limited amount of resources available (e.g., processing power,
communication bandwidth, memory).
This annex outlines the scope of SET devices in general and defines the procedural and protocol
details of a Simple Audio Endpoint Type (Audio SET device). In particular, this annex defines the
functional baseline for all types of Simple Endpoint Types; hence, further SETs are to be defined by
referencing this annex and then only specifying additions to the procedures and conventions set
forth in this annex.
This annex defines a subset of H.323 functionality and any deviations from this Recommendation
are explicitly identified. Any procedures not explicitly described in this annex are covered by the
main body of this Recommendation.
The development of SET devices has potential implications on other H.323 devices: in particular,
MC(U)s and gateways should be aware of their potentially minimal support for H.323 (1998)
functionality in order to provide SET devices with seamless access to enhanced H.323 services such
as multipoint conferences and supplementary services. Alternatively, external proxy devices may be
provided to bridge the different functional ranges between SET devices and full-featured
H.323 (1998) endpoints. Interoperability issues are addressed in more detail in F.9.
F.3 Scope
This annex specifies rules on the use of this Recommendation that enable Simple Endpoint Types to
be implemented in a simple fashion. The following (non-exhaustive) list of Simple Endpoint Types
is envisioned for standardization by the ITU-T:
1) simple telephone (Simple Audio Endpoint Type) – defined in this annex;
2) simple telephone with security capabilities – for further study;
3) text conversation terminal – for further study;
4) fax device – for further study.
The simple telephone is defined in this annex. Secure simple telephone, text terminal, and simple
fax device are Simple Endpoint Types for further study. The profiles for Simple Endpoint Types
can be categorized as follows:
Complete scope
of ITU-T H.323
Secure
simple
phone
H.323(06-06)_FF.1
Figure F.1 is a schematic picture of the different Simple Endpoint Types that are being defined in
the context of H.323 'profiles', in a so-called Venn diagram. In this diagram, the relation between
the SETs is illustrated. The wider ellipse shows the context of a full H.323 compliant system. As an
example, the simple telephone is put in the figure. As it is clearly a subset of the full compliant
H.323 system, it lies completely within its scope. A secure simple telephone, containing
additionally the security capabilities, comprises the capabilities of the simple telephone (e.g., same
audio codecs, same call setup, etc.). The interoperability between a simple telephone SET
implementation and a secure simple telephone will therefore be ensured.
The SET devices are defined in a way that enables them to interoperate seamlessly with one another
and with H.323 (1998) devices supporting the FastConnect procedure as well as with all SET-aware
H.323 endpoints.
F.5 Abbreviations
This annex uses the following abbreviations:
Audio SET Simple Audio Endpoint Type
Fax SET Simple Facsimile Endpoint Type
Secure Audio SET Secure Simple Audio Endpoint Type
SET Simple Endpoint Type
Text SET Simple Text Telephony Endpoint Type
maximumAudioDelayJitter ≥ 250 ms
receiveMultipointCapability,
transmitMultipointCapability, and
receiveAndTransmitMultipointCapability
multicastCapability TRUE/FALSE as appropriate,
default FALSE1
multiUnicastConference TRUE/FALSE as appropriate,
default FALSE1
mediaDistributionCapability
centralizedControl TRUE
distributedControl FALSE
centralizedAudio TRUE
distributedAudio TRUE/FALSE as appropriate,
default FALSE1
centralizedVideo FALSE
distributedVideo FALSE
centralizedData ABSENT
distributedData ABSENT
mcCapability
centralizedConferenceMC FALSE
decentralizedConferenceMC FALSE
rtcpVideoControlCapability ABSENT
mediaPacketizationCapability ABSENT
...,
transportCapability ABSENT
redundancyEncodingCapability Audio redundancy encoding only
(if any)
logicalChannelSwitchingCapability FALSE
t120DynamicPortCapability FALSE
Capabilities signalled from the remote side that are not understood shall be ignored.
F.7.3.4 Logical Channel Signalling Messages
The opening of logical channels shall adhere to the FastConnect specifications of Rec. ITU-T H.323
(1998).
In addition, SET devices shall support reconfiguration of media streams at any time during a call.
Open Logical Channel structures shall be tunnelled in H.225.0 call signalling messages following
the procedures defined in Recs ITU-T H.225.0 (1998) and H.323 (1998) reusing the fastStart
____________________
1 Multicast, multi-unicast, and distributed audio may be supported by Conference-aware Audio SET
devices.
reverseLogicalChannelParameters
dataType a valid audio data type
(see F.7.3.3.1)
multiplexParameters CHOICE:
h2250LogicalChannelParameters
reverseLogicalChannelDependency LogicalChannelNumber OPTIONAL,
replacementFor used if another Logical Channel
is to be replaced
separateStack ABSENT
encryptionSync ABSENT for Audio SET devices;
FFS.
transportCapability
nonStandard should be ABSENT
Logical Channel Number: This field contains the number of the H.245 logical channel – 1.
X bit: Used to distinguish between basic and extended audio types. If X = 0, AuType
(see next field) applies; otherwise (X = 1), the extended audio types described below
apply (primarily GSM) along with a different packet structure.
AuType: Identifies the audio codec to be used. The following values are acceptable for AuType.
The leftmost bit is placed in bit 1 of octet #3 above, the rightmost in bit 5 of octet #4.
The meaning of the fields is identical to the meaning defined for the above format. In addition, the
following fields are relevant:
S bit: Indicates support for silence suppression if S = 1.
F.10.1.1.3 GSM
For GSM, identified by bit #1 of octet #3 set to X = 1, the structure looks as follows:
The fields have the same meaning as in the above packet formats. In addition, the following fields
are defined for GSM:
Ext. Audio Type: Identifies the extended audio codec:
GSM Full Rate = 000 0011
GSM Half Rate = 000 0100
GSM Enhance Full Rate = 000 0101
C bit: C = 1 indicates support/use of comfort noise
S bit: S = 1 indicates support/use of scrambling
F.10.1.2 Reverse Logical Channel Parameters
Open Logical Channel Message containing ReverseLogicalChannel parameters are encoded as
described in this subclause.
The fields have the same meaning as above. In addition, the following fields are defined:
RTP IP address/port: Target transport address for the RTP audio stream to be sent to.
RTCP IP address/port: Target transport address for RTCP sender reports to be sent to.
F.10.1.2.2 Rec. ITU-T G.723.1
For Rec. ITU-T G.723.1, the structure differs slightly from the above as follows:
F.10.1.2.3 GSM
For GSM, identified by bit #1 of octet #7 set to X = 1, the structure looks as follows:
Ext. Au Type: Identifies the extended (GSM) audio codec to be used as follows:
GSM Full Rate = 000 0011
GSM Half Rate = 000 0100
GSM Enhance Full Rate = 000 0101
G.1 Introduction
Standardized, character-oriented text conversation facilities are needed in all networks. When
building text conversation facilities on multimedia protocols, an opportunity is created to use any
combination of text, video and voice in a conversation. The initiative to standardize this
combination comes from the needs of people with communication-related disabilities. The
availability of the three media in a conversation offers communication opportunities over any one of
the media alone. Anyone may find a commonly available, standardized text conversation addition to
multimedia conversation services valuable, enhancing videotelephony to "Total Conversation".
Since H.323 is a framework, where components can be included when required, single function text
terminals as well as text and voice terminals can be useful subsets of the full Total Conversation
terminal. These subsets correspond to text telephones available for the PSTN.
Rec. ITU-T T.140 [G1] specifies a text conversation protocol. It is a common presentation level
suitable for straightforward real-time text conversation in multimedia services and in text telephony.
It is based on the ISO/IEC 10646 character code so as to be suitable to any language. It is
introduced throughout the H-series multimedia protocols.
This specification describes how text conversation facilities are added to the H.323 multimedia
environment in packet networks.
The text conversation facility is established in a data channel or an audio channel (collectively
referred to as "media channels") identified by the H.245 OpenLogicalChannel message. Within a
data channel, the same identification is used for opening text conversation channels in H.324. Only
the protocol and procedures of the data channel to carry T.140 data differ. Interworking between
H.324 systems and H.323 systems assume that devices will utilize a data channel for transporting
text. As such, support for the data channel to transport text is recommended for all H.323 devices
implementing this annex.
Thereby, Total Conversation gets a uniform implementation across different networks. The
complexity of gateways and other network components can be kept low.
G.2 Scope
The scope of this annex is to specify H.323 procedures to establish and carry text conversation
sessions in real-time over packet networks in the H.323 multimedia environment. It also specifies
rules on the use of H.323 that enable Text Conversation Simple Endpoint Type Devices (Text SET)
to be created as supersets of the Audio Simple Endpoint type devices specified in Annex F. The
Text SET specification describes a device that can be used for real-time conversations in voice and
text simultaneously over packet networks.
G.4 Definitions
This annex defines the following terms:
G.4.1 total conversation: Conversational services offering real-time communication in video,
text and voice.
G.4.2 T140PDU: Protocol Data Unit from T.140 = a collection of data submitted in T.140 format
for transmission.
The T140Audio and T140Data capabilities use the same capability identifier value and are
distinguished by their capability class.
G.5.3 Characters per Second Generic Parameter
When using either the generic audio capability or the generic data capability to signal text, an
endpoint may also advertise, either in the terminal capability set, the Open Logical Channel, or
both, the capability to receive a specified number of characters per second. This parameter is
defined in [G2] and [G3] and is signalled as follows:
or
DataApplicationCapability.application = genericDataCapability
(The generic data capability shall be specifed according to G.5.1)
or
AudioCapability = genericAudioCapability
(The generic audio capability shall be specifed according to G.5.2)
• In the Open Logical Channel procedure, specify:
OpenLogicalChannel.forwardLogicalChannelParameters = dataType
DataType = data
And select a reliable or unreliable channel for the transfer of T.140 data by specifying the
DataApplicationCapability and the DataProtocolCapability as above.
or
OpenLogicalChannel.forwardLogicalChannelParameters = dataType
DataType = audioData
The selection of the dataType, whether it is audioData or data, is dependent on the supported and
preferred capabilities.
The Fast Connect procedures or the normal H.245 logical channel signalling procedures may be
used.
The destination node and originating node concepts of Rec. ITU-T T.140 are mapped to the two
H.323 endpoints.
The T.140 user identity is an alias for the far H.323 endpoint.
ITU-T T.140 ITU-T T.140 Voice ITU-T T.140 Voice ITU-T T.140 Voice ITU-T T.140
and and and
video video video
ITU-T ITU-T
Compatibility Trans- AL1 ITU-T ITU-T H.224 TCP ITU-T
T.124
equalizers pareny H.245 client 2 H.245 T.134 GCC
ITU-T H.223 ITU-T H.221 ITU-T H.225.0
ITU-T V.18 ITU-T T.123
Network Network
ITU-T V.34/V.80
access access
PSTN PSTN ISDN IP network Any
network
Gateway functions, with transparent transmission of ITU-T T.140 data between the different ITU-T T.140 data channel types.
H.323(06-06)_FG.1
Anne Eve
Hi, this is Anne.
Oh, hello Anne, I am glad you are calling!
Have you heard that I will come to Paris in November?
No, that was new to me. What brings you here?
Anne Eve
Hi, this is Anne. Have you heard that I will come to Paris Oh, hello guys! How are you Steve?
in November?
Steve Bill
Hi there! This is Steve, I'm fine. Hello Anne! I am happy that you are on the big Internet!
The display of a many-to-many conference can also be ordered in one window with labels for each
participant's entries (IRC style) (see Figure G.4):
We are proud to announce today a new superior system for intergalactic travel
J.1 Introduction
This annex describes security for Annex F simple endpoint types. The specified security profile is
based upon Rec. ITU-T H.235.0 [22] and other H.235.x sub-series and uses the featured profiles.
The shown security profiles in Annex J adopt Recs ITU-T H.235.1 and H.235.6 for the purpose of
simple endpoint types and their specific security requirements. The security profile selects
appropriate security features from H.235.x sub-series with its rich set of options.
The described text provides an overview on the security profile; Recs ITU-T H.235.1 and H.235.6
provide all the technical and implementation details.
Basically, a security simple endpoint type (security SET) is a SET as defined by Annex F that
implements additionally certain security features of this annex.
Currently, this annex focuses only on a "secure audio SET (SASET)" and leaves any other security
simple endpoint types (e.g., secure FAX SET, secure text terminal, secure Video SET, etc.) for
further study.
J.3 Scope
This annex describes security for simple endpoint types. As shown in F.3, this currently includes:
• Secure simple telephone terminal (Secure Audio Simple Endpoint Type) – Defined in this
annex (see J.6).
Any other security SETs are for further study.
J.4 Abbreviations
This annex uses the following abbreviations:
AES Advanced Encryption Standard
DES Data Encryption Standard
GK Gatekeeper
HMAC Hashed Message Authentication Code
** Integrated
H.235 session
* key
H.245 * Password Password management
(Note) HMAC-SHA1-96 HMAC- (Authenticated
SHA1-96 Diffie-Hellman
key exchange,
key update)
56-bit DES
56-bit RC2
compatible
168 bit triple
RTP DES
128 bit AES
192 bit AES
256 bit AES
* Blue area: Password-based scheme.
** Green area: Voice encryption security profile.
NOTE − Embedded ITU-T H.245 inside ITU-T H.225.0 fast connect.
For authentication and integrity, the user shall use a password-based scheme (blue area in
Table J.1). The password-based scheme is highly recommended for authentication due to its
simplicity and ease of implementation. Hashing the fields in the H.225.0 messages is the
recommended approach for integrity of the messages (also using the password scheme). SASETs
realize authentication in conjunction with integrity using the same common security mechanism.
SASETs when deploying the voice encryption security profile (green area in Table J.1) shall
implement 56-bit DES as the default encryption algorithm; SASETs may implement 168-bit
Triple-DES while SASETs implementing exportable encryption may implement 56-bit
RC2-compatible.
For voice confidentiality, the suggested scheme is encryption using RC2-compatible, DES, Triple-
DES or AES based on the business model and exportability requirement. Some environments that
are offering already a certain degree of confidentiality may not require voice encryption. In this
case, Diffie-Hellman key agreement and other key management procedures are not necessary as
well.
Access control means are not explicitly described; they can be implemented locally upon the
received information conveyed within H.235 signalling fields (ClearToken, CryptoToken).
K.1 Introduction
This annex describes an optional way of controlling supplementary services in an
H.323 environment. By opening a separate connection conveying a service-independent control
protocol, new services may be developed and deployed without updates to the H.323 endpoints.
This service control channel is intended to be used for a wide range of services, some which require
the use of H.450 or proxy signalling (e.g., as in Appendix III) for invocation/execution. As this
channel is service-independent, no specific services are defined or advocated. The data exchanged
on this channel are meant to be informative (user interface) and should be followed by appropriate
actions (e.g., H.450 invocations) in the call signalling plane when needed. Although some
serverside applications need to support H.450 services for interworking, this annex is totally
independent of the H.450.x Recommendations.
The service control channel may be utilized for both call-related and non-call-related services. It
may be opened between the terminal and the network, or between two endpoints (in a call or with a
call independent connection).
While several protocols might be used, this annex describes the use of the hypertext transfer
protocol (HTTP) for this purpose. HTTP is open, flexible, firewall friendly and well known. Any
device claiming to support Annex K shall support HTTP as a transport for service control,
optionally also S-HTTP for applications requiring security. The actual service application protocol
is dynamic, and is indicated using MIME types in the HTTP signalling. Example applications may
include XML pages possibly including Java and scripts, download of tones and announcements to
be played to the client, upload of Call Processing scripts from client to a gatekeeper, etc. While this
annex focuses on user-directed supplementary services, this service control channel could also be
used for other means. It could, for example, be used for software upgrades or for pushing
commercials to the clients.
Clause K.2 describes the use of H.323 for providing the HTTP connection's URL between the
service provider and the client, clause K.3 shows the use of HTTP, and clause K.4 shows some
examples of possible services and the corresponding signalling.
The interface between the service control plane and the call control plane on the client or the service
provider is not within the scope of this annex, but could include HTML or XML tags such as mailto
or H.323 URLs. See Figure K.1.
Client entity Service provider
Service HTTP
control plane Web-browser HTTP server
H.323(06-06)_FK.1
HTTP and RAS messages are capitalized (HTTP:GET, RAS:ARQ), while H.225.0 call signalling
messages are written with the first letters capitalized (Setup). ASN.1 codepoints in H.225.0 are
written in bold (ServiceControlAddress).
____________________
2 The term "HTTP user agent" used within this annex refers to a process that implements the client part of
the HTTP protocol (normally represented with a web-browser).
1) The client sends a Setup that is routed via the gatekeeper to the endpoint representing the
called party.
2) The called party may be in a state where specific call processing is programmed, e.g.:
– Decide to reject the call by sending a Release Complete. The Release Complete could
contain a URL to be displayed by an HTTP user-agent on the calling party. The URL
could, for example, be a reference to the home page of the called party.
RRQ
RCF (url)
Load (url)
GET (url)
200 OK (Data)
Display
Update the
phone book
with user B Action
GET (url)
Write the
phone book
Display 200 OK (data)
Click-to-call
w/phone book
with user C Action (callto) Callto:xxx
ARQ (xxx)
H.323(06-06)_FK.4
K.5 References
The following ITU-T Recommendations and other references contain provisions which, through
reference in this text, constitute provisions of this Recommendation. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision;
users of this Recommendation are therefore encouraged to investigate the possibility of applying the
most recent edition of the Recommendations and other references listed below. A list of the
currently valid ITU-T Recommendations is regularly published. The reference to a document within
this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
K.5.1 Normative references
[URL] IETF RFC 3986 (2005), Uniform Resource Identifier (URI): Generic Syntax.
[HTTP] IETF RFC 2616 (1999), Hypertext Transfer Protocol – HTTP/1.1.
K.5.2 Informative references
[S-HTTP] IETF RFC 2660 (1999), The Secure HyperText Transfer Protocol.
[HTML] IETF RFC 2854 (2000), The 'text/html' Media Type.
[MIME] IETF RFC 2045 (1996), Multipurpose Internet Mail Extensions (MIME) Part One:
Format of Internet Message Bodies.
L.1 Scope
This annex describes stimulus signalling procedures between H.323 terminals and a Feature Server
functional entity. This stimulus method allows the network service provider to implement new
supplementary services for the terminals without changes in the terminal software, which results in
easier maintenance. An example of such terminals is a LAN attached feature phone. A Feature
Server may be colocated with the Gatekeeper.
The H.323 stimulus protocol allows services to be provided by one or more Feature Servers. For
interoperability, standard H.225.0 signalling is used for basic call control, and all manipulations of
media streams are done using standard H.245 or Fast Connect procedures. Mechanisms based on
Rec. ITU-T H.248.1 are used to manipulate physical terminations such as speaker or handset.
The protocol described by this annex can support both the direct signalling model and the
Gatekeeper routed model.
The typical configurations illustrated by Figures L.1 and L.2 show functional signalling entities that
may be involved in a call from an H.323 stimulus terminal to another endpoint in a different H.323
zone. Figure L.1 shows the Feature Server acting as a signalling proxy for the Annex L terminal.
Figure L.2 shows the Feature Server co-located with the Annex L terminal's Gatekeeper. In both
cases, the Feature Server has access to the H.323 signalling, which provides it with call state
information which may be useful for particular services, as well as enabling the Feature Server to
affect media streams using H.245 or Fast Connect signalling.
IP network
Feature server
ITU-T H.225.0
Call Sgn./H.450
ITU-T H.323 Stimulus ITU-T
stimulus server
ITU-T H.323 H.450
terminal FE ITU-T H.245
stimulus IW
Stimulus
client ITU-T H.245 To other
FE ITU-T H.323
endpoints/zones
ITU-T H.323
basic
call
IP payload
H.323(06-06)_FL.1
Feature
server
To other
ITU-T H.245 ITU-T H.245 ITU-T H.323
endpoints/zones
ITU-T H.323
basic
call
IP payload
H.323(06-06)_FL.2
L.2 Introduction
The essential requirement for an H.323-based stimulus protocol is to provide a set of capabilities
that allow supporting endpoints access to a potentially unlimited set of supplementary services.
There are many benefits to such a protocol, such as allowing endpoints to remain relatively
lightweight, and providing a degree of isolation from the effects of new feature introduction. These
services themselves are typically controlled by a Gatekeeper, a proxy, or other network entity. This
annex uses the term "Feature Server" to generically designate any network entity providing
configuration or stimulus control of endpoints according to the protocol described.
The goals of the protocol described in this annex are:
• support for arbitrary (standard and non-standard) supplementary services;
• interoperability of these services between Feature Server and endpoint;
• backwards compatibility with endpoints using H.323 (version 2 or later).
This protocol achieves these goals by incorporating significant portions of the protocol described in
Rec. ITU-T H.248.1. H.248.1 describes a purely stimulus model of endpoint control, whereas this
annex must necessarily be a hybrid of both stimulus and H.323-based functional models. Annex L
entities use H.248 PDUs in addition to standard H.323 messages to support this hybrid model.
This annex describes a framework that eases delivery of services into both H.323 and H.248-based
systems, by allowing a high degree of commonality between an Annex L Feature Server and the
components of an H.248 Media Gateway Controller (MGC) not related to media control. This
framework enables the reuse of H.248-based packages in H.323-based systems, often with little or
no modification. For example, suitably designed packages can allow a Feature Server to control
various user interface elements of a compliant terminal, such as:
• write to a text display;
• provide hardware-independent indications to the endpoint, from which the endpoint may
control its own indicators, such as message waiting or line lamps;
• receive user input such as digits, text, special keys (such as hookswitch and function keys);
• assign functions to soft keys and into an endpoint resident directory;
• request application of specific tones;
• specify tones dynamically.
L.4 References
The following ITU-T Recommendations and other references contain provisions which, through
reference in this text, constitute provisions of this Recommendation. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision;
users of this Recommendation are therefore encouraged to investigate the possibility of applying the
most recent edition of the Recommendations and other references listed below. A list of the
currently valid ITU-T Recommendations is regularly published. The reference to a document within
this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
− Recommendation ITU-T H.248.1 (2005), Gateway control protocol: Version 3.
− Recommendation ITU-T H.248.3 (2000), Gateway control protocol: User interface
elements and actions packages.
− Recommendation ITU-T H.450.1 (1998), Generic functional protocol for the support of
supplementary services in H.323.
− Recommendation ITU-T X.691 (2008) | ISO/IEC 8825-2:2008, Information technology –
ASN.1 encoding rules: Specification of Packed Encoding Rules (PER).
M1.1 Scope
The purpose of this annex is to give guidance on how the generic tunnelling mechanism described
in 10.4 can be used to tunnel QSIG over H.323 networks. Other groups such as ISO/IEC are
ultimately responsible for the QSIG procedures themselves. Information on QSIG (also known as
PSS1) can be found in references [M1-1] and [M1-2] below.
RELEASE
All other messages ...
NOTE – If tones or announcements are provided by the called side, this message should be
tunnelled in a PROGRESS message rather than in FACILITY.
M2.1 Scope
The purpose of this annex is to give guidance on how the generic tunnelling mechanism described
in 10.4 can be used to tunnel ISUP over H.323 networks. ITU-T and other standardization bodies
are ultimately responsible for the ISUP procedures themselves. Information on ISUP can be found
in references [M2-1] and [M2-2] below.
H.225.0 messages tunnel the entire ISUP message, unchanged, starting with the Message type code
parameter, and ending with the other parameters. The binary content of the ISUP messages is
encoded as an OCTET STRING in the
H323-UU-PDU.tunnelledSignallingMessage.messageContent. Since the binary encoding of
ISUP messages is what is tunnelled, the integrity of the ISUP messages is fully preserved.
For example, the ISUP IAM message can be tunnelled in a H.225.0 SETUP message, and the
ISUP ANM message can be tunnelled in an H.225.0 Connect message. For other messages, it is
possible that there is no corresponding H.225.0 message (e.g., in the case of an ISUP IDR message)
or the corresponding message is not available because it has already been sent. In those cases, the
ISUP message may be tunnelled in an H.225.0 FACILITY message.
A single ISUP call can be tunnelled in a single H.323 call.
Some information elements in the H.225.0 message may have been modified by the H.323 network
and the gateway receiving the tunnelled ISUP message may need to override the corresponding
ISUP parameters.
The tunnellingRequired flag shall be included in the Setup message when the ISUP required
parameter in the IAM message indicates 'ISUP required'.
Table M2.3 is indicative only and illustrates an example of the mapping between ISUP messages
and H.225.0 messages.
M3.1 Scope
The purpose of this annex is to give guidance on how the generic tunnelling mechanism described
in 10.4 can be used to tunnel DSS1 (Q.931) over H.323 networks. Other groups may adapt this
procedure to accommodate national variants of DSS1.
M4.1 Scope
The purpose of this annex is to give guidance on how the generic tunnelling mechanism described
in 10.4 can be used to tunnel NSS over H.323 networks. Other groups in ITU-T are ultimately
responsible for the NSS procedures themselves. Information on NSS can be found in
Rec. ITU-T Q.1980.1.
M4.2 References
The following ITU-T Recommendations and other references contain provisions which, through
reference in this text, constitute provisions of this Recommendation. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision;
users of this Recommendation are therefore encouraged to investigate the possibility of applying the
most recent edition of the Recommendations and other references listed below. A list of the
currently valid ITU-T Recommendations is regularly published. The reference to a document within
this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
– Recommendation ITU-T Q.1980.1 (2004), The Narrowband Signalling Syntax (NSS) –
Syntax definition.
– Recommendation ITU-T X.691 (2008) | ISO/IEC 8825-2:2008, Information technology –
ASN.1 encoding rules: Specification of Packed Encoding Rules (PER).
H.225.0 messages tunnel the entire NSS message, unchanged, starting with the Version (VER)
parameter, and ending with two sequential pairs of carriage return-line feed (0xD0xA) octets. The
text content of the NSS messages is encoded as an OCTET STRING in the
H323-UU-PDU.tunnelledSignallingMessage.messageContent. Since the text encoding of NSS
messages is what is tunnelled, the integrity of the NSS messages is fully preserved.
For example, the NSS IAM message can be tunnelled in a H.225.0 SETUP message, and the NSS
ANM message can be tunnelled in an H.225.0 Connect message. For other messages, it is possible
that there is no corresponding H.225.0 message (e.g., in the case of an NSS IDR message) or the
corresponding message is not available because it has already been sent. In those cases, the NSS
message may be tunnelled in an H.225.0 FACILITY message.
A single NSS call should be tunnelled in a single H.323 call.
Some information elements in the H.225.0 message may have been modified by the H.323 network
and the gateway receiving the tunnelled NSS message may need to override the corresponding NSS
parameters.
IMPORTS
TunnelledProtocol,
NonStandardParameter
FROM H323-MESSAGES;
END
tunnellingRequired – If this field is present, the call shall only proceed if tunnelling is supported.
M5.1 Scope
The purpose of this annex is to give guidance on how the generic tunnelling mechanism described
in clause 10.4 can be used to tunnel common alerting protocol (CAP) messages [M5-1] over H.323
networks. This annex does not define the actions a receiving device should take after receiving a
CAP message since such actions will be dependent on the type of message received, physical
characteristics of the H.323 device, the intended recipients, and other considerations which are
outside the scope of a signalling specification.
O.1 Scope
This Recommendation defines a means for building multimedia communication services over an
arbitrary packet-based network, including the Internet. It is useful to take advantage of such services
as the Domain Name System (DNS) [O-1] and ENUM [O-9] in order to help facilitate the
completion of multimedia calls, especially when using H.323 over the Internet. This
Recommendation defines the procedures for using DNS to locate gatekeepers and endpoints and for
resolving H.323 URL aliases. This annex also defines parameters for use with the H.323 URL.
NOTE – These parameters may take on additional values in subsequent revisions of this Recommendation.
O.7.2 User parameter
Currently a single standard value for the user parameter is defined: phone.
This specification defines the following symbolic names to be used in the Proto field of the SRV
record according to RFC 2782 [O-3].
O.10.6 Example 2
This example shows a fragment of a DNS zone or DNS domain file for example.com. All
H.323 servers are listening on well-known TSAPs. The H.323 service is provided through both a
Border Element and Gatekeepers. There is no priority defined or assumed between the Border
Element and the Gatekeepers. It is a matter of application. For example, voice-only high quality
service is provided through the Border Element while H.323 videoconferencing is provided through
the Gatekeepers.
An H.323 voice phone residing in a domain would have the following URL: h323:my-
alias@example.com;service=be. In this case a lookup for _h323be._udp will be performed first
and succeed. Note that a lookup for _h323cs._tcp is allowed as well.
A videoconferencing service, provided by an H.323 MCU located in a zone of either a
main-gatekeeper or secondary-gatekeeper would be published as
h323:conference-alias@example.com;service=cs. This is due to the fact that the SRV records
matching _h323cs._tcp will be retrieved, based on the service-parameter. Further, using the
Weight field, actual access to the main-gatekeeper is three quarters that of the secondary-
gatekeeper if either of the Gatekeepers is up and running.
$ORIGIN example.com.
_h323be._udp SRV 0 1 2099 border-element.example.com.
_h323cs._tcp SRV 0 1 1720 secondary-gatekeeper.example.com.
_h323cs._tcp SRV 0 3 1720 main-gatekeeper.example.com.
border-element A 172.30.79.10
main-gatekeeper A 172.30.79.11
secondary-gatekeeper A 172.30.79.12
; NO H.323 access over H.323 Annex E is supported
*._h323mux SRV 0 0 0 .
; NO other services are supported (including H.323 Location Service)
*._tcp SRV 0 0 0 .
*._udp SRV 0 0 0 .
P.1 Scope
The purpose of this annex is to describe the procedures for transferring modem signalling over an
H.323-based network. The signalling procedures describe the use of H.245 (including Fast Connect
and Extended Fast Connect), State Signalling Events (SSEs) to signal endpoint capabilities, to open
and close logical channels, and to signal state changes. H.323 entities that support the carriage of
modem signals of IP networks shall provide that functionality in accordance with this annex.
P.2 References
The following ITU-T Recommendations and other references contain provisions which, through
reference in this text, constitute provisions of this Recommendation. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision;
users of this Recommendation are therefore encouraged to investigate the possibility of applying the
most recent edition of the Recommendations and other references listed below. A list of the
currently valid ITU-T Recommendations is regularly published. The reference to a document within
this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
[P-1] Recommendation ITU-T V.150.1 (2003), Modem-over-IP networks: Procedures for the
end-to-end connection of V-series DCEs.
[P-2] Recommendation ITU-T H.460.6 (2002), Extended Fast Connect feature.
[P-3] IETF RFC 2198 (1997), RTP Payload for Redundant Audio Data.
P.3 Definitions
This annex defines the following terms:
P.3.1 modem over IP: The transport of modem signals over an IP network as described in
Rec. ITU-T V.150.1.
P.3.2 modem relay: The transportation of modem data across a packet network using modem
termination at the network access points.
P.3.3 state signalling event: RTP-encoded event messages that coordinate switching between
different media states as defined in Annex C/V.150.1.
P.3.4 voice band data: The transport of modem signals over an audio channel of a packet
network with the encoding appropriate for modem signals.
P.4 Abbreviations
This annex uses the following abbreviations:
FEC Forward Error Correction
MoIP Modem over IP
MPS Multiple Payload Stream
OLC Open Logical Channel
RTP Real-Time Transport Protocol
SPRT Simple Packet Relay Transport
P.5 Introduction
H.323 systems have been widely deployed throughout the world for the carriage of audio, video and
data traffic over packet-based networks, including IP networks. One of the applications of H.323
has been for transiting audio calls between two disjoint circuit-switched networks or two points on
the same circuit-switched network. In such an application, the call is originated in a circuit-switched
network and delivered to an H.323 Gateway. This Gateway then establishes communication with a
remote Gateway that, in turn, delivers the call to a circuit-switched network.
In such applications, it is desirable to also allow calls between Gateways to be data calls, rather than
audio or video calls only. Annex D introduced the signalling procedures necessary to facilitate the
transport of facsimile data over an IP-based network between Gateways and other devices. The
focus of this annex is to specify the procedures for transporting modem data over an IP-based
network between two Gateways.
Figure P.1 graphically depicts H.323 Gateways that carry modem signals between modems over an
IP network.
Rec. ITU-T V.150.1 defines the general procedures for carrying modem signals over IP-based
networks between two Gateways and should be read in conjunction with this annex. Whereas
Rec. ITU-T V.150.1 does not define the carriage of modem signals within the context of any
particular call control protocol, this annex defines the procedures that are necessary and particular
to this Recommendation.
Unless explicitly stated otherwise, references to H.323 endpoints throughout the remainder of this
annex are to endpoints that are capable of carrying modem signals over an IP network.
Q.1 Scope
The purpose of this annex is to provide far-end camera control protocol based on H.281/H.224. It
also permits an H.323 endpoint to run any H.224 application using the IP/UDP/RTP/H.224 protocol
defined in this annex.
Q.2 References
The following ITU-T Recommendations and other references contain provisions which, through
reference in this text, constitute provisions of this Recommendation. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision;
users of this Recommendation are therefore encouraged to investigate the possibility of applying the
most recent edition of the Recommendations and other references listed below. A list of the
currently valid ITU-T Recommendations is regularly published. The reference to a document within
this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
[Q-1] Recommendation ITU-T H.224 (2005), A real time control protocol for simplex
applications using the H.221 LSD/HSD/MLP channels.
[Q-2] Recommendation ITU-T H.281 (1994), A far end camera control protocol for
videoconferences using H.224.
[Q-3] Recommendation ITU-T T.140 (1998), Protocol for multimedia application text
conversation.
Q.3 Introduction
The protocol described in this annex may be used to support far-end camera control (FECC) in this
Recommendation using the stack IP/UDP/RTP/H.224/H.281. This protocol supports both
point-to-point and multipoint scenarios.
This method may be used as a "simple" FECC scheme when the more sophisticated features of
H.282/H.283 are not needed.
NOTE – Recommendations ITU-T H.282 and H.283 have been withdrawn and their use is therefore
deprecated.
This method shall be used for FECC thru H.320-H.323 and H.324-H.323 gateways when the H.320
or H.324 endpoints do not support Rec. ITU-T H.282.
The requirements given below apply only in the case that the protocol described in this annex has
been selected, using the normal procedures of Rec. ITU-T H.245.
It is allowed to run any H.224 application using the IP/UDP/RTP/H.224 protocol defined in this
annex. The only other currently standardized H.224 application is Rec. ITU-T T.140.
R.4 Abbreviations
This annex uses the following abbreviations:
CRV Call Reference Value
GK Gatekeeper
GW Gateway
RAS Registration, Admission and Status
SCTP Stream Control Transmission Protocol (IETF RFC 4960) (Informative use only)
SDL Specification and Description Language
TCP Transmission Control Protocol
UDP User Datagram Protocol
Any previous connections that might be still open for the call shall be closed, this applies both to
the Call Signalling connection and the Call Control connection.
To facilitate synchronization of the logical channels state, the new fields IncludeFastStart in
STATUS INQUIRY and RobustnessFastStart in Status message may be used. Sender of the
Status message should include the RobustnessFastStart field containing the currently active
receive and transmit channels with the receive addresses for media and media control streams.
Sender of the STATUS INQUIRY message may request inclusion of the RobustnessFastStart
field in the Status message by setting IncludeFastStart to TRUE.
If an intermediate entity needs to synchronize the logical channel state it should send the STATUS
INQUIRY message to one of the call legs, should wait to Status message with fast start field, should
issue the Status and STATUS INQUIRY message to the other leg of the call, should wait for Status
message with the second leg logical channel information and should send the Status message to the
first leg of the call.
This procedure is used to synchronize the states of the logical channels that were opened through
both fast start procedure and H.245 logical channel establishment procedure.
In situations where the call before failure has not reached the active state, the call should be
dropped.
Both the recovering H.323 entity and its signalling neighbour shall implicitly reset their H.245 state
machines for the call as the recovering entity is not aware of any remote terminal capabilities or the
knowledge of the result of MSD negotiations. Moreover, the recovering entity's capabilities may
differ from the failed entity. Before any H.245 messages are sent, both entities shall exchange
TCS messages and make the Master/Slave determination.
If the failed entity implements Method B, the signalling neighbour or the backup entity of the failed
entity can re-establish the call signalling connection. Whoever re-establishes the call signalling
connection, before sending any H.225.0 call signalling messages, the entity shall check if it is the
one that originated (caller side of) the call and if it already has prior calls to the recovered entity. If
the entity that is re-establishing the connection is on the caller side of the call and it has prior calls
to the signalling neighbour as shown in Figure R.5, then the entity shall assign a new CRV value for
this call and use it in all subsequent H.225.0 call signalling and RAS messages. The signalling
neighbour shall assign a unique CRV value for this call and use it in RAS messages in its
communication with the gatekeeper. If the entity that is re-establishing the connection is on the
called side of the call and it has prior calls from the signalling neighbour entity as shown in
Figure R.6, then the entity shall assign a new unique CRV value and use it in a H.225.0 call
signalling message with CRV flag = 1 because it is the destination side of the call. The signalling
neighbour entity shall adopt this new CRV for this call. All the subsequent H.225.0 call signalling
messages for this call shall use this new CRV value. The signalling neighbour entity, if required,
shall assign a unique CRV value for this call to be used in RAS messages.
Figure R.5 – Failed entity is of Method B and called side and Survived entity
initiates re-establishment
II.1 Introduction
H.323 recommends the use of transport level resource reservation mechanisms to fulfil the
QoS requirements of real-time video and audio streams. Although the transport level resource
reservation mechanisms themselves are beyond the scope of this Recommendation, the general
method and coordination of these transport level mechanisms between H.323 entities is described in
this appendix to prevent conflicting interoperability issues.
This appendix describes the use of RSVP (Resource reSerVation Protocol) as a possible mechanism
for providing transport level QoS over IP-based networks. Other protocols may be used; however,
the basic procedures defined in this appendix should still apply. Participants in a conference should
be able to signal their intentions, capabilities, and requirements in a standard, protocol-specific
manner. In addition, the signalling sequence of the resource reservation mechanisms must be
specified such that the call establishment interval is minimal.
RSVP is the transport level signalling protocol for reserving resources in unreliable IP-based
networks. Using RSVP, H.323 endpoints can reserve resources for a given real-time traffic stream
based on its QoS requirements. Only best-effort delivery of the packets is possible if the network
fails to reserve the required resources or if RSVP is absent.
In Figure II.2, a multipoint conference is shown. The Path messages are utilized in the same manner
as the simpler point-to-point case. It should be noted that the Resv requests are aggregated by the
routers to keep redundant reservation requests from occurring upstream.
Path messages must contain the complete destination/source addresses and a traffic specification.
Resv messages contain the reservation parameters and the required service. Path and Resv messages
for a given traffic stream should be sent as part of the openLogicalChannel procedure for that
particular stream. The reservation should be released during the closeLogicalChannel procedure
using the RSVP PathTear and ResvTear messages.
Note that RSVP Path and Resv messages use the same IP address/port pair as the media to be
delivered between endpoints. This means that these messages must be filtered out of the media
stream by the endpoints. This is not an issue for endpoints which do UDP filtering since RSVP
messages themselves are not UDP messages. Even so, the sender of a media stream should not use
RSVP when the receiver is not capable of it. RSVP capabilities are exchanged as part of the
capability exchange and open logical channel procedures.
RSVP is only a signalling protocol. Together with the appropriate QoS services (e.g., guaranteed
QoS or controlled-load service), scheduling mechanisms (e.g., weighted fair queuing), and
policy-based admission control module (e.g., local policy manager), RSVP is capable of satisfying
the QoS requirements of H.323 conference participants. In addition, RSVP is designed for
point-to-point links. If a path traverses a shared link, RSVP invokes the appropriate resource
reservation mechanism for the specific shared medium, e.g., SBM (Subnet Bandwidth
Management) in case of Ethernet. All the mechanisms mentioned in this paragraph are controlled
completely from within RSVP. Therefore, all that an H.323 endpoint needs is RSVP signalling.
Figure II.3 – Message sequence for opening a unicast logical channel with RSVP
Figure II.4 – Message sequence for opening a multicast logical channel with RSVP
Before sending out a closeLogicalChannel message for a given multicast stream, a sending
endpoint should send an RSVP PathTear message if the logical channel being closed is the last
channel carrying that multicast stream and if an RSVP session has been previously created for that
stream. When a receiving endpoint receives a closeLogicalChannel for a given multicast stream, it
should send an RSVP ResvTear message and an IGMP Leave message, if an RSVP session has
been previously created for that stream.
In the event of RSVP failure, the called endpoint will take action according to the derived
QOSMode set, as described in clause II.8.
III.1 Introduction
This appendix gives examples of how a Gatekeeper/proxy can implement user location services.
These services depend on the Gatekeeper using the Gatekeeper-routed call signalling model.
III.2 Signalling
In the scenario shown in Figure III.1, the Gatekeeper implements a "divert on no reply" service.
Endpoint 1 calls Endpoint 2 with the Call Signalling Channel routed through the Gatekeeper. If
there is no answer after some timeout, the Gatekeeper diverts the call to an alternate endpoint.
Messages (1) to (5) show the Gatekeeper attempting to establish a call between Endpoint 1 and
Endpoint 2. In this example, Endpoint 2 does not answer and so the Gatekeeper clears the call to
Endpoint 2 by sending Release Complete (6). The Gatekeeper then tries Endpoint 3 by sending
Setup (7). When Endpoint 3 answers the call using Connect (9), the Gatekeeper forwards the
Connect (10) back to Endpoint 1.
A similar approach can be used to provide "divert on busy" service. In this case, Endpoint 2 would
return a Release Complete indicating that is busy. The Gatekeeper would then attempt to establish a
call to Endpoint 3.
Note that if the Gatekeeper is performing this type of user location algorithm, it should not pass the
h245Address field in any of the Setup Acknowledge, Call Proceeding, and Alerting messages from
Endpoint 2 or Endpoint 3 to Endpoint 1 as this may give the wrong result.
IV.1 Introduction
This appendix describes a simple method by which alternative logical channels may be signalled.
No coding or semantic changes are required.
This method depends upon the guaranteed ordered delivery that is provided by TCP and is
consequently equally applicable to both tunnelled and non-tunnelled H.245 signalling. Tunnelled
signalling further depends upon guaranteed processing order where multiple H.245 messages are
tunnelled in a single H.225.0 call signalling message.
IV.2 Signalling
All alternative logical channels are identified by the use of a common
forwardLogicalChannelNumber in openLogicalChannel messages, one alternative per message.
Messages may be sent either via the H.245 tunnel (one or more OLC messages per call signalling
message) or via separate H.245 connection. Alternative logical channels are signalled in order of
decreasing desirability, i.e., the first OLC message specifies the dataType that the sender of the
OLC would prefer to use on the logical channel.
The receiver of these OLC messages is not required to be aware that this method of alternative
propositions is being used. Prior to reception of an acceptable OLC request, it will reject
unacceptable OLC requests, typically with a cause code of dataTypeNotSupported,
dataTypeNotAvailable, or unknownDataType. When an acceptable OLC request is received, the
endpoint will respond with an openLogicalChannelAck message. Any subsequently received
alternative OLCs are rejected by the receiver with a cause code of unspecified, as the requested
logical channel number will map to a currently open channel.
The sender of such a prioritized sequence of openLogicalChannel messages must keep track of the
number of OLC reject messages received prior to reception of an openLogicalChannelAck
message in order to determine which proposed alternative was accepted by the peer.
Similar descriptions are also defined for non-geographic areas. Rec. ITU-T E.164 further defines
country codes (CC) for all the countries and regions of the world.
An international E.164 number always starts with a country code and its total length is always
15 digits or less. More importantly, it does not include any prefixes that are part of a dialling plan
(for example, "011" for an international call placed in North America, or "1" for a long-distance
call), nor does it include "#" or "*". The number "49 30 345 67 00" is an E.164 number with
CC = 49 for Germany. A national number is the international number stripped of the country code,
"30 345 67 00" in this case. The subscriber number is the national number stripped of the national
destination code, "345 67 00" in this case.
An E.164 number has global significance: any E.164 number can be reached from any location in
the world. A "dialled digit sequence", however, only has significance within a specific domain.
Within a typical private numbering plan in an enterprise, for example, a prefix, such as "9", may
indicate that a call goes "outside", at which point the local telephone company's dialling plan takes
over. Each telephone company or private network is free to choose its own dialling plan. It is also
free to change it as it pleases – and frequently does so (adding new area codes, for example).
In a typical geographically determined network where users input telephone numbers manually and
where users do not travel too much, having different dialling plans everywhere is usually a problem.
However, when a user travels, the user must determine the other network's numbering plan in order
to place calls. When computer systems perform the dialling automatically, the user is usually
required to customize the dialling software for every region or network.
Because of these issues with varying dialling plans and automated dialling, it is essential to be able
to refer to an absolute "telephone number" instead of "what you have to dial to reach it from a
specific location". Proper usage of E.164 numbers can resolve these issues. Many systems use
E.164 numbers instead of dialled digits: for example, a PBX may gather the dialled digits from a
A level n Regional Number (RN) shall have significance only within the level n region to which it
applies. When that number is used outside that level n region, it shall be in the form of an RN of
level greater than n. Only a Complete Number shall have significance throughout the entire PNP.
A typical example in North America would be a 4-digit "extension" as the Level 0 Regional
Number: a 3-digit "location code" combined with the 4-digit "extension" would form the Level 1
Regional Number. The Level 2 Regional Number would be nil.
A prefix could also be used to signal which regional number is used, and would not be part of the
regional number per se, but only part of the dialling plan. Again, a typical example would be the use
of digit "6" to access a Level 1 Regional Number, and no digit for a Level 0 Regional Number.
The following are a set of definitions from ISO/IEC 11571:
V.2.1 private numbering plan (PNP): The numbering plan explicitly relating to a particular
private numbering domain, defined by the PISN Administrator of that domain.
V.2.2 PNP number: A number belonging to a PNP.
V.2.3 region: The entire domain or a sub-domain of a PNP. A region does not necessarily
correspond to a geographical area of a PISN.
V.2.4 region code (RC): The leading digits of a PNP Number which identify a region. The
RC may be omitted to yield a shortened form of a PNP Number for use internally to that region.
V.2.5 regional number (RN): A particular form of a PNP Number which is unambiguous in the
region concerned.
V.2.6 complete number: A number which is unambiguous in the entire PNP, i.e., which
corresponds to the highest regional level employed in that PISN.
This appendix describes a typical H.323 stack. Figure VI.1 shows how RAS, H.225.0 call signalling
and media are implemented using the IP infrastructure.
The arrow between H.245 and H.225.0 points out that H.245 can be tunnelled in H.225.0.
The arrow between H.225.0 call signalling and H.225.0 RAS points out that H.225.0 call signalling
can be tunnelled in H.225.0 RAS.
Audio
ITU-T T.120 codecs Video RTCP ITU-T H.225.0 ITU-T H.245 ITU-T H.225.0
ITU-T G.711 codecs call RAS
ITU-T G.723.1 ITU-T H.261 signalling
ITU-T G.722.1 ITU-T H.263
ITU-T H.264
… …
RTP
IP
H.323(06-06)_FVI.1
VII.2 Informative Note 2: Call state sharing between an entity and its backup peer
This note suggests ways to implement call state sharing between one entity and another entity that
serves as its backup peer. The selection of a method is not part of this Recommendation. Since the
method is not standardized, peers from different vendors may not be able to serve as robust backup
peers.
VII.2.1 Shared memory
If members of the cluster are physically located in the same cabinet, they may be able to use a
shared (or reflective) memory device. This is similar to many fault-tolerant platforms, but might
simply write to shared memory at each checkpoint rather than running a fault-tolerant OS.
VII.2.2 Shared disk
If the members of the cluster are physically located near each other, they can use a shared disk and
write state information at each checkpoint.
VII.2.3 Message passing
The active entity can send a message updating the shared state to each of the other members of the
cluster at each checkpoint. This implements a distributed shared memory sometimes referred to as a
bulletin board. The messages can be sent using distinct UDP messages, multicast messages,
persistent TCP links or fault-tolerant message-passing protocol such as ASAP (which supports a
send-to-group multicast mechanism not requiring multicast IP).
ASAP ENRP
SCTP
IP
H.323(06-06)_FVII.2.3.1.2
This can provide fast fail-over, transparent to the upper layer application, at both link and session
levels:
1) link level (SCTP) – multi-homing support, surviving network failures;
2) session level (ASAP) – server pool support (2N, N+K, etc.), surviving process/node
failures.
In addition, ASAP provides:
• location transparency;
• load sharing;
• plug-and-play, i.e., hot scalability;
• avoiding single point of failure.
VII.2.3.1.3 An architectural view of an H.323 system
Figure VII.1 shows an H.323 system built upon an ASAP/SCTP model.
GK GK' GK"
Server pool
GW 2 GW 1
ENRP namespace
server cloud
H.323(06-06)_FVII.1
In the system, all the H.323 components, including the GW 1, GW 2 and GKs employ the
ASAP/SCTP stacks as shown in the previous clause. In this example, we assume that the
H.323 Gatekeeper is implemented as a server pool (the figure depicts the internals of the server
pool), while the gateways may or may not be implemented as server pools.
As shown in the figure, inside the Gatekeeper server pool we have multiple instances of
functionally identical H.323 Gatekeepers, GK, GK', ..., GK". The GK instances share call state and
other call recovery critical information among themselves using an internal distributed bulletin
board. The mechanism and implementation of the distributed bulletin board is vendor specific and
thus out of the scope of either ASAP or SCTP (the bulletin board, however, can use ASAP/SCTP to
gain fault tolerance and scalability for itself).
All the ASAP/SCTP nodes, including GWs and GKs, rely on either a single ENRP namespace
server cloud or a group of bridged ENRP clouds for name registration and name translation
services [VII.2-2]. To form the Gatekeeper server pool, all GK instances register to the ENRP
namespace under the same name. However, each individual GK instance may choose to register
with a different load-handling capability.
Each H.323 call message will be delivered by ASAP to one of the GK instances in the server pool.
The selection of the receiver GK instance is based on both the load-sharing policy in effect and the
current status of each GK instance in the server pool. It is sometimes very desirable to have all the
H.323 signalling messages related to a call handled by the same GK instance for the entire life cycle
of the call, and only let another GK instance take over the call in case the original handler dies. We
call this relationship between the call and the server instance "loose binding". ASAP is designed to
support this type of "loose binding" relationship very easily [VII.2-2] and [VII.2-3].
Moreover, when a GK instance is handling a call, it should publish to the distributed bulletin board
(i.e., "checkpoint") all critical call state information every time the call reaches a certain stage in its
life cycle. This information will help the alternate GK instance to recover the call in case the
original call handler crashes.
VII.2.3.1.4 An example H.323 call
For the purposes of describing a call, signalling flows are used per Figure VII.2.
ARQ
ACF
(D)
Alert
Alert (E)
Alert
(F)
Connect
Connect
(G)
Connect (H)
H.323(06-06)_FVII.2
Note that the references in this call flow are quite old and the second Gatekeeper is extrapolated.
There may be some differences in the way the current H.323 specification would have a call flow,
but the point here is to emphasize how ASAP/SCTP would be used. Even if minor items are
incorrect in the above figure, this does not invalidate the example.
VII.2.3.1.4.1 General description
The call starts with Endpoint-1 requesting bandwidth. The endpoint would in this case use ASAP to
query a Gatekeeper, known by a name or possibly by a well-known IP address and port. In either
case, an ENRP name translation query (not shown) would propagate to the endpoint the set of all
Gatekeepers (primary and any redundant) in the server pool. This information would be populated
into a ASAP layer local cache in Endpoint-1 for future reference in case of a failure. This same
caching would occur in all ASAP endpoints in the chain transparent to the call itself. Note that
caching is an optional feature. Since it is an option, endpoints not implementing it can still obtain an
alternate Gatekeeper, an additional query would be needed to the ENRP server at the time of failure
detection.
Note we now hit point (A), at this step the Gatekeeper allocates bandwidth and checkpoints this
bandwidth utilization information message into a "bulletin board" area. This "bulletin board" area
could be any of the following:
• a piece of distributed shared memory being maintained by a separate subsystem;
• a piece of reflective memory specifically built for this purpose;
• a distributed commercial database;
• some other creative invention.
Note that the point here is that the redundant/peer Gatekeepers have to share call states in some
way. Any existing or future mechanism conceived to share call state can be used.
Gatekeeper-1 populates its ARQ-related state and pushes this information to the "bulletin board"
and responds to the request in the normal manner, i.e., with an ACF.
Series E Overall network operation, telephone service, service operation and human factors
Series J Cable networks and transmission of television, sound programme and other multimedia signals
Series L Construction, installation and protection of cables and other elements of outside plant
Series Y Global information infrastructure, Internet protocol aspects and next-generation networks
Printed in Switzerland
Geneva, 2010