RFC1889协议中文概要

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