基于MPEG-4和RTP的网络视频监控系统研究.rtf

《基于MPEG-4和RTP的网络视频监控系统研究.rtf》由会员分享，可在线阅读，更多相关《基于MPEG-4和RTP的网络视频监控系统研究.rtf（16页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、基于 MPEG-4 和 RTP 的网络视频监控系统研究.txt 我们用一只眼睛看见现实的灰墙，却用另一只眼睛勇敢飞翔，接近梦想。男人喜欢听话的女人，但男人若是喜欢一个女人，就会不知不觉听她的话。基于 MPEG-4 和 RTP 的网络视频监控系统研究文/北京邮电大学通信网络综合技术研究所 龚猷龙 刘勇摘 要：随着计算机、网络及多媒体通信技术的发展，视频监控在业界得到了广泛的应用，许多先进的技术被逐渐引入视频监控系统。本文采用了递进的方式，先介绍了 IP 网络视频监控系统的组成及其关键技术，接着阐述了 MPEG-4 视频流的 RTP 分组净荷格式。最后，在视频流的 RTP 传输中，着重分析了 MP

2、EG-4 视频流的封装格式，并给出相应的实现方法。关键词：视频监控，MPEG-4，RTP，视频流封装一、引言随着计算机、网络及通信技术的快速发展和成熟，视频监控系统从模拟视频监控系统逐渐转向以数字化和网络化为特色的网络数字视频监控系统。早期的模拟视频监控系统主要应用于闭路电视的监控，监控的范围仅限于本地网络。近十多年来，市场对视频监控业务的需求量越来越大，特别是需求形式越来越广泛。计算机系统处理能力的提升，图像压缩技术的更加完善，以及互联网应用的蓬勃兴起，这些技术的进步为视频监控的发展提供了保证，给视频监控系统带来了巨大商机。受到市场和技术的驱动，视频监控的应用领域和应用的灵活性也已经远远超出

3、传统的安防监控所定义的范畴，其应用面得到了大大地推广，逐步渗透到许多对视频业务有极大需求的新兴行业市场。如银行监控、交通监控、医疗监护、通信机房监控等系统，给人们的生活和工作带来了极大的便利。视频监控系统既可以采用专线组网，也可用 IP 方式组网。采用专线组网的视频监控系统具有带宽充足、图像质量好、易维护等特点，但是费用高。TCP/IP 网络是面向全球用户，资源共享是 TCP/IP 最大的优点。TCP/IP 是目前最流行采用的互联网技术，而且使用价格低廉，满足大众化的需求，其应用前景十分广阔。因此，采用 IP 组网是视频监控系统朝网络化发展的趋势。下文主要介绍 IP 网络视频监控系统的特点及其

4、采用的关键技术。二、IP 网络监控系统结构IP 网络视频监控系统主要由视频监控端、服务器端和客户端组成，如图 1 所示。其中视频监控端包括若干台摄像机、一台矩阵切换器和一台 MPEG-4 编码器；服务器端由一个主控中心组成，包括用于业务平台管理和调度的网络服务器，MPEG-4 解码器和显示设备；客户端包括一个接入 IP 网的集线器和各个 PC 机终端。各部分通过以太网相连接。图 1 IP 网络监控系统从网络视频监控系统可以看出，系统中主要存在两种数据流：视频监控端向客户端发送的媒体流和客户端向视频监控端发送的控制信息流。系统的数据流程如图 2 所示。?图 2 系统数据流程图传输两种数据流所采用

5、的协议是不一样的。控制信息流对服务器平台业务管理、客户端与视频端的接入、调度及解码显示等都是十分重要的，可见在控制信息流的传输过程中不允许有丢包，因此采用面向连接、可靠传输的 TCP 协议传输控制信息。然而 TCP 传输需要的网络开销较大，通过降低有效性来换取传输的可靠性，不能达到实时传输媒体流的目的。UDP协议是面向无连接、不可靠传输的控制协议，传输之前不需要先建立连接，在传输时延及带宽利用率方面都要强于 TCP，正好满足了媒体流实时性的特点，通常采用 UDP 作为媒体流的传输协议。不过，采用 UDP 传输媒体流同样存在不可靠性的问题：UDP 数据包没有编号，无法提供差错控制，也不保证包不丢

6、失，更不能加载媒体流的时间信息。导致在客户端显示的视频图像存在延时和抖动，在一定程度上仍然不能达到实时传输的效果。表 1 给出的是中国电信有关 IP 承载网络端到端通信质量要求，可供参考。表 1 网络通信质量要求丢包率上限网络延时上限延时抖动上限 1/1000150ms50ms为了弥补 UDP 协议存在的缺点，使 IP 网络具有提供媒体流实时传输的能力，IP 网络视频监控系统采用由 IETF 制定的实时传输协议 RTP。RTP 由两个相关协议组成：实时传输协议 RTP 和实时传输控制协议 RTCP。视频压缩编解码技术是视频监控系统的核心技术。视频监控端采集的原始数据量很大，不适合直接在带宽受限

7、的网络中传输，需要先对原始数据进行压缩。视频压缩标准主要有两个系列，一个是由 ITU-T 制定的 H.26x 系列，另一个是由 ISO 制定的 MPEG-x 系列。目前比较看好的国际标准是 H.264 和 MPEG-4。综合考虑算法的复杂度、性能、市场占有率及今后的发展等因素，选择 MPEG-4 作为视频监控系统的压缩编码框架。三、视频监控系统的关键技术1MPEG-4 压缩标准 MPEG-4 标准采用的仍然是以前标准(H.261/3 和 MPEG-1/2)的基本编码框架，即典型的三步：预测编码、变换量化和熵编码。新的压缩编码标准都是基于优化的思想进行设计的，将先前标准中的某些技术加以改进，例如

8、在原来的基础上提出 1/4 和 1/8 像素精度的运动补偿技术，使得预测编码的性能大大提高，或加入以前标准中没有的新技术。与 MPEG-1 和MPEG-2 有很大的不同，MPEG-4 标准不仅仅给出了具体压缩算法，它是针对数字电视、交互式多媒体应用、视频监控等整合及压缩技术的需要而制定的。MPEG-4 将多种多媒体应用集成在一个完整的框架里，为不同的应用提供相应地档次和级别。MPEG-4 标准中最大的特点是：采用了基于对象的编码理念。传统的视频编码方法依照信源编码理论的框架，利用输入信号的随机特性达到压缩的目的，而并没有考虑信息获取者的主观意义和主观特性，还有事件本身的具体含义、重要性及后果等

9、。MPEG-4 标准中引用了视频对象的概念，打破了过去以宏块为单位编码的限制，其目的在于采用现代图像编码方法，利用人眼视觉特性，抓住图像信息传输的本质，从轮廓、纹理的思路出发，支持基于视频内容的交互功能。以上这些都是根据人眼感兴趣的一些特性提出来的。视频序列中每一帧由不同的场景组成，这些场景可以根据人的主观性进行划分，每一个场景可看成是一个 VOP，而同一对象连续的 VOP 称为视频对象 VO。VO 可以是视频序列中的人物或具体的景物，也可以是计算机生成的二维或三维图形。视频监控系统中，视频监控端主要采集的是自然景物的图片，因此这里只考虑 MPEG-4 中自然视频序列的编码档次。MPEG-4是

10、以 VOP 为单位进行编解码，编解码过程如图 3 所示。图 3 MPEG-4 编解码基本过程 编码器包含三个主要部分，形状编码、运动信息编码及纹理编码。(1)?形状编码VOP 的形状信息有两类：二值形状信息和灰度形状信息。二值形状信息用 0，1 来表示 VOP的形状；灰度形状信息用 0255 之间的数值表示 VOP 内各像素的透明度。目前的标准中采用矩阵的形式来表示二值或灰度形状信息，称之为位图(或 alpha 平面)。试验表明，位图表示法具有较高的编码效率和较低的运算复杂度。(2)?运动信息编码VOP 的编码有三种模式，即帧内编码模式(I-VOP)，帧间预测编码模式(P-VOP)，帧间双向预

11、测编码模式(B-VOP)。为了适应任意形状的 VOP，MPEG-4 引入了图像填充技术和多边形匹配技术。对于标准宏块的运动估计和补偿，可采用传统的基于块的方法。而对于 VOP 边界的轮廓宏块，则要采用图像填充技术，再用多边形匹配技术进行运动估计/补偿。(3)?纹理编码一个视频平面的纹理信息可以表示为亮度 Y 和两个色度成分 Cr、Cb。在帧内情况下，纹理信息直接包含亮度和色度成分，在运动补偿的情况下，纹理信息表示经过运动补偿后的残差。2RTP 协议 RTP 是由 IETF 音视频工作组制定的实时传输协议，专门用于交互式语音、视频传输等实时多媒体应用。RTP 可以在点对点或点对多点的传输情况下工

12、作，而且通常使用 UDP 来传送数据。当应用程序开始一个 RTP 会话时，同时还要开启 RTCP 协议，因为 RTP 协议并不能提供差错控制和保证的网络的 QoS，需要和 RTCP 配合使用。此时的会话将使用两个端口：一个给 RTP，另一个给 RTCP。RTP 协议的设计目的是提供实时数据传输中的时间戳信息及各数据流的同步功能。RTP提供序列号以恢复数据包的顺序，实现丢包检测，为实时传输提供网络拥塞等信息；提供时间戳用于媒体同步，使接收端按正确的速率回放数据；提供同步源标志使接收端有可能获得有关发送方的信息。RTCP 的主要功能是提供有关 QoS 的信息反馈。网络终端系统可根据这些反馈信息来调

13、整数据的发送速率。RTCP 包共有五种类型：发送端报告(SR)、接收端报告(RR)、源描述(SDES)、BYE 和 APP。其中，SR 用来描述发送端的发送和接收统计数据；RR 用来描述接收端的接收统计数据。这些统计数据包括发送包数、发送字节数、累计丢包数、已收报文的最大序列号、达到时间间隔抖动等。实时传输协议 RTP 和传输控制协议 RTCP 一起提供流量控制和拥塞控制服务。在 RTP 会话期间，各参与者周期性地传输 RTCP 包。服务器利用RTCP 包中所包含的信息动态地改变传输速率，甚至改变有效载荷类型。因此，RTP 用来传送实时多媒体数据信息，而 RTCP 用来传送控制信息。四、视频监

14、控系统的视频流传输视频监控端采集的视频数据，先被送入 MPEG-4 编码器进行压缩，生成 MPEG-4 视频流，然后将此视频流打包成 RTP 数据包再传输。以下将详细分析这个过程。1RTP 打包传输视频流通过 RTP 打包传输，RTP 数据包由 RTP 包头和不定长的连续媒体数据载荷组成。RTP 数据包如图 4 所示，其中的载荷是 MPEG-4 视频流。4 RTP 数据包格式 几个关键字段的含义前面已给出，RTP 包头字段的含义与以前的 IP 数据包头的类似，这里不再详细说明。其中，MPEG-4 Visual stream 表示 MPEG-4 的视频流，被称为 RTP 分组净荷(payload

15、)。采用 RTP 协议发送 MPEG-4 码流的好处：(1)可以将 MPEG-4 码流和其他的 RTP 净荷相同步；(2)可以通过 RTCP 监视 MPEG-4 的传送性能；(3)使用 RTP 混合器能将从多个终端系统接收到的 MPEG-4 和其他实时数据流复合成一系列合并的码流；(4)通过使用 RTP 转换器实现数据类型的转换。2MPEG-4 视频流格式 视频监控系统中，视频压缩编码采用的是 MPEG-4 标准。而 MPEG-4 标准定义了Profile&Level 来适应不同的应用。Profile 定义了一个码流可以采用哪些技术，Level 则规定了复杂度，譬如支持多大的图像格式和大小，需

16、要的缓存量。先进简单档次(Advanced Simple Profile)是为了适应因特网上流媒体应用的需求而新增加的，在简单档次的基础上改善了压缩性能，而且支持隔行扫描视频编码。本文讨论的视频监控系统采用的是 MPEG-4 标准中的先进简单档次(ASP)。（1）视频流的分片规则由于 IP 网络中传输的分组大小受限制，加上 MPEG-4 视频流是以 VOP 为单位编码的特点，传输 MPEG-4 视频流时，需要先将视频流加上包头信息，进行 RTP 打包封装。MPEG-4 视频流的打包要遵循两个原则：为了提高效率和充分利用 MPEG-4 的编码特性，以 VOP 为单位进行打包；考虑 IP 分组网络

17、传送包长的限制，打包的长度 L 小于最大传输单元(MTU)。基于以上的两个原则，相应给出码流的分片规则如下：原则上是：一个 VOP 包单独放入单个 RTP 包中。但是，一个 VOP 在一个 RTP 包中放不下的情况下，此时要考虑将 VOP 进行分片，分别放入多个 RTP 包，此时须把 VOP 头部信息复制到每个 RTP 包，以去除包间的相关性，达到丢包的鲁棒性；当一个 VOP 太小时，此时为了提高 RTP 传输的有效性(减少包数和降低开销)，需要将多个VOP 放入一个 RTP 包中，这些 VOP 应该按照解码顺序放入 RTP 中。但是，即使最后一个包中仍有剩余空间，也不能将另一 VOP 中的宏

18、块放入此包中；同属于一个 VOP 的控制信息和数据信息必须同时出现在一个 RTP 包中；一个 VOP 头不能分开放在两个或两个以上的 RTP 包中；当将多个视频包串联到一个 RTP 包中时，VOP 头不应放到 RTP 负载的中间。（2）视频流的封装MPEG-4 视频流是 RTP 数据包中的载荷，给 MPEG-4 视频流打包的目的是为了适应网络的传输，让解码端能够恢复 MPEG-4 数据流并进行回放。依照 MPEG-4 视频流的分片规则，可以将包格式简单的分为帧头配置信息和基本流信息。每个 VO 可对应多个视频对象层(VOL)，而且每个 VOL 可能属于多个 VO。图 5 是 MPEG-4 视频

19、流封装结构。图 5 视频流封装结构 从图中可以看出，传输视频对象每一层的基本流信息时，都需要将这个基本流的属性同时传输。比如，传输 VO1 Layer1 的基本流信息，需要将所属的视频序列头、视频对象头和视频对象层头一同传输。而且传输 VO1 Layer2 的基本流信息时，也需要将这些属性再次传输。既可以保证基本流信息的完整性，又具有鲁棒性。MPEG-4 视频流由若干个视频对象序列(VS)组成。VS 的每一帧可分割为一些任意形状的VO，一个视频对象 VO 又是由同一 VOP 的连续系列构成。在具体的实现中，需用分层的方式组织各个头信息。图 6 给出了视频流的分层语法结构。图 6 MPEG-4

20、视频流分层结构上图中每个模块代表一个函数实现，模块的名字取于对应函数的首写字母组合。对应关系及功能如下：VS：VisualObjectSequence()，表示完整的 MPEG-4 的场景，给出了档次和级别信息；VO：VisualObject()，表示一个视频对象对应着场景中的一个特定对象；VOL：VideoObjectLayer()，给出了当前视频流的一些特性；GOP：Group_of_VideoObjectPlane()，提供码流的随机访问点；VOP：VideoObjectPlane()，包含了视频对象的运动参数、形状信息和纹理信息；MST：Motion_shape_texture()，给

21、出了运动参数、形状信息和纹理信息；VPH：Video_packet_header()，视频包头信息；DPMST：data_partitioned_motion_shape_texture()，运动信息和纹理数据分开编码；CMST：combined_motion_shape_texture()，运动信息和纹理数据联合编码；MB：Macroblock()，给出了宏块数据，包括运动矢量和纹理信息。从以上的实现函数可以看到，在加入一系列头信息的情况下，整个视频流是以 VOP 对单位封装传输。而每个 VOP 的编码都是以宏块为单位，有关宏块级的数据流分析就不在加以描述了。MPEG-4 视频流出现在 RT

22、P 数据包的载荷部分，RTP 数据包的结构比较清晰，因此 RTP 的组包过程比较容易实现。然而，MPEG-4 视频流的分析过程非常复杂。MPEG-4 视频标准一共定义了 19 种编码档次，其中用于自然编码的档次有 15 种，每一档次可能支持几种视频对象和级别。可见，设计一个视频监控系统，MPEG-4 视频流的封装过程是十分重要的。五、结束语在视频监控系统的研究中，MPEG-4 视频流实时传输是网络监控系统的一个重要课题，也是网络化进程中的难题。近年来，网络技术和视频压缩编码技术取得了极大的进步，特别是 MPEG-4标准和 RTP 网络传输协议的提出，很好的解决了这个难题。文中将这两种关键技术相

23、结合，给出了一种视频监控系统的码流传输方案。但是，随着科技的不断发展和市场需求的日益增多，目前的技术可能会被继续淘汰。因此不能安于现状，需要在网络音视频传输技术领域开展更多、更深入的研究。本备忘录的状态本文档讲述了一种 Internet 社区的 Internet 标准跟踪协议，它需要进一步进行讨论和建议以得到改进。请参考最新版的“Internet 正式协议标准”(STD1)来获得本协议的标准化程度和状态。本备忘录的发布不受任何限制。版权声明Copyright(C)TheInternetSociety(2001).摘要本文描述了在 RTP 包中传输文本交谈内容的方法，关于文本交谈会话内容在 IT

24、U-T 建议（T.1401）中有详细说明。文本交谈可以用来单独传输或与音视频等交谈工具一起构成多媒体交谈服务。本 RTP 负载包含可选的已传输数据包的冗余文本来降低包丢失的风险。冗余码参照 RFC2198。目录1简介 21.1 术语 32.RTP 用法 32.1RTP 包头 32.2 附加头 42.3T.140 文本结构 43.推荐过程 43.1 基本推荐过程 53.2 补偿丢包的推荐过程 53.3 补偿乱序包的推荐过程 53.4 使用冗余时的“静音期”传输 54.范例 65安全性考虑 76.MIMEMEDIATYPEREGISTRATIONS 76.1RegistrationofMIMEme

25、diatypetext/t140 7鸣谢 8作者地址 8参考 8版权说明 9致谢 91简介本文定义了一种用于在 RTP 包中传输文本交谈会话内容的负载格式，文本交谈会话内容在 ITU-T 建议（T.1401）中有详细说明。文本交谈可单独传输或与音视频等交谈工具共同构成多媒体交谈服务。文本交谈中的文本应尽快传输，或者经过一个小的缓冲延迟。文本的输入通常是以键盘、手写识别、语音识别或是其它输入方法。字符的输入率通常为每秒几个字符。这样，期望的字符传输率也较低。通常每个包中只有很少的新字符需要传输。在 T.140 中指定文本和其它 T.140 元素必须以经过 UTF-8 变换的 ISO10646-1

26、 码来传送。这些有助于实现国际化应用，并且易于处理现代信息技术环境中的文本。本文 RTP 负载中的文本编码严格遵守 T.140，没有任何附加帧。通常是 UTF-8 编码的 ISO10646 单字符。T.140 要求字符按照原始顺序，没有重复的传输。文本交谈的使用者希望文本传输没有或尽可能少丢失。当然，如果能标识出丢失的信息，则丢失的可接受程度会高些。因此，这里介绍了一个基于 RTP 的机制。它将按照原始顺序，无重复传输，并且提供丢失检测和指示。它同时也提供一个可选方案，利用重复的冗余数据来降低丢失文本风险。考虑到包开销通常远远大于 T.140 内容，传输通道中增加冗余数据造成的负担很小。1.1

27、 术语本文中的关键字“必须”，“必须不”，“要求的”，“应该”，“不应该”，“会”，“不会”，“建议”，“或许”，“可选的”在 RFC21194中解释。2.RTP 用法当 RTP 传输中需要传输 T.140 文本交谈，应该使用本文所述的负载。这种负载格式的文本交谈 RTP 包的格式包括：一个 RTP 头（在 RFC18892中有定义），其后紧接着是一个 T.140 数据块（这里被定义为“T140block”）。该负载格式没有附加头。T140 块包括1中定义的一个或多个 T.140 码元素。大部分 T.140 码元素为 ISO106455单字符，但是也有一些是多字符序列。其中每个字符均为 UTF

28、-8 编码6的一个或多个字节。这说明不管单个字符中有几个字节，每一块必须包含 UTF-8 码的整数倍。这也说明任何组合的字符序列（CCS）应该被放到同一块中。T140 块可能会根据 RFC21983所定义的负载格式传输冗余数据。这样，RTP 头后将是一或多个冗余数据块头，个数与从携带的冗余 T140 块数相同，最后是此包的新 T140 块。2.1RTP 包头每个 RTP 包开始于一个固定的 RTP 头。下面列出了用于 T.140 文本流的几个 RTP 头字段。负载类型（PT）：RTP 负载类型的分配是使用该负载格式的 RTP 框架特定的。对于利用动态负载类型号的协议子集，这种负载格式被命名为T

29、140（参照第六节）。如果按照 RFC2198 使用冗余数据，负载类型中必须指定负载格式（RED）。顺序号：顺序号必须严格按照每个新传送包以一递增。它用于包丢失和乱序检测，同时也可以用于获取冗余文本，重组文本和标记丢失文本。时间戳：RTP 时间戳记录了包中主文本块采样时间的近似值。必须使用 1000 赫兹的时钟频率。连续包不能使用相同的时间戳。由于包不按固定间隔发送，所以时间戳不能直接被用于指示包丢失。2.2 附加头本负载格式没有定义专门的附加头。当要按 RFC2198 传输冗余数据时，RTP 头后紧跟者一个或多个冗余数据块头，每个冗余数据块都要有一个对应的冗余数据块头。这些头部均提供了时间戳

30、位移和相应的数据块长度，以及指示了这种负载格式(T140)的负载类型号。2.3T.140 文本结构T.140 文本是按 T.140 协议规定经过 UTF-8 编码的，没有额外组帧。当用该格式传输冗余数据时，发送者会选择每个包中要传输的 T140block 数。数越高则将丢包保护性越好，但同时也会增加数据传输率。由于数据包并非按一定的时间间隔产生，如果不提供附加信息，时间戳在包丢失时就无法标识出该包。冗余数据头并没有提供顺序号，所以必须遵循附加规则才能将丢失主数据所对应的冗余数据正确的插入 T140blocks 主数据流中：1.每个冗余数据块必须与先前传输原始数据的 T140 块数据相同，并标识

31、为相同的时间戳位移。2.冗余数据必须按照时间顺序放置，最近的冗余 T140 块位于冗余区的最后。3.必须包括从最早的 T140blocks 到新数据块前的 T140blocks 所有的 T140 块，。通过这些规则，冗余 T140 块的顺序号可以从当前 RTP 头的序号反向推算得到。结果就是负载中的所有文本都是连续且顺序的。3.推荐过程这部分描述了负载格式使用的推荐过程，根据接受包的信息，接收者可以：1.把错乱文本重新排序。2.标识丢失文本。3.用冗余数据补偿丢失包。3.1 基本推荐过程只有合法的 T.140 格式的数据包才被传输，T.140 数据的排序要使用顺序号。在接收端，将 RTP 顺序

32、号与最后一次正确接收包的序号相比较，如果是连续的，就从中取出 T140block。3.2 补偿丢包的推荐过程为了减少包丢失时的数据丢失，可以根据 RFC2198 在包中使用冗余数据。如果无法得知网络条件，建议每一包中只使用一个冗余 T140 块。如果 RTP 序号出现空隙，且后续包中的冗余 T140 块可用，则可以通过包中 RTP 头的序号逆向推算出冗余 T140 块的序号。如果该冗余 T140 块的序号与丢失的相吻合，就用冗余 T140 块来替换丢失 T140 块。无论是否使用冗余数据，都应该在 T140 块的接收流中插入一个丢失文本标记来标志丢失的数据，见 ITU-TT.140 附录。3.

33、3 补偿乱序包的推荐过程对于乱序包的检测，接收端应该采取下属程序。如果接收包序号有空隙，但没有可用的冗余数据来填充那个空隙，则接收包将被存储在缓存中来等待丢失包的到达。建议等待时间限于 0.5 秒。如果使用了冗余，并且冗余数乘以 T.140 缓冲时间比 0.5 秒长，则等待时间应延长到该乘积。如果空隙数据包在限制时间内到达，则将它被插入到空隙中，这样从空隙前沿开始的T140 块就恢复连续了。任何没有在限制时间内到达的 T140 块将被视为丢失。3.4 使用冗余时的“静音期”传输当使用冗余传输模式且 T.140 没有数据要传输时，最后传输的一个 T140 块有可能在作冗余数据传送之前就失效。这样

34、就不能对文本输入序列的末尾提供有效的丢包保护。为了要避免这种情况，应该传送一个 0 长度的携带冗余数据的原始 T140 块。根据 2.3 节，为了能正确推算冗余 T140 块的序号，任何被当作原始数据为 0 长度的 T140块必须如同正常文本块一样在接下来的包中当作冗余传输。最后一个 T140 块的冗余不应该由重复传送同一个包（相同序号）来解决，因为这样会造成 RTCP 报告的包丢失数量减少。4.范例这是一个没有冗余的 T140RTP 包的例子012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

35、+-+-+-+-+-+-+-+-+-+-+-+-+|V=2|P|X|CC=0|M|T140PT|顺序号|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|时间戳(1000Hz)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|同步源(SSRC)标识符|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+T.140 编码数据+|+-+|+-+-+-+-+-

36、+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+这是一个携带冗余数据的 RTP 包的例子012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|V=2|P|X|CC=0|M|REDPT|主序号|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|原始数据时间戳|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

37、+-+-+-+-+-+-+-+-+-+-+-+-+|同步源(SSRC)标识符|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|1|T140PT|R时间戳位移|R块长度|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|T140PT|+-+-+-+-+-+-+-+-+|+RT.140 编码冗余数据+|+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|PT.140 编码原始

38、数据|+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+附图：RTP 文本包的例子5安全性考虑既然本负载格式的目的是在文本交谈中携带文本，加密的安全性度量就变得十分重要。文本传输的数量很少，这样我们可以选择任何加密方法来对 T.140 会话或者整个 RTP 包进行加密。如果数据包中包含了冗余数据，要使用同 RFC2198 一样的安全性考虑。6.MIMEMediaTypeRegistrations本文档描述了一种新的 RTP 负载名称和相应的 MIME 类型，T140(text/t140).6.1RegistrationofMIMEmedi

39、atypetext/t140MIMEmediatypename:textMIMEsubtypename:t140必需参数:无可选参数:无编码考虑:按 RFC2793 规定传输 T140 文本。安全性考虑：无互操作考虑:无已发行规范:ITU-T 建议 T.140，RFC2793.使用该媒体类型的应用:文本通信终端和文本会议工具。附加信息:无Magicnumber(s):无文件扩展:无Macintosh 文件类型码:无联系办法:GunnarHellstrome-mail:gunnar.hellstromomnitor.se预期使用:COMMONAuthor/Changecontroller:Gun

40、narHellstrom|IETFavtWGgunnar.hellstromomnitor.se|c/oSteveC鸣谢感谢 StephenCasner 和 ColinPerkins 在本文写作时给予的细查和建议。感谢 Ericsson 公司的 MickeyNasiri 提供的实验环境。感谢 MicheleMizarro 验证了负载格式的可用性。作者地址GunnarHellstromOmnitorABAlsnogatan7,4trSE-11641StockholmSwedenPhone:+46708204288/+46855600203Fax:+46855600206EMail:gunnar.

41、hellstromomnitor.se参考1ITU-TRecommendationT.140(1998)-Textconversationprotocolformultimediaapplication,withamendment1,(2000).2Schulzrinne,H.,Casner,S.,Frederick,R.andV.Jacobson,RTP:ATransportProtocolforReal-TimeApplications,RFC1889,January1996.3Perkins,C.,Kouvelas,I.,Hardman,V.,Handley,M.andJ.Bolot,R

42、TPPayloadforRedundantAudioData,RFC2198,September1997.4Bradner,S.,KeywordsforuseinRFCstoIndicateRequirementLevels,BCP14,RFC2119,March1997.5ISO/IEC10646-1:(1993),UniversalMultipleOctetCodedCharacterSet.6Yergeau,F.,UTF-8,atransformationformatofISO10646,RFC2279,January1998.版权说明Copyright(C)TheInternetSoc

43、iety(2000).AllRightsReserved.Thisdocumentandtranslationsofitmaybecopiedandfurnishedtoothers,andderivativeworksthatcommentonorotherwiseexplainitorassistinitsimplementationmaybeprepared,copied,publishedanddistributed,inwholeorinpart,withoutrestrictionofanykind,providedthattheabovecopyrightnoticeandthi

44、sparagraphareincludedonallsuchcopiesandderivativeworks.However,thisdocumentitselfmaynotbemodifiedinanyway,suchasbyremovingthecopyrightnoticeorreferencestotheInternetSocietyorotherInternetorganizations,exceptasneededforthepurposeofdevelopingInternetstandardsinwhichcasetheproceduresforcopyrightsdefine

45、dintheInternetStandardsprocessmustbefollowed,orasrequiredtotranslateitintolanguagesotherthanEnglish.ThelimitedpermissionsgrantedaboveareperpetualandwillnotberevokedbytheInternetSocietyoritssuccessorsorassigns.ThisdocumentandtheinformationcontainedhereinisprovidedonanASISbasisandTHEINTERNETSOCIETYAND

46、THEINTERNETENGINEERINGTASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDINGBUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATIONHEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOFMERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.致谢FundingfortheRFCEditorfunctioniscurrentlyprovidedbytheInternetSoci

47、ety.实时传输协议（RTP）为数据提供了具有实时特征的端对端传送服务，如在组播或单播网络服务下的交互式视频音频或模拟数据。应用程序通常在 UDP 上运行 RTP 以便使用其多路结点和校验服务；这两种协议都提供了传输层协议的功能。但是 RTP 可以与其它适合的底层网络或传输协议一起使用。如果底层网络提供组播方式，那么 RTP 可以使用该组播表传输数据到多个目的地。RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。RTP 实行有序传送，RTP 中的序列号允许接收方重组发送方的包序列，同时序

48、列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。RTP 由两个紧密链接部分组成：*RTP 传送具有实时属性的数据；*RTP 控制协议（RTCP）监控服务质量并传送正在进行的会话参与者的相关信息。RTCP 第二方面的功能对于“松散受控”会话是足够的，也就是说，在没有明确的成员控制和组织的情况下，它并不非得用来支持一个应用程序的所有控制通信请求。协议结构1238916bitVPXCSRC CountMPayload TypeSequence numberTimestampSSRCCSRC(variable 0 15 items 32bits each)*V 版本。识别 RTP

49、版本。*P 间隙（Padding）。设置时，数据包包含一个或多个附加间隙位组，其中这部分不属于有效载荷。*X 扩展位。设置时，在固定头后面，根据指定格式设置一个扩展头。*CSRC Count 包含 CSRC 标识符（在固定头后）的编号。*M 标记。标记由 Profile 文件定义。允许重要事件如帧边界在数据包流中进行标记。*Payload Type 识别 RTP 有效载荷的格式，并通过应用程序决定其解释。Profile 文件规定了从 Payload 编码到 Payload 格式的缺省静态映射。另外的 Payload Type 编码可能通过非 RTP 方法实现动态定义。*Sequence Num

50、ber 每发送一个 RTP 数据包，序列号增加 1。接收方可以依次检测数据包的丢失并恢复数据包序列。*Timestamp 反映 RTP 数据包中的第一个八位组的采样时间。采样时间必须通过时钟及时提供线性无变化增量获取，以支持同步和抖动计算。*SSRC 同步源。该标识符随机选择，旨在确保在同一个 RTP 会话中不存在两个同步源具有相同的 SSRC 标识符。*CSRC 贡献源标识符。识别该数据包中的有效载荷的贡献源。RTP 控制协议（RTCP）采用与数据包相同的分发机制，将控制包周期性传输到所有会话参与者中。底层协议必须提供数据和控制包的多路发送，例如使用不同的 UDP 端口号。RTCP 主要完成