The Registration, Admission and Status (RAS) channel is used to carry messages used in the gatekeeper discovery and endpoint registration processes which associate an endpoint's alias address with its call signalling channel transport address. The RAS channel is an unreliable channel. Since the RAS messages are transmitted on an unreliable channel, H.225.0 recommends time-outs and retry counts for various messages. An endpoint or gatekeeper which cannot respond to a request within the specified timeout may use the Request in Progress (RIP) message to indicate that it is still processing the request. An endpoint or gatekeeper receiving the RIP resets its timeout timer and retry counter.

H.225.0 v2 is a standard which covers narrow-band visual telephone services defined in H.200/AV.120-Series Recommendations. It specifically deals with those situations where the transmission path includes one or more packet based networks, each of which is configured and managed to provide a non-guaranteed Quality of Service (QoS) which is not equivalent to that of N-ISDN such that additional protection or recovery mechanisms beyond those mandated by Rec. H.320 is necessary in the terminals. H.225.0 describes how audio, video, data, and control information on a packet based network can be managed to provide conversational services in H.323 equipment.

The structure of H.225 follows the Q.931 standard as shown in the following illustration:

Protocol discriminator
Distinguishes messages for user-network call control from other messages.

Length of call reference value
Length of the call reference value.

Call reference value
Identifies the call or facility registration/cancellation request at the local user-network interface to which the particular message applies.

Message Type
Identifies the function of the message sent.

Other information elements
Contents of the message.

H.245 is line transmission of non-telephone signals. It includes receiving and transmitting capabilities as well as mode preference from the receiving end, logical channel signalling, and Control and Indication. Acknowledged signalling procedures are specified to ensure reliable audiovisual and data communication.

H.245 messages are in ASN.1 syntax. They consist of an exchange of messages. MultimediaSystemControlMessage message types can be defined as request, response, command and indication messages. The following additional message sets are available:

H.261 describes a video stream for transport using the real-time transport protocol, RTP, with any of the underlying protocols that carry RTP. The format of the header is shown in the following illustration:

SBIT
Start bit. (3 bits) Number of most significant bits that are to be ignored in the first data octet.

EBIT
End bit. (3 bits) Number of least significant bits that are to be ignored in the last data octet.

I
INTRA-frame encoded data field. (1 bit) Set to 1 if this stream contains only INTRA-frame coded blocks and to 0 if this stream may or may not contain INTRA-frame coded blocks. The sense of this bit may not change during the course of the RTP session.

V
Motion Vector flag. (1 bit) Set to 0 if motion vectors are not used in this stream and to 1 if motion vectors may or may not be used in this stream. The sense of this bit may not change during the course of the session.

GOBN
GOB number. (4 bits) Encodes the GOB number in effect at the start of the packet. Set to 0 if the packet begins with a GOB header.

MBAP
Macroblock address predictor. (5 bits) Encodes the macroblock address predictor (i.e., the last MBA encoded in the previous packet). This predictor ranges from 0-32 (to predict the valid MBAs 1-33), but because the bit stream cannot be fragmented between a GOB header and MB 1, the predictor at the start of the packet can never be 0. Therefore, the range is 1-32, which is biased by -1 to fit in 5 bits. Set to 0 if the packet begins with a GOB header.

QUANT
Quantizer field. (5 bits) Shows the Quantizer value (MQUANT or GQUANT) in effect prior to the start of this packet. Set to 0 if the packet begins with a GOB header.

HMVD
Horizontal motion vector data field. (5 bits) Represents the reference horizontal motion vector data (MVD). Set to 0 if V flag is 0 or if the packet begins with a GOB header, or when the MTYPE of the last MB encoded in the previous packet was not MC. HMVD is encoded as a 2's complement number, and `10000' corresponding to the value -16 is forbidden (motion vector fields range from +/-15).

VMVD
Vertical motion vector data (VMVD). (5 bits) Reference vertical motion vector data (MVD). Set to 0 if V flag is 0 or if the packet begins with a GOB header, or when the MTYPE of the last MB encoded in the previous packet was not MC. VMVD is encoded as a 2's complement number, and `10000' corresponding to the value -16 is forbidden (motion vector fields range from +/-15).

H.263 specifies the payload format for encapsulating an H.263 bitstream in the Real-Time Transport Protocol (RTP). Three modes are defined for the H.263 payload header. An RTP packet can use one of the three modes for H.263 video streams depending on the desired network packet size and H.263 encoding options employed. The shortest H.263 payload header (mode A) supports fragmentation at Group of Block (GOB) boundaries. The long H.263 payload headers (modes B and C) support fragmentation at Macroblock (MB) boundaries.

For each RTP packet, the RTP fixed header is followed by the H.263 payload header, which is followed by the standard H.263 compressed bitstream. The size of the H.263 payload header is variable depending on the modes. The layout of an RTP H.263 video packet is shown as:

Three formats (mode A, mode B and mode C) are defined for the H.263 payload header. In mode A, an H.263 payload header of four bytes is present before the actual compressed H.263 video bitstream. It allows fragmentation at GOB boundaries. In mode B, an 8-byte H.263 payload header is used and each packet starts at MB boundaries without the PB-frames option. Finally, a 12-byte H.263 payload header is defined in mode C to support fragmentation at MB boundaries for frames that are coded with the PB-frames option.

The mode of each H.263 payload header is indicated by the F and P fields in the header. Packets of different modes can be intermixed. The format of the header for mode A is shown in the following illustration:

F
Flag bit indicates the mode of the payload header. Values are as follows:
0 - mode A.
1 - mode B or mode C depending on P bit.

P
P bit specifies the optional PB-frames mode.
0 - normal I or P frame.
1 - PB-frames.
When F=1, P also indicates modes as follows:
0 - mode B.
1 - mode C.

SBIT
Start bit position specifies number of most significant bits that are ignored in the first data byte.

EBIT
End bit position specifies number of least significant bits that are ignored in the last data byte.

SRC
Source format (bit 6,7 and 8 in PTYPE in the standard H.263 compressed bitstream) specifies the resolution of the current picture.

I
Picture coding type (bit 9 in PTYPE in the standard H.263 compressed bitstream).
0 - intra-coded.
1 - inter-coded.

U
Set to 1 if the Unrestricted Motion Vector option (bit 10 in PTYPE in the standard H.263 compressed bitstream) was set to 1 in the current picture header, otherwise 0.

S
Set to 1 if the Syntax-based Arithmetic Coding option (bit 11 in PTYPE in the standard H.263 compressed bitstream) was set to 1 for the current picture header, otherwise 0.

A
Set to 1 if the Advanced Prediction option (bit 12 in PTYPE in the standard H.263 compressed bitstream) was set to 1 for current picture header, otherwise 0.

R
Reserved, set to zero.

DBQ
Differential quantization parameter used to calculate quantizer for the B frame based on quantizer for the P frame, when PB-frames option is used. The value should be the same as DBQUANT in the standard H.263 compressed bitstream. Set to zero if PB-frames option is not used.

TRB
Temporal Reference for the B frame in the standard H.263 compressed bitstream. Set to zero if PB-frames option is not used.

TR
Temporal Reference for the P frame in the standard H.263 compressed bitstream. Set to zero if the PB-frames option is not used.

The format of the header for mode B is shown here:

F, P, SBIT, EBIT, SRC, I, U, S and A are defined the same as in mode A.

QUANT
Quantization value for the first MB coded at the starting of the packet. Set to 0 if the packet begins with a GOB header.

GOBN
GOB number in effect at the start of the packet. GOB number is specified differently for different resolutions.

MBA
The address within the GOB of the first MB in the packet, counting from zero in scan order. For example, the third MB in any GOB is given MBA=2.

R
Reserved, set to zero.

HMV1, VMV1
Horizontal and vertical motion vector predictors for the first MB in this packet. When four motion vectors are used for the current MB with advanced prediction option, they are the motion vector predictors for block number 1 in the MB. Each 7-bit field encodes a motion vector predictor in half pixel resolution as a 2's complement number.

HMV2, VMV2
Horizontal and vertical motion vector predictors for block number 3 in the first MB in this packet when four motion vectors are used with the advanced prediction option. This is needed because block number 3 in the MB needs different motion vector predictors from other blocks in the MB. These two fields are not used when the MB only has one motion vector. Each 7 bits field encodes a motion vector predictor in half pixel resolution as a 2's complement number.

The format of the header for mode C is shown here:

F, P, SBIT, EBIT, SRC, I, U, S, A, DBQ, TRB and TR are defined the same as in mode A. QUANT, GOBN, MBA, HMV1, VMV1, HMV2, VNV2 are defined the same as in mode B.

RR
Reserved, set to zero (19 bits).

H.235 provides enhancements within the framework of the H.3xx-Series Recommendations to incorporate security services such as Authentication and Privacy (data encryption). H.235 should work with other H series protocols that utilize H.245 as their control protocol.

All H.235 messages are encrypted as in ASN.1.

H.450.1

The H.45o series defines Supplementary Services for H.323, namely Call Transfer and Call Diversion.

The H.450.1 protocol deals with the procedures and signalling protocol between H.323 entities for the control of supplementary services. This signalling protocol is common to all H.323 supplementary services. The protocol is derived from the generic functional protocol specified in ISO/IEC 11582 for Private Integrated Services Networks (PISN).

The H.450 protocol is used to exchange signalling information to control supplementary services over a LAN. It works together with the H.225 protocol.

This protocol has no header as all messages are in text, in ASN.1 format.

H.450.2

This is a Call Transfer supplementary service for H.323. The H.450.2 protocol describes the procedures and signalling protocol for the call transfer supplementary service in H.323 networks. This supplementary service allows the served user A to transform an existing call (from user A to B) to a new call between user B and a third user C selected by A. User A may or may not have a call established with the third user prior to the call transfer. This is based on H.450.1

This protocol has no header as all messages are in text, in ASN.1 format.

H.450.3

The H.450.3 is a call diversion supplementary service for H.323. It describes the procedures and signalling protocol for the call diversion supplementary service in H.323 networks. This includes the services Call Forwarding Unconditional (SS-CFU), Call Forwarding Busy (SS-CFB), Call Forwarding No Reply (SS-CFNR) and Call Deflection (SS-CD). These are all supplementary services, which apply during call establishment, providing a diversion of an incoming call to another destination endpoint. This is based on H.450.1

This protocol has no header as all messages are in text, in ASN.1 format.

T.38

The T.38 IP-based fax service maps the T.30 fax protocol onto an IP network. Both fax and voiced data are managed through a single gateway. T.38 uses 2 protocols, one for UDP packets and one for TCP packets. Data is encoded using ASN.1 to ensure a standard technique. It allows users to transfer facsimile documents between 2 standard fax terminals over the Internet or other network using IP protocols. H.323 can be used here in the same way that it is used to support Voice over IP.

TCP messages

The T.38 data (Internet Fax Protocol) is contained in the payload of the TCP or UDP messages. The T.38 packet provides an alert for the start of a message. An ASN.1 Application tag identifies it; if this tag is not present the session is aborted.

The following is the format of the TCP Internet Fax Protocol packets.

Type

Data

Type
The type field contains the type of message. It describes the function of and the data of the packet.

Type can be T30_Indicator or T30_Data

Data
The data field is dependent on the type field. It contains the T.30 HDLC control data and the Phase C image (or BFT) data. It contains one or more fields. Each field has 2 parts.

UDP messages

T.38 messages may also be sent over the UDP transport layer. The UDP header is followed by the UDPTL payload which consists of sequence number and a payload.

Sequence number

Mandatory message (primary)

Optional redundant message or optional FEC message

Sequence number
The sequence number is used to identify the sequencing in the payload.

T.125

The T.120 family of protocols describe protocols and services for multipoint Data Conferencing including multilayer protocols which considerably enhance multimedia, MCU and codec control capabilities, permitting greater MCU operational sophistication beyond that described in H.231 and H.243.

T.125 describes the Multipoint Communication Service Protocol (MCS).

It defines:

• Procedures for a single protocol for the transfer of data and control information from one MCS provider to a peer MCS provider.
• The structure and encoding of the MCS protocol data units used for the transfer of data and control information.

Procedures may be:

• Interactions between 2 parallel MCS providers by exchanging MCS protocol data.
• Interactions between MCS providers and users by exchanging MCS primitives.
• Interactions between an MSC provider and a transport service provider by exchanging transport service primitives.

The MCS provider communicates with MCS users through a MCSAP (MCS Service Access Point), by means of MCS primitives defined in T.122. MCSPDU (MCS protocol Data unit) exchanges occur between MCS providers that host the same MCS domain. The MCS provider can have multiple peers; each reached directly by a different MCS connection or indirectly through a peer MCS provider. An MCS connection is composed of either one MAP connection or one or more transport connections. The protocol exchanges are preformed using the transport layer using a pair of TSAPs (Transport Service Access Points).

The MCS PDU is the MCS protocol data unit. This is the information exchanged in the MCS protocol consisting of control information transferred between MCS providers to coordinate their joint operation and possibly data transferred on behalf of MCS users for whom they provide service. Each MCSPDU is transported as one TSDU (Transport service data unit) across a TC (Transport connection) belonging to an MCS connection. Connect MCSPDUs are unlimited in size. Domain MCSPDUs are limited in size by a parameter of the MCS domain.

The structure of Version 2 and Version 3 MCSPDUs is defined in ASN.1 and appears as text or numeric messages.