H.323 Protocols Suite

H.225.0 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 QoS, which is not equivalent to that of N-ISDN, such that additional protection or recovery mechanisms beyond those mandated by Rec. H.320 are 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:

8	7	6	5	4	3	2	1	Octet
Protocol Discriminator								1
0	0	0	0	Length of call reference bits				2
Call reference value								3 (-4)
0	Message type
Information Elements
H.225 structure

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

Length of call ref
The 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. May be up to 2 octets in length.

Message type
Identifies the function of the message sent. The following message types are used:

000	xxxxx 00001 00010 00111 01111 00011 00101 01101	Call establishment messages: ALERTING CALL PROCEEDING CONNECT CONNECT KNOWLEDGE PROGRESS SETUP SETUP ACKNOWLEDGE
001	xxxxx 00110 01110 00010 00101 01101 00001 00000	Call information phase messages: RESUME RESUME ACKNOWLEDGE RESUME REJECT SUSPEND SUSPEND ACKNOWLEDGE SUSPEND REJECT USER INFORMATION
010	xxxxx 00101 01101 11010 00110 01110	Call clearing messages: DISCONNECT RELEASE RELEASE COMPLETE RESTART RESTART ACKNOWLEDGE
011	xxxxx 00000 11001 11011 01110 11101 10101	Miscellaneous messages: SEGMENT CONGESTION CONTROL INFORMATION NOTIFY STATUS STATUS ENQUIRY

Information elements
Two categories of information elements are defined: single octet information elements and variable length information elements, as shown in the following illustrations.

8	7	6	5	4	3	2	1	Octet
1	IEI			Contents of IE				1
Single octet information element format (type 1)

8	7	6	5	4	3	2	1	Octet
1	IE Identifier							1
Single octet information element format (type 2)

8	7	6	5	4	3	2	1	Octet
1	IEI							1
Length of contents of IE								2
Contents of IE								3-n
Variable length information element format

Enlarge	More Details

Interested in more details about testing this protocol?

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.

Interested in more details about testing this protocol?

H.323SET

http://www.itu.int/ITU-T : ITU-T Recommendation H.323.

The H.323 (SET) Simple Endpoint Types describes the standards for Simple Endpoint types in H323. Simple Endpoint Types, i.e. devices manufactured for a single purpose, may comprise a significant fraction of the overall set of H.323 capable end systems. In contrast to full-featured H.323 devices (many implementations of which are PC-based), the so-called Simple Endpoint Types (SETs) may be implemented in inexpensive stand-alone boxes, the most prominent example being the simple telephone.

The protocol header appears as follows:

7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0
0x00/0x40								Logical Channel Number																0	0	0	0	1	1	X
AuType			0	0	0	0	0	# Samples								0x80								length

Logical Channel Number
The number of the H.245 logical channel 1.

AuType
The audio codec to be used.

Samples
The number of samples - 1 per Audio packet as defined in ITU-T Rec. H.245.

Interested in more details about testing this protocol?

 

H.245

H.245:http://www.itu.int/itudoc/itu-t/rec/h/h245.html

• Master Slave Determination messages
• Terminal capability messages
• Logical channel signalling messages
• Multiplex Table signalling messages
• Request Multiplex Table signalling messages
• Request Mode messages
• Round Trip Delay messages
• Maintenance Loop messages
• Communication Mode Messages
• Conference Request and Response Messages
• TerminalID
• Commands and Indications

Important H.245 Messages

Message	Function
Master-Slave Determination	Determines which terminal is the master and which is the slave. Possible replies: Acknowledge, Reject, Release (in case of a time out).
Terminal Capability Set	Contains information about a terminal's capability to transmit and receive multimedia treams. Possible replies: Acknowledge, Reject, Release.
Open Logical Channel	Opens a logical channel for transport of audiovisual and data information. Possible replies: Acknowledge, Reject, Confirm.
Close Logical Channel	Closes a logical channel between two endpoints. Possible replies: Acknowledge
Request Mode	Used by a receive terminal to request particular modes of transmission from a transmit terminal. General mode types include VideoMode, AudioMode, DataMode and Encryption Mode. Possible replies: Acknowledge, Reject, Release.
Send Terminal Capability Set	Commands the far-end terminal to indicate its transmit and receive capabilities by sending one or more Terminal Capability Sets.
End Session Command	Indicates the end of the H.245 session. After transmission, the terminal will not send any more H.245 messages.

Enlarge	More Details

Interested in more details about testing this protocol?

 

H.450.1

http://www.itu.int/ITU-T/. ITU-T H.450.1

The H.450 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.

Interested in more details about testing this protocol?

 

H.450.2

http://www.itu.int/ITU-T/. ITU-T 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.

Interested in more details about testing this protocol?

 

H.450.3

http://www.itu.int/ITU-T/. ITU-T 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.

Interested in more details about testing this protocol?

 

H.450.4

http://www.itu.int/ITU-T/. ITU-T H.450.4

H450.4 is a supplementary service. Call Hold (SS-HOLD) allows the served user, which may be the originally calling or the called user, to interrupt communications on an existing call and then subsequently, if desired, re-establish (i.e.retrieve) communications with the held user.

SS-HOLD applies to the complete H.323 call (audio and video media streams) for which the supplementary service is being invoked. While having put the held user into a hold condition, the served user may perform other actions. Examples are: to communicate (consult) with another user, to have some private side talk, etc.

Hold may only be invoked by the served user for a call in the active state. Communication on the media channels is interrupted and the call is placed in the held state. The distant party is informed, and if appropriate, a specific MOH pattern (e.g. video and/or music on hold) may be provided to the held user. The served user may then originate or accept other calls, or use other services without impacting the call in the held state.

Messages are in ASN.1 format

Interested in more details about testing this protocol?

 

H.450.5

http://www.itu.int/ITU-T/. ITU-T H.450.5

Call Park (SS-PARK) is a supplementary service that enables a user A (Parking User) to place an existing call with user B (Parked User) to a Parking Position (parked-to endpoint). Upon successful invocation of SS-PARK, the parking endpoint becomes idle (except in the case of a local SS-PARK) and is no longer involved in the call with user B. The Parking Position typically provides music/announcement and/or video/still image to the Parked User while that user is parked.

Call Pickup (SS-PICKUP) is a supplementary service that enables a user (Picking-up User) to either retrieve a parked call or to pick up an alerting call.

• A parked call may be picked-up (unparked) by retrieving the Parked User from the parking endpoint A, from the parked-to endpoint or from any other authorized endpoint;
• An alerting call may be picked-up by any authorized Picking-up User.

The architecture of SS-PARK and SS-PICKUP allows any authorized user of an H.323 network to participate in this supplementary service and not just users within a single gatekeeper zone.

Upon successful invocation of SS-PICKUP, the Picking-up User is connected to the Parked User (in the case of picking-up a parked call) or is connected to the Calling User (in the case of picking-up an alerting call). SS-PARK and SS-PICKUP apply to the complete H.323 call for which the supplementary service is being invoked.

Messages are in ASN.1 format

Interested in more details about testing this protocol?

 

H.450.6
http://www.itu.int/ITU-T/. ITU-T H.450.6

The CW (call waiting) supplementary service (SS-CW) permits a busy user B to be informed of an incoming call while being engaged with one or more other calls. That is, SS-CW operates in case of an incoming call when a busy condition within the endpoint is encountered. As an option, a busy condition may also be encountered if the user is busy with workflow applications (e.g. writing emails).

When a user C (calling user) attempts to call a busy user B, user B is given an appropriate indication of the waiting call. The calling user C may be informed about SS-CW being invoked at the destination by being provided with an appropriate indication. After receiving the call waiting indication, user B has the choice of accepting, rejecting or ignoring the waiting call. During the call waiting condition, the calling user C has the option to release the call or to invoke other supplementary services, e.g. message waiting callback. The maximum number of calls that can be handled (e.g. active, held, alerting, waiting) for each endpoint is an implementation option. SS-CW occurs only when an attempt is made to exceed these limits.

The messages are in ASN.1 format.
Interested in more details about testing this protocol?

 

H.450.7

http://www.itu.int/ITU-T/ ITU-T H.450.7.

The Message Waiting Indication supplementary service provides a general purpose mechanism by which a user can be advised that messages intended for that user are available. A variety of message types are supported, such as voice mail, fax and teletex. In one of its simplest forms, when a message is left for a user, a Message Centre sends a notification to the Served User, where a Message Waiting lamp is lit.

Additional information provided by the notification mechanism allows the Served User to know the number of messages that are waiting, the types of messages, the subjects of the messages, and the priority of the highest priority message.
In an H.323 environment, where endpoints may commonly be directly associated with general purpose computers, applications such as automated message retrieval may be envisioned.

SS-MWI also provides a mechanism whereby it is possible for an endpoint to issue a callback request to the Served User.

The interrogation mechanism provided by SS-MWI allows a Served User to query Message Centres known to it, or a known Gatekeeper/proxy for the MWI activations currently applied to it. A typical usage of this mechanism is by a Served User to recreate its MWI status when the endpoint is returned to service, as the status may have changed while it was out of service.

The messages are in ASN.1 format.
Interested in more details about testing this protocol?

 

H.450.8

http://www.itu.int/ITU-T/.ITU-T H.450.8.

Calling Party Name Presentation is a feature which provides the name of the calling party to the called party. The calling party name may be provided by the calling endpoint or by the gatekeeper for gatekeeper routed calls that originate in the packet network. When the call is routed through the gatekeeper with which the calling endpoint is registered, that gatekeeper may provide a screening service that assures the name provided is actually that of the calling party. The gatekeeper may also provide the calling party name when no name is provided by the calling party, or when the calling party provides a false name. The method by which a gatekeeper obtains the name information is implementation dependent and outside the scope of this Recommendation.

When a call originates in the switched circuit network and enters the packet network through a gateway, the gateway passes to the packet network the calling party name information provided from the switched circuit network.

The messages are in ASN.1 format.

Interested in more details about testing this protocol?

 

H.450.9

http://www.itu.int/ITU-T/. ITU-T H.450.9.

Completion of Calls to Busy Subscribers (SS-CCBS) is a supplementary service that is offered to a calling User A. On encountering a busy called User B, it allows User A to request that User B's endpoint monitor User B and notify User A's endpoint when User B becomes free. On response by User A to that notification, User A's endpoint then tries to mplete the call to User B.

The messages are in ASN.1 format.

Interested in more details about testing this protocol?

 

H.450.10

http://www.itu.int/ITU-T/. ITU-T H.450.10.

The Call Offer supplementary service (SS-CO) enables a calling user A, encountering a busy destination user B, to "camp-on" to the busy user. This means that the call is indicated to user B and kept in a waiting state until user B reacts to the indication, rather than being released due to the busy condition.

SS-CO is a supplementary service which, on request from the calling user (or on that user's behalf), enables a call to be offered to a busy called user and to wait for that called user to accept the call, after the necessary resources have become available.
The busy called user is given an indication of the offered call. During the time that the call is offered, the called user may either:

• Ignore the offered call; or
• may attempt to make the necessary resources available (e.g. by releasing or placing on hold another call).

After the necessary resources become available at the called user, the call is completed as a normal incoming call.
The messages are in ASN.1 format.

Interested in more details about testing this protocol?

 

H.450.11

http://www.itu.int/ITU-T/. ITU-T H.450.11

Call Intrusion (SS-CI) is a supplementary service which, on request from the served user, enables the served user to establish communication with a busy called user (user B) by breaking into an established call between user B and a third user (user C).

On successful intrusion, user C is either connected in a held type of connection, connected in a conference type connection, connected in a silent monitoring type of connection, or user C is force-released.

Upon SS-CI request, if no specific option is requested, either the held type or the conference type of SS-CI is invoked depending on the implementation options supported within user B's endpoint.

As an option, the forced release type of SS-CI may be requested by a served user that is authorized appropriately, either within the initial call setup or after the held type or conference type of SS-CI have been invoked successfully.
As an option, the silent monitoring type of SS-CI may be requested by a served user that is authorized appropriately.
The messages are in ASN.1 format.

Interested in more details about testing this protocol?

 

H.450.12

http://www.itu.int/ITU-T/. ITU-T H.450.12

The ANF-CMN supplementary service is an additional network feature that enables the exchange of Common Information between ANF-CMN endpoints. This Common Information is a collection of miscellaneous information that relates to the endpoint or equipment at one end of a connection and includes one or more of the following:
Feature Identifiers, Feature Values, or Feature Controls. This information, when received by an ANF-CMN endpoint, can be used for any purpose, e.g. as the basis for indications to the local user or to another network or in order to filter feature requests.

A solicited and an unsolicited service can be offered to an ANF-CMN endpoint (which may be located at either end of a connection). The solicited service enables the ANF-CMN endpoint to request the Common Information from a peer ANF-CMN endpoint. The unsolicited service enables an ANF-CMN endpoint to supply Common Information to a peer ANF-CMN endpoint.

These services may be combined and are not mutually exclusive.

Interested in more details about testing this protocol?

 

H.261

H.261: http://www.cis.ohio-state.edu/htbin/rfc/rfc2032.html

H.263

RFC2190 (RTP): http://www.cis.ohio-state.edu/htbin/rfc/rfc2190.html
H.263: http://www.itu.int/itudoc/itu-t/rec/h/h263.html

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

Interested in more details about testing this protocol?

 

RAS

H.225: http://www.itu.int/itudoc/itu-t/rec/h/h225-0.html

Interested in more details about testing this protocol?

 

RTCP

RFC 1889: http://www.cis.ohio-state.edu/htbin/rfc/rfc1889.html

The RTP control protocol (RTCP) is based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the data packets. The underlying protocol must provide multiplexing of the data and control packets, for example using separate port numbers with UDP.

The format of the header is shown in the following illustration:

0	1	2	3	4	5	6	7	Octet
Version		P	Reception report count					1
Packet type								2
Length								3-4
RTCP structure

Version
Identifies the RTP version which is the same in RTCP packets as in RTP data packets. The version defined by this specification is two (2).

P
Padding. When set, this RTCP packet contains some additional padding octets at the end which are not part of the control information. The last octet of the padding is a count of how many padding octets should be ignored. Padding may be needed by some encryption algorithms with fixed block sizes. In a compound RTCP packet, padding should only be required on the last individual packet because the compound packet is encrypted as a whole.

Reception report count
The number of reception report blocks contained in this packet. A value of zero is valid. Packet type Contains the constant 200 to identify this as an RTCP SR packet.

Length
The length of this RTCP packet in 32-bit words minus one, including the header and any padding. (The offset of one makes zero a valid length and avoids a possible infinite loop in scanning a compound RTCP packet, while counting 32-bit words avoids a validity check for a multiple of 4.)

Enlarge	More Details

Interested in more details about testing this protocol?

 

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.

Sequence number

Mandatory message (primary)

Optional redundant message or optional FEC message

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

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