H.323 Protocols Suite

 
This the following H.323 protocols are described here:
DVB Digital Video Broadcasting
H.225 Covers narrow-band visual telephone services
H.225 Annex G  
H.225E  
H.235 Security and authentication
H.323SET  
H.245 Negotiates channel usage and capabilities
H.450.1 Series defines Supplementary Services for H.323
H.450.2 Call Transfer supplementary service for H.323
H.450.3 Call diversion supplementary service for H.323
H.450.4 Call Hold supplementary service
H.450.5 Call Park supplementary service
H.450.6 Call Waiting supplementary service
H.450.7 Message Waiting Indication supplementary service
H.450.8 Calling Party Name Presentation supplementary service
H.450.9 Completion of Calls to Busy Subscribers supplementary service
H.450.10 Call Offer supplementary service
H.450.11 Call Intrusion supplementary service
H.450.12 ANF-CMN supplementary service
H.261 Video stream for transport using the real-time transport
H.263 Bitstream in the Real-time Transport Protocol
Q.931 manages call setup and termination
RAS Manages registration, admission, status
RTCP RTP Control protocol
RTP Real-Time Transport
T.38 IP-based fax service maps
T.125 Multipoint Communication Service Protocol (MCS).

The H.323 standard provides a foundation for audio, video, and data communications across IP-based networks, including the Internet. H.323 is an umbrella recommendation from the International Telecommunications Union (ITU) that sets standards for multimedia communications over Local Area Networks (LANs) that do not provide a guaranteed Quality of Service (QoS). These networks dominate today’s corporate desktops and include packet-switched TCP/IP and IPX over Ethernet, Fast Ethernet and Token Ring network technologies. Therefore, the H.323 standards are important building blocks for a broad new range of collaborative, LAN-based applications for multimedia communications. It includes parts of H.225.0 - RAS, Q.931, H.245 RTP/RTCP and audio/video codecs, such as the audio codecs (G.711, G.723.1, G.728, etc.) and video codecs (H.261, H.263) that compress and decompress media streams.

Media streams are transported on RTP/RTCP. RTP carries the actual media and RTCP carries status and control information. The signalling is transported reliably over TCP. The following protocols deal with signalling:

To see how to generate thousands of H.323 calls and stress test an H.323
network

 

Typical H.323 procedures

Interested in more information on how to decode and analyze H.323 protocols?

 

The H.323 suite is illustrated here in relation to the OSI model:
Click the protocols on the map to see more details.

cellular protocols

 

DVB

ETS 800 300

Certain implementations suitable for Digital Video Broadcasting (DVB) broadcasting systems are supported by CATV infrastructures. Specifically, implementations of the Return Channel for interactive services are supported by CATV.
DVB involves a standard link.

The format of the DVB packet is shown in the following illustration:

Mpeg Header (4) Upstream Marker (3) Slot Number
(2)
MAC Flag Control (3)
MAC Flags
(26)

Ext. Flags
(26)

MAC Message
(40)
MAC Message
(40)
MAC Message
(40)
Rsrvc.
(40)
DVB packet structure

Mpeg Header
4 byte Mpeg-2 transport stream header as defined in ISO 13818-1 with a specific PID designated for MAC messages. The value of this PID is 0 x 1C. The transport scrambling control field of the MPEG header is set to 00.

Upstream Marker
24 bit field, 3 byte marker that provides upstream QPSK synchronization information. At least one packet with synchronization information must be sent in every period of 3 msec. The definition of the field is as follows:

Bit 0: Upstream Marker Enable - When this field has the value ‘1,’ the slot marker pointer is valid. When this field has the value ‘0,’ the slot marker pointer is not valid.
Bits 1 - 3: MAC Message Framing - Bit 1 relates to the first MAC message slot within the MPEG frame, bit 2 to the second MAC message within the MPEG frame, and bit 3 to the last MAC message within the MPEG frame. Possible values:
0 - A MAC message terminates in this slot.
1 - A MAC message continues from this slot into the next, or the slot is unused. If the slot is unused, the first two bytes of the slot are
0 x 0000.
Bits 4 - 7: Reserved
Bits 8 - 23: Upstream Slot Marker Pointer - A 16 bit unsigned integer which indicates the number of downstream “symbol” clocks between the next Sync byte and the next 3 msec time marker. Bit 23 is considered the most significant bit of this field.

Slot Number4
A 16 bit field which is defined as follows:

Bit 0: Slot Position Register Enable (msb) - When this field has the value ‘1,’ the slot position register is valid. When this field has the value ‘0,’ the slot position register is not valid.
Bits 1-3: Reserved
Bit 4: Set to the value ‘1.’ This bit is equivalent to M12 in the case of OOB downstream.
Bit 5: Odd Parity - This bit provides odd parity for upstream slot position register. It is equivalent to M11 in the case of OOB downstream.
Bits 6 - 15: Upstream Slot Position Register - 10 bit counter which counts from 0 to n with bit 6 the msb. These bits are equivalent to M1 - M10 in the case of OOB downstream.

MAC Flag Control
24 bit field (b0 (msb), b1, b2 . . . b23) that provides control information used in conjunction with the ‘MAC Flags’ and ‘Extension Flags’ fields. The definition of the MAC Flag Control field is as follows:

  • b0 - b2 - Channel 0 control field.
  • b3 - b5 - Channel 1 control field.
  • b6 - b8 - Channel 2 control field.
  • b9 - b11 - Channel 3 control field.
  • b12 - b14 - Channel 4 control field.
  • b15 - b17 - Channel 5 control field.
  • b18 - b20 - Channel 6 control field.
  • b21 - b23 - Channel 7 control field.

MAC Flags
26 byte field containing 8 slot configuration fields (24 bits each) which contain slot configuration information for the related upstream channels followed by two reserved bytes. The first 3 bytes correspond to MAC Flag Set 1, the second 3 bytes to MAC Flag Set 2, etc.

Ext. Flags
A 26 byte field used when one or more 3.088 Mbit/s or 6.176 Mbit/s upstream QPSK links are used. The definition of the Extension Flags field is identical to the definition of the MAC Flags field (above). The Extension Flags field contains the MAC Flags from 9 to 16.

MAC Message
The MAC Message field contains a 40 byte message in hexadecimal code.

Reserved Field C (Rsrvc.)
Reserved Field C is a 4 byte field reserved for future use.

Interested in more details about testing this protocol?

 

H.225

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

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

 

Interested in more details about testing this protocol?

 

H.225 Annex G

http://www.itu.int/ITU-T/.Recommendation H.225.0 (09/99).

The overall H.323 network consists of smaller subsets of equipment organized in a manner such as by administrative domains. Because of the potentially large numbers of H.323 equipment existing in H.323 networks, an efficient protocol is needed to allow calls to be completed between administrative domains. The most elementary example is for a user (an endpoint) in one administrative domain to reach a user (an endpoint) serviced by another administrative domain. While the H.225.0 RAS protocol can provide many of the needs of communication between administrative domains, it is neither complete nor efficient enough for this purpose.

This annex describes methods to allow address resolution, access authorization and usage reporting between administrative domains in H.323 systems for the purpose of completing calls between the administrative domains. An administrative domain exposes itself to other administrative domains through a type of logical element known as a border element. A border element may be collocated with any other entity (for example, with a gatekeeper). Annex G does not require an administrative domain to reveal details about its organization or architecture. Annex G does not mandate a specific system architecture within an administrative domain. Furthermore, Annex G supports the use of any call model (gatekeeper routed versus direct endpoint).

The general procedure is for border elements to exchange information regarding the addresses each administrative domain can resolve. Addresses can be specified in a general manner or in an increasingly specific manner. Additional information allows elements within an administrative domain to determine the most appropriate administrative domain to serve as the destination for the call. Border elements may control access to their exposed addresses, and require reports on the usage made during calls to those addresses.
Messages are in ASN1 format.

Sequence Number
Each request or update message contains a unique sequence number.

ReplyAddress
The address to which to send the reply to a request message.

Version
The protocol version.

Hopcount
The number of border elements through which this message may propagate.

IntegrityCheckValue
Provides improved message integrity/message authentication.

Tokens
Data which may be required to allow the operation.

CryptoTokens
Encrypted tokens
.

Interested in more details about testing this protocol?

 

H.225E

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

This annex describes a packetization format and a set of procedures (some of which are optional) that can be used to implement UDP and TCP based protocols. The first part of this annex describes the signalling framework and wire-protocol, and subsequent clauses detail specific use cases. The only profile currently specified in this revision is for transporting H.225.0 Q.931-like messages.

This annex is designed to operate in engineered networks and use the security services provided by H.323 (e.g. H.235, IP-SEC).

The protocol header structure appears as follows:

1

2

3

4

5

6

7

8

Octet

Version

6

M

H

L

A

1

SEQNUM

2-4

Payload

5-n

Structure when the L-bit is cleared
 

1

2

3

4

5

6

7

8

Octet

Version

6

M

H

L

A

1

SEQNUM

2-4

Payload Count

5

Length

6-8

Payloads

9-n

Structure when the L-bit is set

 

Version

The version number (Should be 0)

6

The IP version (4 or 6)

M

Whether the PDU uses multicast, or the PDU was unicast

H

Whether the message will result in a reply

L

The length indicator indicates whether there are an additional 4 octets that contain the number of payloads and the total length

A

If an Ack is requested for this PDU

SEQNUM

The sequence number of this PDU

PAYLOAD COUNT

The number of payloads

Length

Total length in OCTETs of all payloads (excluding header)

T

The payload identification type

S

The presence of a Session field

A

The presence of a Source/Destination Address field

Interested in more details about testing this protocol?

 

H.235

H.235: http://www.itu.int/itudoc/itu-t/rec/h/h235.html

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

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:

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

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

0
1
2
3
4
5
6
7
Octet
SBIT
EBIT
I
V
1
GOBN
  MBAP 
2
MBAP
QUANT
HMVD   
3
 HMVD
VMVD
4
H.261 header structure
 

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

Interested in more details about testing this protocol?

 

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

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:

4 bytes
RTP header
 H.263 payload header
H.263 bitstream
RTP H.263 video packet

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:

1
2
3
4
5
6
7
8
Octet
F
P
SBIT
EBIT
1
SRC
I
U
S
A
R
2
R (cont.)
DBQ
TRB 
3
TRB 
4
H.263 mode A payload header structure
 

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:

1
2
3
4
5
6
7
8
Octet
F
P
SBIT
EBIT
1
SRC
QUANT
2
GOBN
MBA
3
MBA (cont.)
R
4
I
U
S
A
HMV1 
5
HMV1 (cont.)
VMV1
6
VMV1 (cont.)
HMV2
7
HMV2
VMV2
8

H.263 mode B payload header structure

 

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:

1
2
3
4
5
6
7
8
Octet
F
P
SBIT
EBIT
1
SRC
QUANT
2
GOBN
MBA
3
MBA (cont.)
R
4
I
U
S
A
HMV1 
5
HMV1 (cont.)
VMV1
6
VMV1 (cont.)
HMV2
7
HMV2
VMV2
8

RR

9
RR (cont.)
DBQ
DBQ
10
TR
11

H.263 mode C payload header structure

 

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

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.

Important RAS Messages

Message   Function
RegistrationRequest (RRQ) Request from a terminal or gateway to register with a gatekeeper. Gatekeeper either confirms or rejects (RCF or RRJ).
AdmissionRequest (ARQ) Request for access to packet network from terminal to gatekeeper. Gatekeeper either confirms or rejects (ACF or ARJ).
BandwidthRequest (BRQ) Request for changed bandwidth allocation, from terminal to gatekeeper. Gatekeeper either confirms or rejects (BCF or BRJ).
DisengageRequest (DRQ) If sent from endpoint to gatekeeper, DRQ informs gatekeeper that endpoint is being dropped; if sent from gatekeeper to endpoint, DRQ forces call to be dropped. Gatekeeper either confirms or rejects (DCF or DRJ). If DRQ sent by gatekeeper, endpoint must reply with DCF.
InfoRequest (IRQ) Request for status information from gatekeeper to terminal.
InfoRequestResponse (IRR) Response to IRQ. May be sent unsolicited by terminal to gatekeeper at predetermined intervals.
RAS timers and Request in Progress (RIP) Recommended default timeout values for response to RAS messages and subsequent retry counts if response is not received.

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

Interested in more details about testing this protocol?

 

RTP

Interested in more information on how to analyze RTP for jitter, lost packets and more?

The Real-time Transport (RTP) Protocol provides end-to-end network transport functions suitable for applications transmitting real-time data such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level transla tors and mixers.

The format of the RTP Fixed Header Fields is shown in the following illustration:

0
1
2
3
4
5
6
7
Octet
V
P
X
CSRC count
1
M
Payload type
2
Sequence number
3
4
Timestamp
5
6
7
8
SSRC
9
10
11
12
CSRC
0-60
octets

RTP structure

 

V
Version. Identifies the RTP version.

P
Padding. When set, the packet contains one or more additional padding octets at the end which are not part of the payload.

X
Extension bit. When set, the fixed header is followed by exactly one header extension, with a defined format.

CSRC count
Contains the number of CSRC identifiers that follow the fixed header.

M
Marker. The interpretation of the marker is defined by a profile. It is intended to allow significant events such as frame boundaries to be marked in the packet stream.

Payload type
Identifies the format of the RTP payload and determines its interpretation by the application. A profile specifies a default static mapping of payload type codes to payload formats. Additional payload type codes may be defined dynamically through non-RTP means.

Sequence number
Increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore packet sequence.

Timestamp
Reflects the sampling instant of the first octet in the RTP data packet. The sampling instant must be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations. The resolution of the clock must be sufficient for the desired synchronization accuracy and for measuring packet arrival jitter (one tick per video frame is typically not sufficient).

SSRC
Identifies the synchronization source. This identifier is chosen randomly, with the intent that no two synchronization sources within the same RTP session will have the same SSRC identifier.

CSRC
Contributing source identifiers list. Identifies the contributing sources for the payload contained in this packet.

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.

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.

Interested in more details about testing this protocol?

 

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.

Interested in more details about testing this protocol?

 

1 2 3

VoIP Protocols Information
DVB | H.225 | H.225 Annex G | H.235 | H.245 | H.450.1 | H.450.2 | H.450.3 | H.450.4 | H.450.5 | H.450.6 | H.450.7 | H.450.8 | H.450.9 | H.450.10 | H.450.11 | H.450.12 | H.261 | H.263 | Megaco (H.248) | MGCP | RAS | RTCP | RTP | RVP over IP | SAPv2 | SDP | SIP | SGCP | Skinny | T.38 | T.125 | VoIP Reference Page

 
Additional Information