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 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