rfc3550（RTP协议） 翻译

Network Working Group                                    H.Schulzrinne

Request for Comments: 3550                          Columbia University

Obsoletes: 1889                                       S. Casner

Category: Standards Track                           Packet Design

                                                                R. Frederick

                                                Blue Coat Systems Inc.

                                                           V. Jacobson

                                                        Packet Design

                                                            July 2003

RTP：实时应用程序传输协议

（RTP: A Transport Protocol for Real-Time Applications）

备忘录状态

       本文档为因特网社区提供了一个因特网标准协议的详细说明，它还需要进一步的讨论和建议。请查阅当前版本的“因特网官方协议标准”（STD1）以得到本标准说明和这个协议的状态。本备忘录发布没有限制。

版权公告

       Copyright (C) The Internet Society (2003). All Rights Reserved.

摘要

       本备忘录描述了RTP，实时传输协议。RTP提供端到端网络传输功能，它适用与传输实时数据的应用程序，比如 音频，视频或者模拟数据穿越单播或多播网络服务。RTP没有地址资源预约也不保证实时服务质量。通过一个控制协议（RTCP）数据传输得到了加强。RTCP允许以一个随大型多播网络伸缩的方式监视数据传递，并提供最低限度的控制和验证功能。

RTP和RTCP独立于下面的传输层和网络层。本协议支持RTP层的转发器和混合器。

       本备忘录的大部分内容和已经废弃的RFC1889是相同的，包格式并没有改变，仅对协议如何使用的规则和算法做少许改动。最大的改动是增强了可伸缩定时器的算法，这个定时器是计算发送RTCP包的时机，目的是在许多参与者同时加入到一个会话是以超过预期的速率将传输减到最少。

 

目录

1           介绍

1．1              术语

2                         RTP使用说明

2．1              简单多播音频会议

2．2              音频和视频会议

2．3              混合器和转发器

2．4              分层编码

3                         定义

4                         字节序，校正和时间格式

5                         RTP数据传输协议

5．1              RTP固定分组头

5．2              多路复用RTP会话

5．3              变更RTP头的概述

5．3．1            RTP头扩展

6                         RTP控制协议————RTCP

6．1              RTCP包格式

6．2              RTCP传输时间间隔

6．2．1 维持会话成员数量

       6．3        RTCP包发送和接收规则

       6．3．1 计算RTCP传输时间间隔

       6．3．2 初始化

       6．3．3 接收一个RTP 或者 Non-BYE RTCP 包

       6．3．4 接收一个RTP BYE包

       6．3．5 超时SSRC

       6．3．6 传输定时器的截止

       6．3．7 发送一个 BYE 包

       6．3．8 更新 we-sent

       6．3．9 指定资源描述带宽

6．4        发送方和接收方通告

       6．4．1 SR：发送方通告RTCP包

       6．4．2 RR：接收方通告RTCP包

       6．4．3 扩展发送方和接收方通告

       6．4．4 分析发送方和接收方通告

6．5 SDES：资源描述RTCP包

       6．5．1 CNAME：规范的终端标示符 SDES 条款

       6．5．2 NAME：用户名称 SDES条款

       6．5．3 EMAIL：电子邮件地址 SDES条款

       6．5．4 PHONE：电话号码 SDES条款

       6．5．5 LOC：地理位置 SDES 条款

       6．5．6 TOOL：应用程序或工具名称 SDES条款

       6．5．7 NOTE：通知/状态 SDES 条款

       6．5．8 PRV：私有扩展 SDES 条款

6．6        BYE：再见 RTCP 包

6．7        APP：应用程序定义RTCP包

7      RTP 转发器和混合器

       7．1        概述

       7．2        在转发器中的RTCP数据处理

       7．2        在混合器中的RTCP数据处理

       7．3        级联混合器

8      SSRC 标示符分配和使用

       8．1        冲突的可能性

       8．2        冲突解决和循环检测

       8．3        使用分层编码

9      安全

       9．1        机密性

       9．2        身份验证和信息完整

10     阻塞控制

11     网络和传输协议之上的RTP

12     协议常量概述

       12．1      RTCP 包类型

       12．2      SDES 类型

13     RTP 概况和净荷格式详细说明

14     安全考虑

15     IANA考虑

16     知识产权描述

17     感谢

附录A。算法

附录A。1       RTP数据头校验

附录A。2       RTCP数据头校验

附录A。3       确定期望报数和丢失包数

附录A。4       生成RTCP SDES 包

附录A。5       解析RTCP SDES 包

附录A。6       生成一个随即32位标示符

附录A。7       计算RTCP传输时间间隔

附录A。8     估计两次时间间隔的抖动

附录B            与RFC1889的不同

引用

标准引用

资料引用

作者地址

版权描述

 

 

1 介绍

       本备忘录详细规定了实时传输协议（RTP），它为某些类型的数据提供了端到端的传输服务。这些数据具有实时属性，比如交互式的音频和视频。这些服务包括净荷类型标示，顺序号，时间戳，和传递监视。典型情况下，应用程序在UDP上运行RTP，通过利用UDP的多路传输和校验服务；这两个协议到提供了传输协议的功能，但是RTP应该与其他下层的网络或传输协议共同使用（见11节）。如果下层网络提供了多播，那么RTP支持数据的多目的传输。

       需要注意的是RTP本身并不提供任何机制来保证及时传送或其他服务质量保证。而是依靠下层服务做到这一点，它不能提供可靠传输或预防失序传递。也不假定下层网络是可靠的或是以序传递包的。例如在视频编码里，编码包的顺序并不是必须的。

       RTP主要用于满足多用户多媒体会议需要，但它并不局限与此。连续数据存储，交互的分布式模拟，活动标记，和控制，测量应用程序，也有RTP的一席之地。

       本文档定义了RTP，由紧密相连的两部分组成

1 实时传输协议（RTP），传输具有实时属性的数据

2 RTP控制协议（RTCP），监视服务质量和传递下一个会话中的参与者信息。后一方面对于松散控制会话可能已经足够了，例如在没有显式的成员资格控制和创建的地方，它并不是必须支持一个应用程序控制通信的所有需求。这些功能可能被全部或部分地包含在一个单独的会话控制协议，对它的讨论已经超出了本文档的范围。

随着由Clark 和Tennenhouse提议的应用程序层框架和综合层处理原则，RTP表现出一种新的协议形式。那就是说，RTP计划有伸缩性地由一个特殊应用程序来提供所需要的信息并且经常被综合进应用程序处理中而不是作为一个分开的层来实现。RTP仅是一个不完整的协议框架，这个文档详细说明的这些功能对所有适用RTP的应用程序来说都是通用的。在一些常规的协议里，附加的功能可能通过使协议更通用或添加需要解析的选项机制来调节，与它们不同，RTP通过修改或添加需要的协议头来达到预期的裁剪。例子在5。3和6。4。3中给出。

因此，除这篇文档之外，一个完整的RTP详细说明还需要一个或更多的协作文档（见13节）

一个概要的说明文档，它定义了一系列的净荷类型代码和他们到净荷格式的影射（例如，多媒体编码）。也可能定义一些对RTP的扩展和修改并在一个特别的应用程序类里得到了明确。典型情况下一个应用程序仅遵照一个概要。一个对音频和视频数据的说明可以在RFC3551 中找到。

净载格式详细说明文档，它定义了一个独特的净载，例如一个音频或视频编码，在RTP中是如何被运载的。

关于实时服务和算法的实现的讨论以及一些RTP设计决议的背景讨论可以在 [11] 中找到。

1．1              术语

本文档中的关键字 “MUST” “MUST NOT” “REQUIRED” “SHALL” “SHALL NOT”, “SHOULD” “SHOULD NOT” “RECOMMENED” “MAY” AND “OPTICAL”将在BCF14，RFC2119中给出描述性解析。并指出了相应的RTP实现的需求。

2                         RTP 使用说明书

随后的章节描述了使用RTP的一些方面。所选择的例子是演示使用RTP的应用程序的基本操作，不要因此而限制了RTP 的使用范围。在这些例子中， RTP加上了IP和UDP头部，并遵从RFC3551的约定。

 

2．2 音视频会议

       如果音频和视频同时应用到一个会议，他们被作为分离的RTP会话来传递。那就是说，对一个媒体的RTP包和RTCP包用两个不同的UDP端口对或多播地址来传输。

音频和视频会话之间并不存在RTP层的直接耦合，除非参与到两个会话的一个用户在两者的RTCP包中使用了相同的规范的名字，以便于是两个会话联系起来。

       对这种分离机制的一个动机是为了允许会话中的一些参与者接收到自己所选择的一种媒体。进一步的解释在5。2节中给出。经管同源的音频和视频是分开的，利用两个会话的RTCP包里的时间信息，也能达到同步回放。

2．3 混频器 和 转换器

       迄今为止，我们一直假设所有的地点都想接收相同格式的媒体数据。但是，这一点并不总是适当的。想象一下，一个区域的参与者通过一个低速链接 连接到高速网络会议上。代替强迫每个人都使用一个较低的带宽（音频编码质量下降），一个叫做混频器的RTP级的中继器可以放在低带宽区域的附近。这个混频器再次同步接收到的音频包来重构这个由发送者生成的连续的20毫秒间隔，把这些重构的音频流混合到一个单独的流。转换这个音频编码到一个低带宽编码并把这个低带宽包流推向前，穿过这个低带宽链接。这些包可能单播到一个单独的接收者，或在一个不同的地址上多播到多个接收者。这个RTP头包括了混合器的标志来表明该资源是混合的以便把正确的谈话者指示提供给接收者。

       音频会议中的一些参与者可能采用了高带宽接入，但是却不能通过 IP 多播直接到达。比如， 他们很可能在一个应用程序级的防火墙的后面， 而这个防火墙不让任何IP 包通过。对这些地点来说，混合也许不是必需的，而另一种RTP级的中继称为转换器的就派上了用场。两个转换器分别被安装在防火墙的两边， 外面的哪个把通过一个安全连接接收的全部多播包灌进防火墙。而在内侧的转换器把它们作为多播包再次发送到一个特定的多播组，该多播组被限制在该地点的内部网络。

       混合器和转换器可以用于各种各样的用途。一个例子是一个视频混合器测量分开的视频流里的个别人的图象然后把它们合成到一个视频流中来模拟一组景物。其他关于传输的例子包括连接一组IP/UDP主机到一组ST—II 主机，或者来自分开源的视频流不需要再同步或混合而一个包接一个包的传输。混合器和转换器的操作细节在 7 节中给出。

2．4              分层编码

多媒体应用程序应该能够调节传输速率来匹配接收容量或者适应网络阻塞。许多实现把速率适应的责任放在源端。但是由于不同接收者对带宽需求的冲突，它在多播传输时并不能工作的很好。这经常导致最小公分母方案，即用网格中的最小管道来规定全部多媒体传输的质量和保真度。

相反，可以联合分层编码和分层传输系统来把速率适应的责任放在接收端。在IP多播之上的RTP上下文中，源能够把一个分级描述信号的层分成条状穿过多重会话，每个会话运载它自己的多播组。 接收方通过仅仅加入适当的多播组子集来适应网络非均匀性和控制接收带宽。（这句看着头晕，翻的不太准确）。

RTP分层编码的细节在 6。3。9 节和11 节中给出。