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