RFC1889协议 中文概要

简介 本PPT为计算机网络第9小组学习RFC1889,即RTP/RTCP协议后深感流媒体方面资料欠缺，英语文档对学习效率造成较大影响后，根据小组成员的学习心得，由组长整理并翻译的原协议中文概要。希望能为将来学习流媒体相关知识的同学提供一些帮助。 本PPT按原协议目录顺序编写，可对照学习，如有翻译和理解不当之处，尽可见仁见智。

摘要 这份文档描述了RTP这份实时传输协议。RTP提供了端到端的传输功能，通过多播或单播的方式，适合于传输如音频、视频等实时数据。RTP并不保证服务质量，也没有提供资源预留。传输的数据通过控制协议RTCP的补充来实现乃至大规模多播传输方式下的监视功能。并通过RTCP提供一些控制和识别流的功能。RTP和RTCP被设计成独立于传输和网络层。这份协议支持使用RTP层的混流服务器(MIXER)和译流服务器(TRANSLATOR)。

1.介绍

RTP通常和UDP，同时也可以和其他协议共用来实现传输实时数据，如果下层网络允许的话，支持目的地为多个地址的多播传输。

对于特定的应用，RTP协议是可扩展的。所以RTP协议只是一个框架，并且有意被定义为如此。在实际应用时，RTP协议的包头可以被修改来得到所需的功能，而不是像传统协议那样靠不断修改并使其统一来变得更完善。

1.配置文档（profile specification document） 定义传输负载类型编码和与实际负载类型格式的对应关系。对于特定的应用，还定义了对于RTP所应做的扩展和修改。 2.负载格式规范文档（payload format specification documents） 定义了特定格式编码的音、视频文件如何在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负载（RTP PAYLOAD)： RTP包中传输的数据，比如音频数据和压缩了的视频数据。 RTP 包 （RTP PACKET): 由RTP包头（HEADER), 组成源服务器（CSRC）列表（见下）和传输数据构成。一般来说一个下层协议如UDP的包中仅包含一个RTP包，但也可以通过封装方式包含几个RTP包。

RTCP 包（RTCP PACKET): 一个包含控制信息的包，同样由包头和后面结构化的数据组成，结构化的数据根据RTCP包的类型不同而有所不同（详见第6章）。典型的，RTCP包的传输是把几个包放在一起组成一个下层协议的包来传输的。 端口 （PORT): 即传统意义上网络的端口。

传输地址（TRANSPORT ADDRESS): 由地址和端口号组成，如一个IP地址和UDP端口。数据由传送方地址传到接收方地址。 RTP会话 （RTP SESSION): 多个参与者通过RTP协议通信，这就形成了一个RTP会话。对于每个参与者来说，RTP会话被一个地址和一对端口号定义。在多媒体会话中，不同的流建立不同的RTP会话（如：音频的会话，视频的会话）。每种不同的会话都有自己的RTCP包。不同的会话靠不同的传输地址来区分。

同步化源（SYNCHRONIZATION SOURCE）： 即SSRC，可理解为信号的源头，如一个麦克风输入或一个摄像头输入，在整个会话中有一个独一无二的标识符。从它输出的信号都经过它的同步处理，以使接受方能实现对源的控制，如回放功能。若一个服务器有多个输入，如多个摄像头信号，那么每个摄像头都有一个SSRC。SSRC标识符靠RTCP绑定。 供流源（CONTRIBUTING SOURCE ）： 即CSRC，经由混流服务器（MIXER)输出的一个流通常由多个分流汇成，每个分流都有一个供流源。（详见第8章）

终端系统（END SYSTEM): 一个能产生（也可以接受）需要传输的RTP包的进程。在一个会话中可以由一个或几个同步化源组成，但通常仅由一个组成。 混流服务器（MIXER): 从一个或多个源接受信息，然后可能对数据类型作适当修改，混合接受流，产生一个新数据流的实体。从其产生的数据流的SSRC受到修改，把混流服务器的SSRC作为新的同步化源标识符。

译流服务器（TRANSLATOR）: 有输入流，也有输出流，不改变输入流的SSRC，这点与MIXER不同。举几个例子：转换流的编码，但不混合输入流的程序；将多播转换为多个单播的程序；应用层上的防火墙过滤器。 监控器（MONITOR): 通过接受网络上会话的参与者发送的RTCP控制包，做预测服务质量，诊断错误原因等工作。可以由建立RTP会话的应用程序提供，也可能由第三方行使此功能，如ISP服务商等。

非RTP方式（NON-RTP MEANS): 作为RTP的补充。在诸如分发会议多播IP和加密密钥时，可能用到其他协议和机制。在RTP负载的类型未确定时，需要通过其他方式来传递RTP头中负载类型标识和相应的负载类型规范文档的映射关系。

4.字节顺序 对齐方式 时间格式

字节顺序 所有的整数字节按所谓的“BIG-ENDIAN”顺序排列，即，高位字节权重大

对齐方式 按数据自身的长度对齐，无法对齐的地方以0填充。（请参看协议，此仅为个人意见）

时间格式 时间的表示按照互联网时间协议（NETWORK TIME PROTOCOL),即NTP定义。 表示时间的变量类型为64位无符号长整数。将1900年1月1日0点作为原点，以秒为单位，变量的前32位表示整数部分，后32位表示小数部分。 在有些格式中为了节省空间，仅用中间32位来表示时间，前16位为整数，后16位为小数。

5.RTP数据传输协议

5.1 RTP 头部字段 格式如下： 前12个字节是每个RTP头都有的，CSRC字段只有当MIXER插入时才产生。

字段定义 version (V): 2 bits RTP版本号。 padding (P): 1 bit 置1时表明末尾有非数据的填充字段。所有填充字段的最后一个字节为填充字段长度。填充字段常被用于需加密的场合。 extension (X): 1 bit 此位若置1，则在标准的头部字段后还有扩展的字段，其定义见5.3.1

CSRC count (CC): 4 bits CSRC列表的项数 marker (M): 1 bit 由配置文件定义，用于特定的应用程序。 payload type (PT): 7 bits 负载数据类型编号，具体格式定义在PAYLOAD FORMAT SPECIFICATION文件中。 sequence number: 16 bits 每发送一个RTP包，该项加1，其初始数值随机产生，以防止别人破译加密。

timestamp: 32 bits 该项用于时间同步计算和抖动控制，其精度必须足以满足上述两项要求。时钟频率与负载类型有关，2者同时定义在PAYLOAD FORMAT SPECIFICATION文件中。其初始值随机。 SSRC: 32 bits 同步化源标识符，即此RTP包的发出者（个人理解）。因为一个RTP会话中不能有2个相同的SSRC ，所以当发送者传输地址改变时此值需重新生成，以防止形成循环。

CSRC list: 0 to 15 items, 32 bits each 字段头中CSRC COUNT项给出了该项中ITEM的数量。 当包通过MIXER时由MIXER将原来包中的SSRC标识符作为CSRC插入，而将MIXER自己的SSRC作为新的SSRC项。

5.2 RTP会话的多路传输 RTP协议中，多路传输的目标地址由定义RTP会话的网络地址＋端口号确定。 音、视频传输不能定义在同一个RTP会话中，因为负载类型不同而SSRC标识符相同会引起一系列的问题。（详细问题请参考原文档）

5.3 配置文档（profile-specific document） 对于一些常用的功能来说，RTP协议是足够的。但在一些特殊的应用场合，可能需要在RTP包头后面加上一些扩展定义来满足需求。5.1中的MARKER和PAYLOAD TYPE字段就可以与接下来要讨论的配置文档一起提供所需的额外信息。 如果对上述字段的特定值在很多场合都行使同样的功能的话，则可将其加入协议，作为标准确立

5.3.1 RTP头的扩展 扩展定义通常仅用于实验或者个别的场合。 如果RTP头中的X字段置1，则在RTP头部的CSRC列表后（如果有这个列表的话），产生一个16位的DEFINED BY PROFILE字段和一个16位的LENTH字段。前者由特定的配置文件定义，后者的值为LENGTH字段后扩展定义位所需字节数，其长度不包括LENGTH和DEFINED BY PROFILE所占的4个字节。所以长度0也是允许的，虽然这样并没什么意义。

扩展头格式：

6. RTP传输协议之——RTCP

RTCP协议基于每隔一段时间给会话的所有参与者发送一些控制包的机制。下层协议必须支持数据和控制包的多路传输。比如通过UDP协议发送数据到多个端口。

RTCP协议的四个主要功能 1.提供数据分布服务质量的反馈。这是RTP作为传输协议必不可少的部分。同时也与别的协议中拥塞和流量控制功能有关。反馈功能主要通过“接受者报告”和“发送者报告”实现（详见6.3）。在某些时候，第三方也可以通过RTCP包实现对网络的监控。

RTCP协议的四个主要功能 2.RTCP包中携带着RTP源的永久标识符信息存放为CNAME（canonical name）项。在会话中的RTP源有可能因为SSRC冲突或者因为程序重启而重新生成一个SSRC，但它的CNAME是不变的，这样就可以追踪会话的每个参与者。

RTCP协议的四个主要功能 3. 前2个功能均要求会议的参与者发送RTCP包。所以，发送速率应该得到控制以适应有大规模参与者的RTP会话。每个参与者必须可以独立地知道会话的参与者数量，来决定发包的速率（详见6.2）。

RTCP协议的四个主要功能 4. 第四个，同时也是一个可选功能项，通过RTCP协议传递最少的会话控制信息，比如用户界面上显示的参与者身份。这个功能在参与者可随时加入或离开的会话时非常有用，因为可以传递控制信息到每个参与者。该功能用于IP多播环境

RTCP协议的四个主要功能 功能1－3是必须的，功能4是推荐使用在所有环境下的。RTP协议的设计应避免只能用于单播模式并且应当能推广到大规模传输的应用。

6.1 RTCP的包格式 以下是RTCP包的5种类型： SR: Sender report 会话中频繁发送包的参与者的报告 RR: Receiver report 非频繁发包的参与者发送的接受方统计数据 SDES: Source description items 发送源描述项，包括CNAME信息 BYE: 终止参与会议信息的包 APP: 用于特定进程的包

每个RTCP包都有一个包头，然后根据包的类型的不同，包头后跟着不同长度的结构化的数据项，但这些数据项都有一个32位的包的边界。 RTCP包通过下层协议传输时，相邻的包之间没有分隔符。比如用UDP传输时，并没有给出UDP包中RTCP包的数量，而仅有一个总长度

几个RTCP包在通过下层协议传输时，对包的排列次序和组合方式没有要求，但有以下限制： 接受方数据统计（包含于SR和RR内）必须在带宽允许下尽可能多地发送，以使统计更加精确。因此，每个RTCP包集合必须有一个SR或RR的包。 新的接收者必须尽快得到源的CNAME并联系媒体求得同步。每个RTCP包集合必须包含SDES CNAME。

综上所述，每个RTCP包都必须以混合包的形式传输，每个混合包中必须至少包含2个独立的包，包的形式按下列推荐： Encryption prefix: 混合包如果需要加密，前面必须有个32位加密前缀。 SR or RR: 混合包的第一个包必须为其中之一。 Additional RRs: 如果接受方数据中的源的数目超过了31，就需在正常的RR或SR后添加发送超出部分的信息 SDES: 每个混合包中必须包含的包类型，除了CNAME项，可视带宽情况在SDES包中加入更多源的信息。 BYE or APP: BYE类型的RTCP包必须是SSRC/CSRC发送的最后一个包，APP包为其他类型的RTCP包。

MIXER和TRANSLATOR被建议在收到由多个源发出的单独的RTCP包后将数个包混合，形成一个混合包。一个例子如下所示：

6.2 RTCP包发送间隔 在整个RTP会话期间，根据资源预留协议会分配一定的会话带宽(SESSION BANDWIDTH)。由于RTP会话要能适应很大的规模，所以RTP包的发送会有自我限制（SELF-LIMITING)。但是RTCP包的发送没有这种机制，又不能因为大规模发送RTCP控制包占用网络带宽，所以RTCP包的发送量只能不超过固定比例地占用会话带宽。因此，会话规模扩大之后，RTCP包发送速率下降。在附录A.7中详细介绍了会话带宽的计算方式。

6.2.1得到会话参加者数量 计算发包间隔与参加会话的站点数有关。参加会话的站点被维护在一个表中，以SSRC/CSRC标识。一个新站点直到带有它的SSRC标识符的包被大量收到以后才能被确认并加入表中。当一个站点被确认后，即时之后被标记为INACTIVE，它的带宽仍得到保留并留在表中。其目的是为了防止包的丢失。服务器超时设置为30分钟，至少为一般RTCP发包间隔的5倍以上。

6.2.2 源服务器描述的带宽分配 6.1中提到的RTCP包中的SDES包内包含了对于源服务器的描述。描述内容除了CNAME项是必须的，其余内容由应用程序的需要决定。由于发送额外内容需要占用网络带宽，所以发送不同内容的包具有优先级的差别。

6.3 发送者和接受者报告(SR/RR) RTP包的接受者发送REPORT的RTCP包来反馈服务质量。REPORT包分为2种，RR和SR。两者的唯一区别是，发送后者的站点不仅是包的接受者同时也是活跃的包发送者。所以SR比RR要多20字节，用来携带发送者信息。

6.3.1 SR: Sender report RTCP packet

SR包由3部分组成，如果配置文件指定的话，可能会有额外的信息附加在第三部分之后。这三部分为： HEADER SENDER INFO REPORT BLOCKS

HEADER: version (V): 2 bits RTP协议所用版本 padding (P): 1 bit 置1时表明末尾有非数据的填充字段。填充字段的最后一个字节为填充字段长度。填充字段常被用于需加密的场合。 多个RTCP包被放在一个下层协议包中传送时，只有最后一个包有填充字段，因为下层协议包是整个被加密的。

Reception report count (RC): 5 bits RTCP包中对于各个站点的RECEPTION REPORT项的数量，可以为0。 packet type (PT): 8 bits RTCP包类型，作为SR包，值为常量200。 length: 16 bits RTCP包长度，以32位字长为单位，包括包头和填充，然后减1，即为此项值。所以0也是合法长度。 SSRC: 32 bits 发送此包的站点的SSRC标识符

SENDER INFORMATION: 该部分共长20字节，其中包含了SENDER所要发送的信息，其中字段结构如下： NTP timestamp: 64 bits 按NTP协议格式给出此包发送的时间。 RTP timestamp: 32 bits 与上面的NTP timestamp对应，用来估算RTP的时钟周期

sender’s packet count: 32 bits 从传输开始到此RTCP包发送时刻为止，站点共发送的RTP数据包数量。 sender’s octet count: 32 bits 从传输开始到此RTCP包发送时刻为止，站点共发送的RTP数据量，即PAYLOAD的数量。当站点的SSRC改变时，此项清零。该项常被用于估计实际数据传输率。

REPORT BLOCKS 该项可以有0或者多项信息，取决于从上次发包到当前包的时间间隔内该服务器收到的数据包的源的数量。每项都传递了发送给当前站点数据包的SSRC的接收信息。该项包含以下信息： SSRC_n (source identifier): 32 bits 当前BLOCK中的信息所对应的SSRC标识符

fraction lost: 8 bits 从上次发送RR或SR到本次发送期间，从该项对应的SSRC发送到本站点的包中丢失的包的数量与应收到包的数量的比例。 cumulative number of packets lost: 24 bits 从该项对应的SSRC到本站点所发送包的总丢包率。

extended highest sequence number received: 32 bits 低16位记录了从对应SSRC站点收到的包的最大序号，高16位记录了总的循环数。 interarrival jitter: 32 bits 抖动控制字段。详见原文档。

6.3.2 接受者报告RTCP包(RR) 其结构与SR包基本相同，区别仅在于少了20字节的发送者信息，同时PACKET TYPE字段值为201，而不是SR中的200。

RR包格式：

6.3.3 扩展RR和SR 同RTP包一样，可通过配置文件在特定的应用中发送一些REPORT RTCP 包。由于应用场合是特定的，包的形式可能更短小，更易于处理。

6.3.4 对SR和RR的分析 REPORT RTCP包不仅可以让SENDER调整自己的发包方式，同时对于RECEIVER定位拥塞发生点是局部的还是全局的也有很大作用。对第三方的MONITOR也能提供参考信息。 如Cumulative counts，NTP timestamp可以用来计算丢包率、数据率和数据分配情况interarrival jitter可用来计算网络短期内的拥塞情况。

6.4 源描述信息RTCP包(SDES) 每个SDES包包含一个包头和0或多个SSRC或CSRC信息项，每个信息项中又分别包含多个子项信息，如CNAME、E-MAIL等。

SDES格式如下：

version (V), padding (P), length: 与SR包定义相同 (见 6.3.1). packet type (PT): 8 bits 值为常量202 source count (SC): 5 bits 包中描述的SSRC/CSRC的数目

包头后的每一项都是对一个SSRC/CSRC的描述，其中包含一系列子项。每个子项都具有下列格式： 8位子项类型标识 8位该子项的描述文本长度，不包括子项头这2个字节 描述文本，以UTF-8方式编码，最大长度255字节

6.4.1 CNAME: Canonical end-point identifier SDES item 同SSRC一样，在一个RTP会话中，CNAME也是全局唯一的，用来绑定应用程序与该站点的连接，通常具有以下形式："doe@sleepy.megacorp.com" "doe@192.0.2.89"

6.4.2 NAME: User name SDES item 源站点的真正名字，在RTP会话中并不要求全局唯一

6.4.3 EMAIL: Electronic mail address SDES item E-MAIL格式按RFC822定义，如： John.Doe@megacorp.com

6.4.4 PHONE: Phone number SDES item 格式如下： +1 908 555 1212

6.4.5 LOC: Geographic user location SDES item 根据应用的不同，对于位置的介绍可以有不同的详细的程度，由实现和用户决定。该项的值在会话期间应保持不变，除非是移动主机。

6.4.6 TOOL: Application or tool name SDES item 给出产生该流的应用程序名，如果可能，给出相应版本号。该项在DEBUG时可能产生作用。在整个会话期间应保持不变。

6.4.7 NOTE: Notice/status SDES item 当源站点产生一个事件时，该项传递了该事件的信息。通常，这个事件是比较重要的当该项有效时。则传递CNAME的包的发送速率下降以让出带宽发送该包

6.4.8 PRIV: Private extensions SDES item 这一项被定义作为实验或特定的程序中的应用。直到有些PRIV中的值被证实具有通用的意义，这些值才会被IANA定义，成为标准的一部分

6.5 BYE: Goodbye RTCP packet 表示1个或多个源将不再ACTIVE

6.6 APP: Application-defined RTCP packet 用于试验新的程序中的应用和特点，当实验完成并被证实可大规模应用时，可在IANA注册。

7. RTP 译流服务器(TRANSLATOR) 和混流服务器(MIXER)

7.1 整体描述 RTP MIXER/TRANSLATOR连接2个或多个所谓的“network cloud”。每个CLOUD由各自所用的网络层和传输层协议，传输目的地定义（地址＋端口）。1个站点可以在多个RTP会话中担当MIXER或TRANSLATOR的角色，但彼此之间是独立的实体

当一台机器被定义为TRANSLATOR/MIXER时，为防止出现循环，应遵循下列原则： 每个CLOUD都在所使用的协议，地址和端口这几项上必须至少有一项存在不同。 多个TRANSLATOR/MIXER不能并行地连接相同的网络，除非特殊需要。 根据不同的目的，可以定义多种TRANSLATOR/MIXER，比如加密解密数据包，改变数据编码格式和协议等。

TRANSLATOR和MIXER的区别：前者流入一个或多个流，作必要改变后将其分别送出，后者流入一个或多个流，将其混合后输出。 RTP包通过时SSRC保持不变，以使接受方能对源进行某些控制。根据TRANSLATOR的不同，某些包通过时数据内容不变，某些包通过时改变数据内容。RECEIVER是感觉不到TRANSLATOR的存在的。 MIXER: 按某些方式改变数据或混合数据将数据包的SSRC换成自己的SSRC。而将原来各个流的SSRC添加入CSRC表中。如果自己也产生数据加入流中，则CSRC中也必须有自身所在的项。

MIXER相对于TRANSLATOR的好处在于较适合传输数据到低带宽网络，缺点在于接受方无法对SSRC进行有效控制。 下页所附图为MIXER和TRANSLATOR的工作方式，原理如下：M代表MIXER，T代表TRANSLATOR，E代表END SYSTEM，E1带有SSRC值17，E2带有SSRC值1，通过M1时，包的SSRC被换成M的SSRC48,而17和1被添加到CSRC列表。

7.2 RTCP包在TRANSLATOR中的处理过程 某些TRANSLATOR，比如仅仅将多播地址复制为单播地址的站点，对通过的RTP数据包不作改变；但其他的一些TRANSLATOR，如转化RTP包中负载类型的站点，就要对SR和RR包作相应的改变。一个TRANSLATOR不应把从多个站点得到的SR或RR包合在一起传输，应为那样会降低传输延迟计算的精确性。（具体过程由于本实验并未涉及，请参阅对应文档，7.3节亦作类似处理）。

7.3 RTCP包在MIXER中的处理过程 由于MIXER产生了新的流，所以并不允许RR和SR包的通过，而为流的源和目的地分别产生新的RR和SR包。

协议的第8章SSRC标识符的分配和使用，第9章安全由于与本次作业关系不大，且限于本人水平，未完全理解其算法，所以无法给出译文和概要，敬请谅解                  

10. 网络和传输协议上的RTP

RTP依靠下层协议提供对RTP数据的多路传输和RTCP控制流的传送。对于UDP或相似协议来说，RTP使用一对相邻端口，其一传输RTP数据包，另一个传输RTCP控制包。

11. 协议常量的总结

本章总结了协议中定义的常量值。 RTP PAYLOAD TYPE定义在独立的文档中，而不在本协议中定义

11.1 RTCP 包类型 缩写 英文名 值 SR sender report 200 RR receiver report 201 缩写 英文名 值 SR sender report 200 RR receiver report 201 SDES source description 202 BYE goodbye 203 APP application-defined 204

11.2 SDES types 缩写 英文名 值 END end of SDES list 0 CNAME canonical name 1 缩写 英文名 值 END end of SDES list 0 CNAME canonical name 1 NAME user name 2 EMAIL user’s electronic mail address 3 PHONE user’s phone number 4 LOC geographic user location 5 TOOL name of application or tool 6 NOTE notice about the source 7 PRIV private extensions 8

12. RTP配置文件和负载格式规范

对于一个特定应用的RTP规范必须由一个或多个文档作为补充定义，这些补充文档分为下列两类： 负载格式规范文件

RTP协议必须有足够的弹性来适应不同场合的应用，比如传输音频和视频文件的配置文件即为Internet-Draft draft-ietf-avt-profile 对于负载格式规范文件，定义了特定类型的负载，比如用H.261压缩的视频文件如何用RTP包来传送。在这个文件中，下列选项可能会被重新定义：

RTP data header Payload types RTP data header additions RTP data header extensions RTCP packet types RTCP report interval SR/RR extension SDES use Security

String-to-key mapping Underlying protocol Transport mapping Encapsulation 相对于定义新的配置文件，在原有基础上作些扩展要更好，一些简单的改变，比如additional payload type values 或 RTCP packet types可以向IANA注册，然后将新的定义作为附录添加到相应的配置文件或格式描述文件中去。

谢谢观赏 制作人： 第9小组组长CG 由于时间有限，附录未译出。 限于水平，错误难免，望谅解。 希望这份PPT对您学习RTP协议有所帮助。 若能如此，本人不甚荣幸。 RTSP协议，即RFC2326原亦在翻译计划之中， 但限于时间，未付诸实践，拟于今后完成这 一愿望。 经过本次大作业，发现流媒体是一个很有趣 的领域，有意联系本人者，可加 QQ：279878126，转载请注明此信息。 谢谢观赏 制作人： 第9小组组长CG