《RFC1889协议中文概要》由会员分享，可在线阅读，更多相关《RFC1889协议中文概要（15页珍藏版）》请在金锄头文库上搜索。
1、RFC1889协议中文概要摘要n 这份文档描述了RTP这份实时传输协议。RTP提供了端到端的传输功能，通过多播或单播的方式，适合于传输如音频、视频等实时数据。RTP并不保证服务质量，也没有提供资源预留。传输的数据通过控制协议RTCP的补充来实现乃至大规模多播传输方式下的监视功能。并通过RTCP提供一些控制和识别流的功能。RTP和RTCP被设计成独立于传输和网络层。这份协议支持使用RTP层的混流服务器(MIXER)和译流服务器(TRANSLATOR)。1.介绍n RTP通常和UDP，同时也可以和其他协议共用来实现传输实时数据，如果下层网络允许的话，支持目的地为多个地址的多播传输。n RTP并不保
2、证服务质量而主要靠下层协议的支持，所以每个包都有一个顺序号使接受方能按序重建数据。n RTP原先被设计用于多方参加的多媒体会议，但也可以用于如交互模拟等其他应用。n 对于特定的应用，RTP协议是可扩展的。所以RTP协议只是一个框架，并且有意被定义为如此。在实际应用时，RTP协议的包头可以被修改来得到所需的功能，而不是像传统协议那样靠不断修改并使其统一来变得更完善。n 正因为上述原因，使用RTP协议时，一般需要两种伴随文档：1.配置文档（profile specification document）n 定义传输负载类型编码和与实际负载类型格式的对应关系。对于特定的应用，还定义了对于RTP所应做的
3、扩展和修改。2.负载格式规范文档（payload format specification documents）n 定义了特定格式编码的音、视频文件如何在RTP协议中传输。2.一些RTP应用实例2.1 简单的音频会议n 通过IP多播方式建立的一个会议，每个参与者通过某些分配机制（不在本协议讨论范围中）得到一个组地址和2个端口号，一个端口号用来传送RTP数据，即音频数据，另一个用来传输RTCP控制数据。如果需要加密，可根据本协议第9章内容生成密钥。n 会议的每个参与者每隔20ms发送一段音频数据，放在RTP包中。RTP包又通过UDP包传输。RTP包头中定义了音频文件的编码方式，以便参与者改变自己
4、的编码方式以适应网络传输（如编码质量低以适应低带宽传输）。n INTERNET会产生丢包和延迟，所以RTP包头中包含了时间信息和一个序号，序号可以用来使接受方预测丢包的情况。n 在本例中，由于会议不时有成员加入或离开，所以每个接受方会每隔一段时间报告一次接受情况。这个信息有可能被用来控制编码方式以适应带宽。当某个成员发出BYE的RTCP包时，该成员离开该会议。2.2 音频、视频会议n 音频、视频信息通过不同的RTP会话（session）传输，即二者是分开传输的。同时对于每一个传输，都有2个端口用来传送RTP数据和RTCP控制信息。n 这样做的目的是因为接受者可能由于带宽限制，只够接受音频数据，
5、或他只想接受一种数据。在5.2中可得到这方面的详细信息。2.3 混流服务器(MIXER)和译流服务器(TRANSLATOR)n 顾名思义，混流就是把多个进入的流信息混合输出为一个流，一个应用就是适应不同带宽的需要。n 译流服务器就是把入流经过转化变成另一种形式的流传出，一个应用是防火墙有可能阻止某些端口的IP包，而经过转换的IP包可顺利通过。 混流服务器(MIXER)和译流服务器（TRANSLATOR)在第7章中有详细介绍，建议先阅读那部分文档以对其有个全面了解。3. 定义n RTP负载（RTP PAYLOAD)： RTP包中传输的数据，比如音频数据和压缩了的视频数据。n RTP 包 （RTP
6、 PACKET): 由RTP包头（HEADER), 组成源服务器（CSRC）列表（见下）和传输数据构成。一般来说一个下层协议如UDP的包中仅包含一个RTP包，但也可以通过封装方式包含几个RTP包。n RTCP 包（RTCP PACKET): 一个包含控制信息的包，同样由包头和后面结构化的数据组成，结构化的数据根据RTCP包的类型不同而有所不同（详见第6章）。典型的，RTCP包的传输是把几个包放在一起组成一个下层协议的包来传输的。n 端口 （PORT): 即传统意义上网络的端口。n 传输地址（TRANSPORT ADDRESS): 由地址和端口号组成，如一个IP地址和UDP端口。数据由传送方地址
7、传到接收方地址。n RTP会话 （RTP SESSION): 多个参与者通过RTP协议通信，这就形成了一个RTP会话。对于每个参与者来说，RTP会话被一个地址和一对端口号定义。在多媒体会话中，不同的流建立不同的RTP会话（如：音频的会话，视频的会话）。每种不同的会话都有自己的RTCP包。不同的会话靠不同的传输地址来区分。n 同步化源（SYNCHRONIZATION SOURCE）： 即SSRC，可理解为信号的源头，如一个麦克风输入或一个摄像头输入，在整个会话中有一个独一无二的标识符。从它输出的信号都经过它的同步处理，以使接受方能实现对源的控制，如回放功能。若一个服务器有多个输入，如多个摄像头信
8、号，那么每个摄像头都有一个SSRC。SSRC标识符靠RTCP绑定。n 供流源（CONTRIBUTING SOURCE ）： 即CSRC，经由混流服务器（MIXER)输出的一个流通常由多个分流汇成，每个分流都有一个供流源。（详见第8章）n 终端系统（END SYSTEM): 一个能产生（也可以接受）需要传输的RTP包的进程。在一个会话中可以由一个或几个同步化源组成，但通常仅由一个组成。n 混流服务器（MIXER): 从一个或多个源接受信息，然后可能对数据类型作适当修改，混合接受流，产生一个新数据流的实体。从其产生的数据流的SSRC受到修改，把混流服务器的SSRC作为新的同步化源标识符。n 译流服
9、务器（TRANSLATOR）: 有输入流，也有输出流，不改变输入流的SSRC，这点与MIXER不同。举几个例子：转换流的编码，但不混合输入流的程序；将多播转换为多个单播的程序；应用层上的防火墙过滤器。n 监控器（MONITOR): 通过接受网络上会话的参与者发送的RTCP控制包，做预测服务质量，诊断错误原因等工作。可以由建立RTP会话的应用程序提供，也可能由第三方行使此功能，如ISP服务商等。n 非RTP方式（NON-RTP MEANS): 作为RTP的补充。在诸如分发会议多播IP和加密密钥时，可能用到其他协议和机制。在RTP负载的类型未确定时，需要通过其他方式来传递RTP头中负载类型标识和相
10、应的负载类型规范文档的映射关系。4.字节顺序 对齐方式 时间格式字节顺序n 所有的整数字节按所谓的“BIG-ENDIAN”顺序排列，即，高位字节权重大对齐方式n 按数据自身的长度对齐，无法对齐的地方以0填充。（请参看协议，此仅为个人意见）时间格式n 时间的表示按照互联网时间协议（NETWORK TIME PROTOCOL),即NTP定义。 n 表示时间的变量类型为64位无符号长整数。将1900年1月1日0点作为原点，以秒为单位，变量的前32位表示整数部分，后32位表示小数部分。n 在有些格式中为了节省空间，仅用中间32位来表示时间，前16位为整数，后16位为小数。5.RTP数据传输协议5.1
11、RTP 头部字段n 格式如下：n 前12个字节是每个RTP头都有的，CSRC字段只有当MIXER插入时才产生。字段定义n version (V): 2 bits RTP版本号。n padding (P): 1 bit 置1时表明末尾有非数据的填充字段。所有填充字段的最后一个字节为填充字段长度。填充字段常被用于需加密的场合。n extension (X): 1 bit 此位若置1，则在标准的头部字段后还有扩展的字段，其定义见5.3.1n CSRC count (CC): 4 bits CSRC列表的项数n marker (M): 1 bit 由配置文件定义，用于特定的应用程序。n payload
12、 type (PT): 7 bits 负载数据类型编号，具体格式定义在PAYLOAD FORMAT SPECIFICATION文件中。n sequence number: 16 bits 每发送一个RTP包，该项加1，其初始数值随机产生，以防止别人破译加密。n timestamp: 32 bits 该项用于时间同步计算和抖动控制，其精度必须足以满足上述两项要求。时钟频率与负载类型有关，2者同时定义在PAYLOAD FORMAT SPECIFICATION文件中。其初始值随机。n SSRC: 32 bits 同步化源标识符，即此RTP包的发出者（个人理解）。因为一个RTP会话中不能有2个相同的S
13、SRC ，所以当发送者传输地址改变时此值需重新生成，以防止形成循环。n CSRC list: 0 to 15 items, 32 bits each 字段头中CSRC COUNT项给出了该项中ITEM的数量。 当包通过MIXER时由MIXER将原来包中的SSRC标识符作为CSRC插入，而将MIXER自己的SSRC作为新的SSRC项。5.2 RTP会话的多路传输n RTP协议中，多路传输的目标地址由定义RTP会话的网络地址端口号确定。n 音、视频传输不能定义在同一个RTP会话中，因为负载类型不同而SSRC标识符相同会引起一系列的问题。（详细问题请参考原文档）5.3 配置文档（profile-sp
14、ecific document）n 对于一些常用的功能来说，RTP协议是足够的。但在一些特殊的应用场合，可能需要在RTP包头后面加上一些扩展定义来满足需求。5.1中的MARKER和PAYLOAD TYPE字段就可以与接下来要讨论的配置文档一起提供所需的额外信息。n 如果对上述字段的特定值在很多场合都行使同样的功能的话，则可将其加入协议，作为标准确立5.3.1 RTP头的扩展n 扩展定义通常仅用于实验或者个别的场合。n 如果RTP头中的X字段置1，则在RTP头部的CSRC列表后（如果有这个列表的话），产生一个16位的DEFINED BY PROFILE字段和一个16位的LENTH字段。前者由特定
15、的配置文件定义，后者的值为LENGTH字段后扩展定义位所需字节数，其长度不包括LENGTH和DEFINED BY PROFILE所占的4个字节。所以长度0也是允许的，虽然这样并没什么意义。扩展头格式：6. RTP传输协议之RTCPn RTCP协议基于每隔一段时间给会话的所有参与者发送一些控制包的机制。下层协议必须支持数据和控制包的多路传输。比如通过UDP协议发送数据到多个端口。RTCP协议的四个主要功能 1.提供数据分布服务质量的反馈。这是RTP作为传输协议必不可少的部分。同时也与别的协议中拥塞和流量控制功能有关。反馈功能主要通过“接受者报告”和“发送者报告”实现（详见6.3）。在某些时候，第三方也可以通过RTCP包实现对网络的监控。RTCP协议的四个主要功能 2.RTCP包中携带着RTP源的永久标识符信息存放为CNAME（canonical name）项。在会话中的RTP源有可能因为SSRC冲突或者因为程序重启而重新生成一个S
