H.323 Protocols Suite
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 proceduresInterested 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.
ETS 800 300Certain 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 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:
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.
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:
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: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?
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:
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.
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:
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:
Important 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? 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.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.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.
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:
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:
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:
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:
P P bit specifies the optional PB-frames mode. 0 – normal I or P frame. 1 – PB-frames. When F=1, P also indicates modes as follows: 0 – mode B. 1 – mode C.
SBIT Start bit position specifies number of most significant bits that are ignored in the first data byte.
EBIT End bit position specifies number of least significant bits that are ignored in the last data byte.
SRC Source format (bit 6,7 and 8 in PTYPE in the standard H.263 compressed bitstream) specifies the resolution of the current picture.
I Picture coding type (bit 9 in PTYPE in the standard H.263 compressed bitstream). 0 – intra-coded. 1 – inter-coded.
U Set to 1 if the Unrestricted Motion Vector option (bit 10 in PTYPE in the standard H.263 compressed bitstream) was set to 1 in the current picture header, otherwise 0.
S Set to 1 if the Syntax-based Arithmetic Coding option (bit 11 in PTYPE in the standard H.263 compressed bitstream) was set to 1 for the current picture header, otherwise 0.
A Set to 1 if the Advanced Prediction option (bit 12 in PTYPE in the standard H.263 compressed bitstream) was set to 1 for current picture header, otherwise 0.
R Reserved, set to zero.
DBQ Differential quantization parameter used to calculate quantizer for the B frame based on quantizer for the P frame, when PB-frames option is used. The value should be the same as DBQUANT in the standard H.263 compressed bitstream. Set to zero if PB-frames option is not used.
TRB Temporal Reference for the B frame in the standard H.263 compressed bitstream. Set to zero if PB-frames option is not used.
TR Temporal Reference for the P frame in the standard H.263 compressed bitstream. Set to zero if the PB-frames option is not used.
The format of the header for mode B is shown here:
F, P, SBIT, EBIT, SRC, I, U, S and A are defined the same as in mode A.
QUANT Quantization value for the first MB coded at the starting of the packet. Set to 0 if the packet begins with a GOB header.
GOBN GOB number in effect at the start of the packet. GOB number is specified differently for different resolutions.
MBA The address within the GOB of the first MB in the packet, counting from zero in scan order. For example, the third MB in any GOB is given MBA=2.
R Reserved, set to zero.
HMV1, VMV1 Horizontal and vertical motion vector predictors for the first MB in this packet. When four motion vectors are used for the current MB with advanced prediction option, they are the motion vector predictors for block number 1 in the MB. Each 7-bit field encodes a motion vector predictor in half pixel resolution as a 2’s complement number.
HMV2, VMV2 Horizontal and vertical motion vector predictors for block number 3 in the first MB in this packet when four motion vectors are used with the advanced prediction option. This is needed because block number 3 in the MB needs different motion vector predictors from other blocks in the MB. These two fields are not used when the MB only has one motion vector. Each 7 bits field encodes a motion vector predictor in half pixel resolution as a 2’s complement number.
The format of the header for mode C is shown here:
F, P, SBIT, EBIT, SRC, I, U, S, A, DBQ, TRB and TR are defined the same as in mode A. QUANT, GOBN, MBA, HMV1, VMV1, HMV2, VNV2 are defined the same as in mode B.RR Reserved, set to zero (19 bits).
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
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:
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:
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.
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 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 The sequence number is used to identify the sequencing in the payload.
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).
Procedures may be:
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.
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