ITU-T H.225.0：包基多媒体通信系统的呼叫信令与媒体流封装

H.225.0

5星 · 超过95%的资源需积分: 25 177 浏览量更新于2024-07-31 收藏 3.19MB PDF 举报

ITU-T H.225.0是国际电信联盟（International Telecommunication Union, ITU）下属的电信标准化部门（Telecommunication Standardization Sector, ITU-T）发布的一系列推荐标准中的一个，主要关注基于包交换的多媒体通信系统中的呼叫信令协议和媒体流封装。这个标准定义了在IP网络上进行实时多媒体通信的基础架构和控制协议。 H.225.0标准是H.323协议族的一部分，H.323是广泛用于IP电话、视频会议和多媒体通信的一个框架。H.225.0规定了以下关键组件： 1. **呼叫信令**：这部分定义了如何建立、管理和终止多媒体会话。它包括RAS（Registration, Admission, Status）信令，用于设备注册、呼叫接入和状态信息的交换。同时，它还包含了H.245控制协议，用于协商和控制会话中的能力交换、开放/关闭逻辑通道以及传输控制命令。 2. **媒体流封装**：H.225.0定义了如何将音频、视频和其他数据流封装成适合在网络上传输的包。这通常涉及到使用Real-time Transport Protocol (RTP) 和 Real-time Control Protocol (RTCP) 来确保数据的实时传输和质量监控。 3. **信道分配**：标准涵盖了逻辑信道的分配和管理，使得不同的媒体类型（如音频、视频）可以在同一会话中并行传输。 4. **带宽管理**：H.225.0也涉及到了带宽控制，确保网络资源的有效利用，防止拥塞。 5. **QoS支持**：虽然H.225.0本身不直接处理服务质量（Quality of Service, QoS），但它与H.245和其他相关标准一起工作，以确保多媒体通信所需的网络条件得以满足。 6. **安全性**：H.225.0还涉及到安全方面的考虑，如加密和认证机制，以保护通信内容的安全性。 H.225.0标准与其他相关H系列标准（如H.245、H.26x等）协同工作，共同构成了多媒体通信的完整框架。H.245是控制协议，负责协商和控制会话的能力，而H.26x系列则定义了视频编码标准，如H.264和H.265，用于高效压缩视频数据。 ITU-T H.225.0是IP网络上多媒体通信的核心标准之一，对于实现可靠的、高质量的实时交互式通信至关重要。它为各种应用提供了基础，包括VoIP、视频会议、远程教育、在线协作等。

8 Rec. ITU-T H.245 (12/2009)

SE Session Exchange Message (used for encryption: refer to ITU-T Recs H.233 and

H.234)

SQCIF Sub QCIF

STD System Target Decoder (refer to ITU-T Rec. H.222.0 | ISO/IEC 13818-1)

VC ATM Virtual Channel

5 General

This Recommendation provides a number of different services, some of which are expected to be

applicable to all terminals that use it and some that are more specific to particular ones. Procedures

are defined to allow the exchange of audiovisual and data capabilities; to request the transmission of

a particular audiovisual and data mode; to manage the logical channels used to transport the

audiovisual and data information; to establish which terminal is the master terminal and which is

the slave terminal for the purposes of managing logical channels; to carry various control and

indication signals; to control the bit rate of individual logical channels and the whole multiplex; and

to measure the round-trip delay, from one terminal to the other and back. These procedures are

explained in more detail below.

Following this general introduction, there are clauses detailing the message syntax and semantics

and the procedures. The syntax has been defined using ASN.1 notation [40] and the semantics

define the meaning of syntax elements as well as providing syntactic constraints that are not

specified in the ASN.1 syntax. The procedures clause defines the protocols that use the messages

defined in the other clauses.

Although not all of the messages and procedures defined in this Recommendation will be applicable

to all terminals, no indication of such restrictions is given here. These restrictions are the

responsibility of the recommendations that use this Recommendation.

This Recommendation has been defined to be independent of the underlying transport mechanism,

but is intended to be used with a reliable transport layer, that is, one that provides guaranteed

delivery of correct data.

5.1 Master-slave determination

Conflicts may arise when two terminals involved in a call initiate similar events simultaneously and

only one such event is possible or desired, for example, when resources are available for only one

occurrence of the event. To resolve such conflicts, one terminal shall act as a master and the other

terminal shall act as a slave terminal. Rules specify how the master and slave terminal shall respond

at times of conflict.

The master-slave determination procedure allows terminals in a call to determine which terminal is

the master and which terminal is the slave. The terminal status may be re-determined at any time

during a call; however, a terminal may only initiate the master-slave determination process if no

procedure which depends upon its result is locally active.

5.2 Capability exchange

The capability exchange procedures are intended to ensure that the only multimedia signals to be

transmitted are those that can be received and treated appropriately by the receive terminal. This

requires that the capabilities of each terminal to receive and decode be known to the other terminal.

It is not necessary that a terminal understand or store all incoming capabilities; those that are not

understood, or cannot be used shall be ignored, and no fault shall be considered to have occurred.

When a capability is received which contains extensions not understood by the terminal, the

capability shall be accepted as if it did not contain the extensions.

Rec. ITU-T H.245 (12/2009) 9

The total capability of a terminal to receive and decode various signals is made known to the other

terminal by transmission of its capability set.

Receive capabilities describe the terminal's ability to receive and process incoming information

streams. Transmitters shall limit the content of their transmitted information to that which the

receiver has indicated it is capable of receiving. The absence of a receive capability indicates that

the terminal cannot receive (is a transmitter only).

Transmit capabilities describe the terminal's ability to transmit information streams. Transmit

capabilities serve to offer receivers a choice of possible modes of operation, so that the receiver

may request the mode which it prefers to receive. The absence of a transmit capability indicates that

the terminal is not offering a choice of preferred modes to the receiver (but it may still transmit

anything within the capability of the receiver).

These capability sets provide for more than one stream of a given medium type to be sent

simultaneously. For example, a terminal may declare its ability to receive (or send) two independent

H.262 video streams and two independent G.722 audio streams at the same time. Capability

messages have been defined to allow a terminal to indicate that it does not have fixed capabilities,

but that they depend on which other modes are being used simultaneously. For example, it is

possible to indicate that higher resolution video can be decoded when a simpler audio algorithm is

used; or that either two low resolution video sequences can be decoded or a single high resolution

one. It is also possible to indicate trade-offs between the capability to transmit and the capability to

receive.

Non-standard capabilities and control messages may be issued using the NonStandardParameter

structure. Note that while the meaning of non-standard messages is defined by individual

organizations, equipment built by any manufacturer may signal any non-standard message, if the

meaning is known.

Terminals may reissue capability sets at any time.

5.3 Logical channel signalling procedures

An acknowledged protocol is defined for the opening and closing of logical channels which carry

the audiovisual and data information. The aim of these procedures is to ensure that a terminal is

capable of receiving and decoding the data that will be transmitted on a logical channel at the time

the logical channel is opened rather than at the time the first data is transmitted on it; and to ensure

that the receive terminal is ready to receive and decode the data that will be transmitted on the

logical channel before that transmission starts. The OpenLogicalChannel message includes a

description of the data to be transported, for example, H.262 MP@ML at 6 Mbit/s. Logical channels

should only be opened when there is sufficient capability to receive data on all open logical

channels simultaneously.

A part of this protocol is concerned with the opening of bidirectional channels. To avoid conflicts

which may arise when two terminals initiate similar events simultaneously, one terminal is defined

as the master terminal, and the other as the slave terminal. A protocol is defined to establish which

terminal is the master and which is the slave. However, systems that use this Recommendation may

specify the procedure specified in this Recommendation or another means of determining which

terminal is the master and which is the slave.

5.4 Receive terminal close logical channel request

A logical channel is opened and closed from the transmitter side. A mechanism is defined which

allows a receive terminal to request the closure of an incoming logical channel. The transmit

terminal may accept or reject the logical channel closure request. A terminal may, for example, use

these procedures to request the closure of an incoming logical channel which, for whatever reason,

10 Rec. ITU-T H.245 (12/2009)

cannot be decoded. These procedures may also be used to request the closure of a bidirectional

logical channel by the terminal that did not open the channel.

5.5 H.223 multiplex table entry modification

The H.223 multiplex table associates each octet within an H.223 MUX message with a particular

logical channel number. The H.223 multiplex table may have up to 15 entries. A mechanism is

provided that allows the transmit terminal to specify and inform the receiver of new H.223

multiplex table entries. A receive terminal may also request the retransmission of a multiplex table

entry.

5.6 Audiovisual and data mode request

When the capability exchange protocol has been completed, both terminals will be aware of each

other's capability to transmit and receive as specified in the capability descriptors that have been

exchanged. It is not mandatory for a terminal to declare all its capabilities; it only needs to declare

those that it wishes to be used.

A terminal may indicate its capabilities to transmit. A terminal that receives transmission

capabilities from the remote terminal may request a particular mode to be transmitted to it. A

terminal indicates that it does not want its transmission mode to be controlled by the remote

terminal by sending no transmission capabilities.

5.7 Round-trip delay determination

It may be useful in some applications to have knowledge of the round-trip delay between a transmit

terminal and a receive terminal. A mechanism is provided to measure this round-trip delay. This

mechanism may also be useful as a means to detect whether the remote terminal is still functioning.

5.8 Maintenance loops

Procedures are specified to establish maintenance loops. It is possible to specify the loop of a single

logical channel either as a digital loop or decoded loop, and the loop of the whole multiplex.

5.9 Commands and indications

Commands and indications are provided for various purposes: video/audio active/inactive signals to

inform the user; fast update request for source switching in multipoint applications are some

examples. Neither commands nor indications elicit response messages from the remote terminal.

Commands force an action at the remote terminal whilst indications merely provide information and

do not force any action.

A command is defined to allow the bit rate of logical channels and the whole multiplex to be

controlled from the remote terminal. This has a number of purposes: interworking with terminals

using multiplexes in which only a finite number of bit rates are available; multipoint applications

where the rates from different sources should be matched; and flow control in congested networks.

剩余345页未读，继续阅读

amdfansheng2

粉丝: 0
资源: 2

ITU-T H.225.0：包基多媒体通信系统的呼叫信令与媒体流封装

H.225.0 协议标准

ITU T H.225包括225RSA信令部分和H245建议书(五个文档中文及对应英文)

H225 h245 协议简介

ITU-T H.225.0：2006版 - 基于分组的多媒体通信呼叫信令与媒体流

itu-t h323协议 中文版本

网络语音-H.323技术介绍-D.docx

IP语音解决方案H.323技术白皮书--H3C.pdf

网络语音-H.323技术介绍.pdf

行业分类-设备装置-H.323应用过程中获取媒体通道地址的实现方法.zip

H.225音视频协议详解：多媒体通信基础设施标准

最新资源

itu-t h323协议中文版本