INTERNET-DRAFT EXPIRES: SEPTEMBER 1997 INTERNET-DRAFT
Internet-Draft Philip Lantz
Category: Informational Intel Corporation
Expires in six months February 1997
Usage of H.323 on the Internet
<draft-rfced-info-lantz-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress".
To learn the current status of any Internet-Draft, please check the
"1id-abstract.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
The H.323 standard defined by the International Telecommunication
Union (ITU) describes "Visual telephone systems and equipment for
local area networks which provide a non-guaranteed quality of
service", that is to say, video conferencing over Local Area Networks
and the Internet.
Although it has been generally accepted that H.323 is an appropriate
standard for audio/video telephony on the Internet, it is a complex
standard. It describes a broad and complex set of capabilities,
including interoperation with other types of video conferencing
systems, and contains references to a number of other ITU standards.
This document describes the parts of the standard that are necessary
for Internet telephony and multipoint conferencing. It describes the
messages that are necessary to work with other H.323 implementations.
In a separate section, it also lists the messages that must be
implemented to be H.323 compliant.
This document is a guide to make the standard more accessible. It is
not intended to duplicate information in the standard. It does not
contain specifications of the messages or details of the protocol.
1. Introduction
The H.323 standard covers tightly-controlled point-to-point and
multipoint audio and video conferencing over non-guaranteed quality
of service networks. In addition to video conferencing terminals,
H.323 describes gateways, which allow interoperation of H.323 systems
with audio/video conferencing systems on ISDN, POTS, and other
transports. It also describes gatekeepers, which provide admission
control and address translation.
Lantz [Page 1]
I-D Usage of H.323 on the Internet February 1997
Definition of the H.323 standard was begun by the ITU to enable
interoperation between existing H.320 systems and new LAN-based video
conferencing systems. Early in the standardization process, it became
clear that enabling calls between systems on a LAN was equally
important. It has since become clear that H.323 is also appropriate
for video conferencing over the Internet.
Because of its history, and the ITU standardization process, the
H.323 standard requires a number of features which are of little
importance in some environments. An implementation that is designed
to work in a known environment may take some shortcuts such that the
implementation would not be compliant with the standard but would
still interoperate with most compliant implementations in the
specified environment. It is hoped that full H.323 implementations
will be tolerant of peers that are not fully compliant, to allow
communication among a wide range of implementations.
This document describes the basic messages used to set up a point-
to-point or multipoint conference, which enable a relatively simple
conferencing application to interoperate with compliant H.323
implementations on the Internet. This document purposely does not go
into details of all the standard's requirements. It glosses over
some finer points and recommends simplifying courses of action which
do not take into account all of the complex features of the standard.
The standard itself should be consulted to determine its exact
requirements.
The final section of this document is a synopsis of the messages
required to be fully compliant with the standard. For most messages,
only a minimal implementation is necessary to be fully compliant.
1.1. H.323 Terminology
"terminal": an endpoint in a conference with a user and audio/video
input and output. This document is primarily focused on the
implementation of an H.323 terminal.
"gatekeeper": controls usage of the network for conferencing and may
perform address translation and other services
"gateway": enables H.323 terminals to connect to ITU terminals on
ISDN, POTS, or other types of networks
"Multipoint Controller (MC)": provides centralized control for a
conference with three or more terminals or gateways
"Multipoint Control Unit (MCU)": provides audio and/or video
processing for a conference with three or more terminals or
gateways so they don't have to manage multiple audio and video
streams
1.2. Standards Documents
H.323 standard-based video conferencing is described by a number of
ITU documents. H.323 itself describes the system components and the
procedures for establishing conferences. H.225.0 specifies the call
Lantz [Page 2]
I-D Usage of H.323 on the Internet February 1997
setup and gatekeeper messages and describes the usage of RTP. The
call setup messages in H.225.0 are based on messages defined in
Q.931. Q.931 is the definition of part of the signaling system for
ISDN, and parts of it were adapted for use in H.323. Q.931 must be
consulted for the specification of those parts of the messages which
H.225.0 inherits. H.245 specifies the conference control and
capability exchange messages. H.245 defines control messages for
several ITU conferencing standards. H.323 uses a subset of these
messages. The H.323 Implementer's Guide contains corrections to the
standards documents and clarifications which are necessary to
properly implement the standard. There are additional documents
which describe the audio and video codecs, message encoding rules,
and other topics.
1.3. ASN.1
The structure of H.245 messages is described using a language called
ASN.1, defined in X.680. The extensions to Q.931 messages defined in
H.225.0 are also described using ASN.1. The encoding of ASN.1 is
described in X.691. While it may be possible to hand-generate code
to encode H.245 messages, it is not very practical. There are tools
available which read the ASN.1 syntax (extracted directly from the
standard) and generate a header file defining a structure for each
message and code to encode and decode the messages. Use of these
tools will also help ensure compatibility with other implementations.
2. Overview of point-to-point conference operation
Establishment of a point-to-point H.323 conference requires two TCP
connections between the two terminals, one for call setup and the
other for conference control and capability exchange. The initial
connection is made from the caller to a well-known port on the
callee. This connection carries the call setup messages defined in
H.225.0, and is commonly called the Q.931 channel. Upon receipt of
the incoming call, the callee listens for a TCP connection on a
dynamic port; the callee communicates this port in the acceptance
message. The caller then establishes the second TCP connection to
that port. The second connection carries the conference control
messages defined in H.245. Once the H.245 channel is established, the
first connection is no longer necessary (in a simple conference
environment) and may be closed by either endpoint.
The H.245 channel is used by the terminals to exchange audio and
video capabilities and perform master/slave determination. It is
then used to signal opening logical channels for audio and video,
which causes RTP sessions to be created for the media streams. The
H.245 channel remains open for the duration of the conference. It is
used to signal the end of the conference.
Lantz [Page 3]
I-D Usage of H.323 on the Internet February 1997
3. Call Setup
Call setup messages are sent on the first TCP connection the caller
establishes to the callee. Four call setup messages are necessary
for simple conferences. Their use and syntax are defined in H.225.0
and Q.931. The necessary messages are:
Setup
Alerting
Connect
Release Complete
The caller sends Setup to initiate the conference immediately after
establishing the TCP connection. The Setup message contains the
caller's name and IP address. The callee sends Alerting after
notifying the user of the incoming call, if the call will not be
accepted without user intervention. The callee sends Connect to
accept the call or Release Complete to refuse the call. The Connect
message contains the address and port on which the callee is
listening for the H.245 connection.
Either Alerting, Connect, or Release Complete must be sent by the
callee immediately upon receipt of Setup; one of these must be
received by the caller before its setup timer expires. After Alerting
is sent, the user has up to 3 minutes to accept or refuse the call.
To be fully H.323 compliant, four additional messages must be
supported. See section 9, "Compliance".
3.1. Setup
The following fields of the Setup message carry useful information
for simple point-to-point conferences. Some of these fields are in
the Q.931-defined part, and some are in the H.225.0-defined
extensions. See H.225.0 and Q.931 for information on the content and
formatting of these fields.
Display - should contain caller name for display to the callee
sourceInfo - manufacturer and product version information
sourceCallSignalAddress - IP address of caller
The following additional fields must be included as part of the
syntax. Except as noted, they may have fixed values for all simple
conferences.
Protocol discriminator
Call reference - unique for simultaneous calls
Message type
Bearer capability
protocolIdentifier
destCallSignalAddress - IP address of callee
activeMC
conferenceID - unique for every call
conferenceGoal
callType
Lantz [Page 4]
I-D Usage of H.323 on the Internet February 1997
3.2. Alerting
The Alerting message contains no useful fields. When it is received,
the calling terminal should provide outgoing ring indication to the
user and stop the setup timer, which was started when the Setup
message was sent. The following fields must be included as part of
the syntax. Except as noted, they have fixed values.
Protocol discriminator
Call reference - the value received in the Setup message
Message type
protocolIdentifier
destinationInfo - manufacturer and product version information
3.3. Connect
The following fields of the Connect message carry useful information
for simple point-to-point conferences.
Display - should contain callee name for display to the caller
h245Address - IP address and port to establish H.245 connection
destinationInfo - manufacturer and product version information
The following additional fields must be included as part of the
syntax. Except as noted, they have fixed values.
Protocol discriminator
Call reference - the value received in the Setup message
Message type
protocolIdentifier
conferenceID - the value received in the Setup message
3.4. Release Complete
The only useful information in the Release Complete message is the
reason for refusing the call. This may be carried in either the Cause
field or the reason field, depending on the specific reason. Reasons
defined by Q.850 are coded in the Cause field. Additional reasons
defined by H.225.0 are coded in the reason field. Either the Cause
field or the reason field must be present.
The following additional fields must be included as part of the
syntax. Except as noted, they have fixed values.
Protocol discriminator
Call reference - the value received in the Setup message
Message type
protocolIdentifier
4. Conference control
Conference control and capability exchange messages are sent on the
second TCP connection, which the caller establishes to a dynamic port
on the callee. The messages are defined in H.245.
Lantz [Page 5]
I-D Usage of H.323 on the Internet February 1997
The following H.245 messages are necessary for a simple conference:
Terminal Capability Set, Acknowledge
Master/Slave Determination, Acknowledge, Reject
Open Logical Channel, Acknowledge, Reject
End Session
To be fully H.323 compliant, additional messages must be supported.
See section 9, "Compliance".
4.1. Terminal Capability Set
Terminal Capability Set is the first message sent by each terminal on
the H.245 channel. It contains a potentially complex description of
the audio, video, multipoint, and data capabilities of the terminal.
In the simplest case, the terminal capability set may list a set of
audio and video capabilities, and indicate that the terminal can do
any of them simultaneously. If a terminal has bandwidth or processing
limits which constrain which capabilities can be performed
simultaneously, the terminal capability set can describe these
constraints. The terminal capability set may contain transmit
capabilities as well as receive capabilities, but it need not; a
terminal may choose to send any media type and format allowed by the
peer's receive capabilities, whether or not the format is listed as a
transmit capability in its own capability set. The format of the
terminal capability set is fully described in H.245.
4.2. Master/Slave Determination
In an H.323 conference, one entity in the conference is identified as
the master. In a multipoint conference, the master is called the
Multipoint Controller (MC), and has a significant role, as described
in section 6, "Multipoint". In a point-to-point conference, the
master has a variety of minor roles. The master in a point-to-point
conference is chosen at random, if the two terminals have similar
capabilities. However, if one terminal is capable of being MC and
the other is not, the MC-capable terminal will always be selected
master, to allow the conference to expand to multipoint if desired.
Master/Slave Determination is sent by each terminal after it has sent
Terminal Capability Set. The terminal does not need to wait for a
response to Terminal Capability Set before sending Master/Slave
Determination. If a terminal receives Master/Slave Determination
before sending its own, it does not need to send it, but only needs
to send Master/Slave Determination Ack.
Each terminal generates a random number and sends it in the
Master/Slave Determination message. Which terminal is the master is
determined by comparison of the terminal types and the random
numbers. If both endpoints send Master/Slave Determination, both
endpoints will reach the same conclusion about who is master. If one
endpoint receives Master/Slave Determination before sending its own,
it makes the determination. In any case each terminal sends
Lantz [Page 6]
I-D Usage of H.323 on the Internet February 1997
Master/Slave Determination Ack indicating its conclusion.
Master/Slave Determination Reject is sent if the random numbers
chosen by the two endpoints are the same; when this message is
received, Master/Slave Determination is sent again with a new random
number.
4.3. Open Logical Channel
Logical channels for audio and video are always opened by the
terminal that will send data on the channel. The Open Logical
Channel message indicates to the peer the intent to send audio or
video in a specific format. It must specify an Audio Capability or
Video Capability that is compatible with a receive capability in the
peer's terminal capability set. The Open Logical Channel message also
includes the RTCP address and port on which the opener expects to
receive receiver reports. The peer responds with an Open Logical
Channel Ack message which includes the RTP address and port at which
it expects to receive the media stream and the RTCP address and port
at which it expects to receive sender reports. (When the underlying
network is UDP, the RTP and RTCP addresses differ only in that the
UDP port for the RTCP address is one greater than the UDP port for
the RTP address. However, H.323 does not assume this, and both
addresses must be fully specified in the Open Logical Channel Ack
message.)
If the media format is not one for which a static RTP payload type is
defined, the master assigns a dynamic payload type. If the master is
opening the channel, it puts the dynamic payload type in the Open
Logical Channel message; if the slave is opening the channel, the
master puts the dynamic payload type in the Open Logical Channel Ack
message.
Note that there is no mechanism for the two terminals to agree on
common data formats, nor is it necessary. Each terminal chooses the
data format(s) it wishes to send, within the constraints imposed by
the receive capabilities in the peer's terminal capability set. If a
terminal is unable to support an asymmetric mode (in which it is
sending and receiving different formats), it should express this
constraint in its terminal capability set.
The master is expected to recognize conflicts between simultaneous
open logical channel requests. If the master receives an open logical
channel request from the slave which it determines is incompatible
with an open logical channel request that it has sent, it must reject
the request from the slave. The slave is expected to accept the
channel opened by the master. The slave may then open a logical
channel that is compatible with the already opened channel(s).
4.4. End Session
End Session is sent by either terminal to terminate the call. When a
terminal receives End Session, it should stop sending audio and video
Lantz [Page 7]
I-D Usage of H.323 on the Internet February 1997
and respond with an End Session (although it should not be surprised
if the H.245 connection has already been closed!).
5. RTP/RTCP
H.225.0 includes the entire text of the definition of RTP/RTCP in an
annex. Although the description of RTP/RTCP was modified by the
editor of H.225.0, and it states that RTP must be used according to
the description in H.225.0, rather than according to the primary
specification of RTP, there are no substantive differences between
RTP as defined by RFC 1889 and 1890 and RTP as defined by H.225.0.
There are a few minor differences: 1) H.225.0 says that the RTCP BYE
message cannot be relied on to terminate a session; the appropriate
H.245 procedures must be used. For consistency with RTP, an H.323
terminal should send BYE, but it should not expect to receive it and
should ignore it if it is received. 2) H.225.0 says that the marker
bit need not be set in a video frame if it would increase end-to-end
latency (i.e., if an implementation does not know where the end of a
frame is until the start of the next frame). I expect most, if not
all, H.323 implementations to set the marker bit appropriately.
3) H.225.0 says that a single RTP packet cannot contain video from
more than one video frame. RFC 1890 does not have this restriction.
6. Multipoint
In a multipoint conference, conference control is centralized in an
entity called the Multipoint Controller (MC). The MC may reside in
any of the terminals, or in a gatekeeper, gateway, or MCU. The
location of the MC is determined at the beginning of each conference,
during master/slave determination. By building MC capability into
each terminal, no additional equipment is required to support a
multipoint conference, and a point-to-point conference can be easily
expanded into a multipoint conference. Each terminal in a multipoint
conference establishes its Q.931 and H.245 connections with the MC.
H.323 defines two modes of media distribution for multipoint
conferences, centralized and distributed. In a centralized multipoint
conference, each terminal sends its audio and video streams to a
Multipoint Control Unit (MCU), which redistributes them to the
terminals in the conference. In a distributed multipoint conference,
audio and video streams are sent directly from each source to all
receivers (using multicast, if available). The standard also defines
mixed mode, in which audio is centralized and video is distributed,
or vice versa.
A terminal signals its ability to participate in a distributed
multipoint conference in the Terminal Capability Set message. It
need not be capable of taking the role of MC to participate, but it
does need to be able to send its own audio and video streams to all
other participants, receive multiple audio and video streams from the
other participants, mix the audio streams, and select one or more of
Lantz [Page 8]
I-D Usage of H.323 on the Internet February 1997
the video streams to display.
6.1. Multipoint Call Setup
The steps for multipoint call setup are the same as for point-to-
point call setup. However, each terminal must call or be called by
the MC. If a terminal that is not in a conference calls a terminal
that is in a conference but is not the MC, the called terminal
responds with the H.225.0 Facility message, which informs the caller
that it should call the MC and gives it the MC call signaling address
and the conference ID. (The callee could of course refuse the call
with a busy indication instead.)
If a terminal in a multipoint conference wishes to invite another
terminal into the conference, it sends the Setup message to the MC.
The MC then establishes a connection to the new terminal and forwards
the Setup message to it. The calling terminal receives the Alerting
and Connect messages from the new terminal (forwarded by the MC), but
once the new terminal has accepted the call, there is no further
relationship between the calling terminal and the new terminal; the
new terminal simply appears as another terminal which has joined the
conference.
6.2. Multipoint Conference Control
The following H.245 messages are used in multipoint conferences:
MC Location Indication
Multipoint Mode Command
Communication Mode Command
Terminal Number Assign
Enter H243 Terminal ID, Terminal ID Response
Terminal List Request, Response
Request Terminal ID, MC Terminal ID Response
Terminal Joined Conference
Terminal Left Conference
The first five of these messages are sent by the MC to each terminal
when it joins the multipoint conference. MC Location Indication
tells the terminal where to route callers that wish to join the
multipoint conference, as described in section 6.1, "Multipoint Call
Setup". (MC Location Indication may also be sent by the master in a
point-to-point conference, to allow the slave to expand the
conference to multipoint.) Multipoint Mode Command simply informs the
terminal that it is participating in a multipoint conference.
Communication Mode Command tells the terminal the RTP sessions that
make up the multipoint conference. The terminal should generally open
a channel for each of these sessions, and expect to receive an Open
Logical Channel command for each session from the MC on behalf of
each terminal. Terminal Number Assign tells the terminal what its
terminal number is. It must use this value as the low byte of the
SSRC for each of its media streams. This enables other terminals to
associate the media streams with the terminal so it may be correlated
Lantz [Page 9]
I-D Usage of H.323 on the Internet February 1997
with other information about that terminal received from the MC.
Enter H243 Terminal ID is used by the MC to request the terminal's
id, which is a text string containing the human-readable name of the
terminal or (preferably) its user. The terminal responds with
Terminal ID Response.
The terminal may request information about the other terminals in the
conference with the rest of the messages. Terminal List Request is
used by a terminal to obtain from the MC a list of the terminal
numbers of all the terminals in the conference. The MC responds with
Terminal List Response. The terminal may obtain the Terminal ID of
each terminal in the conference by sending Request Terminal ID for
each terminal. The MC responds with MC Terminal ID Response for each
request. The MC sends Terminal Joined Conference and Terminal Left
Conference indications as additional terminals join and leave the
conference so each terminal can maintain an up-to-date list of the
terminals currently in the conference.
7. Gateways/Proxies
Gateways are defined in H.323 to provide interoperability with
previously defined ITU video conferencing standards such as H.320
(ISDN) and H.324 (POTS). A gateway which allows an H.323 terminal to
call a standard telephone (or vice versa) is also possible. Although
proxies were not anticipated by the standard, they can be thought of
as H.323-H.323 gateways, and the implementers group has described
their use.
For the most part, a gateway presents itself as an H.323 terminal, so
an H.323 terminal that is communicating with a non-H.323 terminal
doesn't have to function any differently than if it were
communicating with an H.323 terminal. The only difference is in the
Setup message, which must contain information specific to the path
the call is actually being routed on (such as a phone number). A
proxy also requires additional information in the Setup message, to
communicate the intended recipient of the call. The details of this
addressing information can be found in the H.323 Implementer's Guide.
8. Gatekeepers
The original purpose of the gatekeeper in H.323 is to control access
to the network for video conferencing. Along the way, it gained some
other responsibilities, such as address translation, which can be
used to locate gateways. Gatekeeper vendors are also adding other
features, such as conference and bandwidth usage logging, which can
be used for billing. Gatekeepers could also be used to control and
bill for access to services such as gateways to standard telephones.
A compliant terminal is required to attempt to locate and register
with a gatekeeper before conferencing, but not doing so will not
prevent it from interoperating with any other terminal.
Lantz [Page 10]
I-D Usage of H.323 on the Internet February 1997
9. Compliance
The previous sections describe the usage of H.323 for simple
conferences. There are a number of additional messages which H.323
requires be handled. Although most H.323 implementations, even fully
compliant ones, should work with a peer that does not handle these
messages, they must be implemented to be fully compliant.
H.323 also requires that every terminal have certain capabilities.
Every terminal must support centralized multipoint conferences, and
the H.245 messages associated with it. Every terminal must support
G.711 (although this requirement obviously cannot be met over a
modem--current implementations which are intended to operate over
low-bit-rate links use G.723.1). Every terminal that supports video
must support H.261 QCIF. Every terminal that supports H.263 must
support H.263 QCIF.
Every terminal must attempt to locate a gatekeeper. If a gatekeeper
responds, the terminal must register with it, send admission requests
before conferencing and abide by the gatekeeper's responses. This
document does not list the required gatekeeper messages.
9.1. Call Setup
H.225.0 requires support for the following eight messages:
Setup
Call Proceeding
Alerting
Connect
Release Complete
Status
Status Enquiry
Facility
Setup, Alerting, Connect, and Release Complete were discussed above.
Release Complete is also sent during conference shutdown if the Q.931
channel is still open. In a conference involving only two terminals,
either terminal may close the Q.931 channel as soon as the H.245
channel is opened, but in a conference involving a gatekeeper or
gateway, the terminal must keep the Q.931 channel open and send
Release Complete upon termination of the conference.
Call Proceeding should be sent upon receipt of the Setup message if
no other response can immediately be sent. In general this should
not be necessary for a terminal, because Alerting can be sent
instead. If Call Proceeding is received, the only action that is
required is to disable the 4 second timer which was started when the
Setup message was sent.
Status is sent in response to a Status Enquiry message or any message
that is not understood. If a terminal does not send either Status
Enquiry or any undefined messages, it does not need to handle receipt
Lantz [Page 11]
I-D Usage of H.323 on the Internet February 1997
of a Status message. A terminal is required to send Status at the
proper time to be compatible with entities which expect it.
Facility is used to redirect incoming calls, either for the purpose
of call forwarding or to cause all participants in a multipoint
conference to contact the MC. When a terminal receives Facility in
response to Setup, it sends Release Complete and closes the Q.931
channel, then establishes a new TCP connection to the call signaling
address given in the Facility message and sends a new Setup message.
(If the reason given in the Facility message is Route Call to MC, the
calling terminal may wish to ask the user if he wants to join a
multipoint conference before proceeding.)
This table lists all the H.225.0 messages which are required and the
required usage for each of these messages.
_____________________________________________________________________
| Message | When to send | What to do on receipt |
|___________________|_______________________|________________________|
| Setup | to initiate a | respond with |
| | conference | Alerting, Connect or |
| | | Release Complete |
|___________________|_______________________|________________________|
| Call Proceeding | on receipt of | stop 4 second timer |
| | Setup if neither | |
| | Alerting, Connect, | |
| | nor Release | |
| | Complete can be | |
| | sent immediately | |
|___________________|_______________________|________________________|
| Alerting | on receipt of | stop 4 second timer; |
| | Setup if user has | start 180 second |
| | been notified of | timer |
| | incoming call | |
|___________________|_______________________|________________________|
| Connect | after receipt of | establish H.245 |
| | Setup to accept | connection |
| | the incoming call | |
|___________________|_______________________|________________________|
| Release Complete | after receipt of | close Q.931 channel |
| | Setup to refuse an | and end call |
| | incoming call or | |
| | during conference | |
| | shutdown if Q.931 | |
| | channel is still | |
| | open | |
|___________________|_______________________|________________________|
| Status | on receipt of | may be ignored |
| | Status Enquiry | |
| | | |
| | | |
|___________________|_______________________|________________________|
Lantz [Page 12]
I-D Usage of H.323 on the Internet February 1997
_____________________________________________________________________
| Message | When to send | What to do on receipt |
|___________________|_______________________|________________________|
| Status Enquiry | not required | send Status |
|___________________|_______________________|________________________|
| Facility | on receipt of | send Release Complete |
| | Setup to forward | and establish new |
| | the incoming call | call to specified |
| | to another | address |
| | terminal or to the | |
| | MC in a multipoint | |
| | conference | |
|___________________|_______________________|________________________|
9.2. H.245 Messages
H.323 requires the use of the following H.245 messages:
Terminal Capability Set, Acknowledge, Reject, Release
Master/Slave Determination, Acknowledge, Reject, Release
Open Logical Channel, Acknowledge, Reject
Close Logical Channel, Acknowledge
Request Channel Close, Reject, Release
Request Mode, Acknowledge, Reject, Release
Round Trip Delay Request, Response
Maintenance Loop Request, Reject, Off Command
Send Terminal Capability Set
Flow Control Command
End Session Command
Function Not Supported
H2250 Maximum Skew
User Input Indication
Video Freeze Picture
Video Fast Update Picture
Video Fast Update GOB
Video Fast Update MB
Multipoint Mode Command
Cancel Multipoint Mode Command
MC Location Indication
Communication Mode Command
Terminal Number Assign
Terminal Capability Set Reject is sent if a Terminal Capability Set
message is received that is badly-formed or too large for the
receiving terminal to handle. If a terminal receives this, its
choices are to simplify its capability set or simply send End Session
to end the conference.
Logical channels for audio and video are always opened by the
terminal that will send data on the channel, but either terminal may
wish to close the channel. If a terminal wants to close a channel
Lantz [Page 13]
I-D Usage of H.323 on the Internet February 1997
that it has opened, it sends Close Logical Channel, which must be
acknowledged. (The peer cannot prevent a terminal from closing one of
its own channels!) If a terminal wants to close a channel that the
peer has opened, it sends Request Channel Close. The terminal
receiving this message may reject it for any reason, or it may
respond with Close Logical Channel.
Request Mode is used to request the peer to send specific data
formats, in contrast to Terminal Capability Set, which describes what
a terminal is able to receive, not necessarily what it wants to
receive. Request Mode may be sent in a point-to-point conference
only if transmit capabilities were included in the peer's terminal
capability set, so a terminal may avoid having to process this
message by simply omitting any transmit capabilities from its
terminal capability set. If a terminal does receive this message, it
may acknowledge the request and begin using one of the modes
requested, or it may reject the request, with or without a reason. In
a multipoint conference, the MC may send Request Mode to any
terminal, and the terminal is required to comply if the requested
mode is within its capabilities.
The Release messages for Terminal Capability Set, Master/Slave
Determination, Request Channel Close, and Request Mode are sent if no
response is received to the corresponding Request message within the
timeout period. (However, no value or range of values for the
timeout period is specified by the standard.)
Round Trip Delay Request must be responded to with Round Trip Delay
Response. Maintenance Loop Request may be rejected for any reason.
Maintenance Loop Off Command turns off any loopback in effect, and
may be ignored if no loopback modes are supported.
Send Terminal Capability Set requests the peer to re-send all or part
of its terminal capability set. A compliant endpoint must respond to
this by sending a Terminal Capability Set message. Flow Control
Command specifies a maximum bit rate for a specific logical channel
or the entire set of open logical channels. The bit rate limit
specified must be honored. Function Not Supported is sent if an
unsupported request, response, or command is received.
H2250 Maximum Skew specifies the time skew between when audio and
video that were captured at the same instant are delivered to the
network. Since this time is likely to be overwhelmed by jitter in the
network, I think it is a meaningless value, but the standard requires
that an estimate be made.
A terminal is required to allow the user to input the characters 0-9,
#, and * and send them in the User Input Indication message. This is
so that a gateway, phone mail system, or other H.323 entity can
provide services with a known user interface that all terminal will
support. This message may be ignored on receipt.
Lantz [Page 14]
I-D Usage of H.323 on the Internet February 1997
This table lists the H.245 messages which are required by H.323
(except for those described in section 4, "Conference Control", and
section 6, "Multipoint") and the simplest compliant behavior for each
of these messages. More sophisticated behavior is of course possible.
Where no action is specified on receipt, the message may be ignored.
_____________________________________________________________________
| Message | When to send | What to do on receipt |
|___________________|________________________|_______________________|
| Terminal | on receipt of a | send a simpler |
| Capability Set | Terminal | capability set or end |
| Reject | Capability Set | the conference |
| | that is badly- | |
| | formed or too | |
| | large to handle | |
|___________________|________________________|_______________________|
| Close Logical | if no response is | send Close Logical |
| Channel | received to Open | Channel Ack |
| | Logical Channel | |
| | within the timeout | |
| | period | |
|___________________|________________________|_______________________|
| Request Channel | | send Request Channel |
| Close | | Close Reject |
|___________________|________________________|_______________________|
| Request Mode | | In a point-to-point |
| | | conference: send |
| | | Request Mode Reject. |
| | | In a multipoint |
| | | conference: if the |
| | | requested mode is |
| | | within capabilities, |
| | | send Request Mode |
| | | Acknowledge and begin |
| | | using the requested |
| | | mode; otherwise send |
| | | Request Mode Reject |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
|___________________|________________________|_______________________|
Lantz [Page 15]
I-D Usage of H.323 on the Internet February 1997
_____________________________________________________________________
| Message | When to send | What to do on receipt |
|___________________|________________________|_______________________|
| Terminal | if no response is | |
| Capability Set | received to the | |
| Release | corresponding | |
|___________________| request within the | |
| Master/Slave | timeout period | |
| Determination | | |
| Release | | |
|___________________| | |
| Request Channel | | |
| Close Release | | |
|___________________| | |
| Request Mode | | |
| Release | | |
|___________________|________________________|_______________________|
| Round Trip Delay | | send Round Trip Delay |
| Request | | Response |
|___________________|________________________|_______________________|
| Maintenance Loop | | send Maintenance Loop |
| Request | | Reject |
|___________________|________________________|_______________________|
| Maintenance Loop | | turn off any loopback |
| Off Command | | in effect; ignore if |
| | | no loopback modes are |
| | | supported |
|___________________|________________________|_______________________|
| Send Terminal | | re-send all or part |
| Capability Set | | of the terminal |
| | | capability set, |
| | | according to the |
| | | request |
|___________________|________________________|_______________________|
| Flow Control | | adjust bit rates or |
| Command | | close channels to |
| | | meet the specified |
| | | bit rate |
|___________________|________________________|_______________________|
| Function Not | a request, | |
| Supported | response, or | |
| | command is | |
| | received that | |
| | cannot be decoded | |
| | or is not | |
| | supported | |
|___________________|________________________|_______________________|
| H2250 Maximum | after opening | |
| Skew | associated audio | |
| | and video channels | |
| | | |
|___________________|________________________|_______________________|
Lantz [Page 16]
I-D Usage of H.323 on the Internet February 1997
_____________________________________________________________________
| Message | When to send | What to do on receipt |
|___________________|________________________|_______________________|
| User Input | on user request | |
| Indication | | |
|___________________|________________________|_______________________|
| Video Freeze | | stop sending video at |
| Picture | | the end of the |
| | | current frame |
|___________________|________________________|_______________________|
| Video Fast Update| | perform a fast update |
| Picture | | of the specified |
|___________________| | picture element at |
| Video Fast Update| | the earliest |
| GOB | | opportunity |
|___________________| | |
| Video Fast Update| | |
| MB | | |
|___________________|________________________|_______________________|
| Cancel Multipoint| | no longer required to |
| Mode Command | | comply with Request |
| | | Mode |
|___________________|________________________|_______________________|
10. References
[1] ITU-T Recommendation H.323 (1996), "Visual Telephone Systems and
Equipment for Local Area Networks which provide a Non-Guaranteed
Quality of Service".
[2] ITU-T Recommendation H.225.0 (1996), "Media Stream Packetization
and Synchronization for Visual Telephone Systems on Non-
Guaranteed Quality of Service LANs".
[3] ITU-T Recommendation H.245 (1996), "Control Protocol for
Multimedia Communication".
[4] ITU-T Recommendation H.320 (1995), "Narrow-band ISDN Visual
Telephone Systems and Terminal Equipment".
[5] ITU-T Recommendation H.324 (1995), "Terminal for Low Bitrate
Multimedia Communications".
[6] ITU-T Recommendation Q.931 (1993), "ISDN User-Network Interface
Layer 3 Specification for Basic Call Control".
[7] ITU-T Recommendation Q.850 (1993), "Usage of Cause and Location
in the Digital Subscriber Signaling System No. 1 and the
Signaling System No. 7 ISDN User Part".
Lantz [Page 17]
I-D Usage of H.323 on the Internet February 1997
[8] ITU-T Recommendation X.680 (1994), "Information Technology -
Abstract Syntax Notation One (ASN.1) Specification of Basic
Notation".
[9] ITU-T Recommendation X.691 (1994), "Information Technology -
ASN.1 Encoding Rules - Specification of Packed Encoding Rules
(PER)".
[10] RFC 1889, "RTP: A Transport Protocol for Real-Time
Applications".
[11] RFC 1890, "RTP Profile for Audio and Video Conferences with
Minimal Control".
[12] ITU-T AVC-1100, "Implementer's Guide for the ITU-T H.323
Recommendation Series".
11. Author's Address
Philip Lantz
Intel Corporation, JF2-58
2111 NE 25th Ave.
Hillsboro, OR 97124
Phone: 503-264-8896
E-mail: prl@ibeam.intel.com
INTERNET-DRAFT EXPIRES: SEPTEMBER 1997 INTERNET-DRAFT