没有合适的资源?快使用搜索试试~ 我知道了~
首页RFC 3550 中文文档:实时传输协议 RTP 翻译
RFC 3550 中文文档:实时传输协议 RTP 翻译
需积分: 49 27 下载量 140 浏览量
更新于2024-07-15
收藏 2.54MB PDF 举报
"RFC 3550中文文档" RFC 3550是互联网工程任务组(IETF)发布的一份文档,主要介绍实时传输协议(Real-time Transport Protocol, RTP)。这份文档是2003年7月更新的标准,取代了之前的RFC 1889,属于IETF的“标准跟踪”类别,意味着它是互联网标准过程中的一个重要组成部分。 RTP是一种网络协议,设计用于在互联网上实时传输音频、视频和其他时间敏感的数据。它提供了一种框架,使得数据可以在多个网络服务之间进行传输,包括多播和单播方式。RTP并不专注于预留网络资源或保证服务质量(QoS),而是专注于如何有效地传输实时数据流,以尽可能减少延迟和抖动。 RTP的核心功能包括时间戳和序列号,它们允许接收端重新排序接收到的数据包和检测丢失的包。此外,RTP通常与实时传输控制协议(RTCP)一起使用,RTCP的主要作用是监测和评估服务质量,收集传输统计信息,以及为参与者提供反馈,以帮助调整传输参数和提高性能。 该中文文档是由译者翻译的,特别指出,由于工作量大,附录部分未被翻译。译者也提醒读者,文档中可能存在的错译或理解错误,并鼓励感兴趣的读者提出疑问和反馈。文档末尾还提到了版权信息,该文档的版权归The Internet Society所有。 RTP的应用场景广泛,包括但不限于VoIP(Voice over IP)、在线会议、流媒体服务等。它在现代通信系统中扮演着关键角色,因为它能够处理网络变化和不确定性,确保实时数据的可靠传输。RTP的灵活性和适应性使其成为多媒体通信领域不可或缺的一部分。
资源详情
资源推荐
![](https://csdnimg.cn/release/download_crawler_static/12581607/bg10.jpg)
RFC 3550 RTP July 2003
中的位数量来指定没有标识位(见第 5.3 节)。
payload type (PT):7 bits
这个字段定一个 RTP payload 的格式和在应用中定义解释。profile 可能指
定一个从 payload type 码字到 payload format 的默认静态映射。也可以通过
non-RTP 方法来定义附加的 payload type 码字(见第 3 章)。在 RFC 3551[1]中
定义了一系列的默认音视频映射。一个 RTP 源有可能在会话中改变 payload
type,但是这个域在复用独立的媒体时是不同的。(见 5.2 节)。
接收者必须忽略它不识别的 payload type。
sequence number:16 bits
每发送一个 RTP 数据报文序列号值加一,接收者也可用来检测丢失的包或者
重建报文序列。初始的值是随机的,这样就使得 known-plaintext 攻击更加困难,
即使源并没有加密(见 9。1),因为要通过的 translator 会做这些事情。关于选
择随机数方面的技术见[17]。
timestamp:32 bits
timestamp 反映的是 RTP 数据报文中的第一个字段的采样时刻的时间瞬时
值。采样时间值必须是从恒定的和线性的时间中得到以便于同步和 jitter 计算
(见第 6.4.1 节)。必须保证同步和测量保温 jitter 到来所需要的时间精度(一帧
一个 tick 一般情况下是不够的)。 时钟频率是与 payload 所携带的数据格式有
关的,在 profile 中静态的定义或是在定义格式的 payload format 中,或通过
non-RTP 方法所定义的 payload format 中动态的定义。如果 RTP 报文周期的生
成,就采用虚拟的(nominal) 采样时钟而不是从系统时钟读数。例如,在固定比
特率的音频中,timestamp 时钟会在每个采样周期时加一。如果音频应用中从输
入设备中读入 160 个采样周期的块,the timestamp 就会每一块增加 160,而不
管块是否传输了或是丢弃了。
对于序列号来说,timestamp 初始值是随机的。只要它们是同时(逻辑上)同
时生成的,这些连续的的 RTP 报文就会有相同的 timestamp,例如,同属一个视
频帧。正像在 MPEG 中内插视频帧一样,连续的但不是按顺序发送的 RTP 报文可
能含有相同的 timestamp。
不同媒体流的 RTP timestamp 可 能有不同的速率,通常有独立的随机
offset。虽然这些 timestamp 对于从建单流的时序是足够的,但是直接比较不同
timestamp 来获得同步是不够的。因此,对于每一个媒介来说,RTP timestamp
与采样时刻是通过与从参考时钟而来的 timestamp 作对比而建立时间戳对
(pair),系统时钟 timestamp 是数据数据被采样的时刻的 timestamp。系统时钟
被所有媒体共享以便同步。timestamp 对不是在每一个数据报文中传送,而是在
低速率的 RTCP SR 报文中传送见第 6.4 节。
采样瞬时值作为 RTP timestamp 是因为这对于传输的终点来说是可知的并且
它对于所有媒体,独立的编码延迟,或者其它的处理来说是一个通用的定义。目
的是为了允许所有的同时采样的媒体能够同步表示
PDF 文件使用 "pdfFactory Pro" 试用版本创建 www.fineprint.com.cn
11
![](https://csdnimg.cn/release/download_crawler_static/12581607/bg11.jpg)
RFC 3550 RTP July 2003
(presentation)。
应用所传输的数据是已经存储的而不是实时采样的,利用一个虚拟的从
wallclock 得到的表示时间来确定下一帧或是其它的存储单元的表示时间。在这
种情况下,RTP timestamp 会为每个单元提供表示时间。即每一个单元的 RTP
timestamp 会根据 wallclock time 来确定虚拟的表示时间。就收者的真正的再
现会发生在一些时间后。
事先录音的现场音频会议很好的说明了选择采样瞬时值作为参考点的的重
要作用。在这个假定中,视频必须被同步利用 RTP 传送以便于讲述者”看”。RTP
传送的一帧视频的"采样瞬时值"是由参考自己的时间戳与 wallclock 时间来确
定什么时刻再现给讲述者。对于包含讲述者语音的音频 RTP 报文的采样瞬时值来
说,是由参考音频采样时刻的 wallclock 时刻确定的。如果两台主机是由 NTP
来同步的,也可以通过这两台的主机传送音视频。就收者可以利用 在 RTCP Sr
报文中的 timestamp 对中的 RTP timestamp 来重现音视频。
SSRC:32 bits
SSRC 域识别同步源。为了防止在一个会话中有相同的同步源有相同的 SSRC
identifier, 这个 identifier 必须随机选取。生成随机 identifier 的算法见
目 录 A.6 。 虽然选择相同的 identifier 概率很小 , 但 是 所有的 RTP
implementation 必须检测和解决冲突。第 8 章描述了冲突的概率和解决机制和
RTP 级的检测机制,根据唯一的 SSRC identifier 前向循环。如果有源改变了它
的源传输地址,就必须为它选择一个新的 SSRC identifier 来避免被识别为循环
过的源(见第 8.2 节)。
CSRC list:0 to 15 items,32 bits each
CSRC list 表示那些在本报文中对 payload 作了贡献的源。号数是由 CC 域
定的。如果有多于 15 个贡献源,只有 15 个源可以被标识。CSRC identifier 是
由 Mixer 利用贡献源的 SSRC identifier 插入的。例如,对于音频报文,所有混
合在一起的源的 SSRC identifier 被例出来,以便就收者识别出正确的讲话者。
5.2 RTP 会话的多路复用
正如在 the integrated layer processing design principle [10] 中描述
的那样,为了协议处理更有效率,复用点的数量应最小化,在 RTP 中,复用技术
是由目的传输地址(网络地址和端口号)提供的。例如,在音频与视频独立编码的
远程电信会议(teleconference)中,每一个媒介都是由单独的带有自己的目的传
输地址的 RTP 会话来携带的。
分开的音频和视频流不应该在一个 RTP 会话中携带也不应该基于 payload
type 或 SSRC 域来解复用(是 should not be carried in a single RTP session
and demultiplexed based on the payload type or SSRC fields) 。不同的 RTP
PDF 文件使用 "pdfFactory Pro" 试用版本创建 www.fineprint.com.cn
12
![](https://csdnimg.cn/release/download_crawler_static/12581607/bg12.jpg)
RFC 3550 RTP July 2003
媒体但是用同样的 SSRC 较差的报文会产生几种问题:
1。 假设,两个音频流公用相同的 RTP 会话,具有相同的 SSRC 值,其中的一
个改变了编码因此需要一个不同的 RTP payload type,就是不能识别出到底是
哪个流改变了编码。
2。 SSRC 是用来识别一个单时序和序列值间隙的。如果媒体时钟速率不同,
交叉的多 payload type 需要不同的时隙和不同的序列间隙来通知哪个 payload
type 承受了损失。
3。 RTCP 发送者和接受者报告在每个 SSRC 仅能描述单时序和序列号间隙,
没有携带 payload type 域。
4。 RTP Mixer 不能将不兼容的交叉 媒体流合并成单一流。
5。 在一个 RTP 会话中携带多个媒体流就不会出现下面几种情况:利用不同
的网络路径或者分配的网络资源;希望接收子媒体,例如视频超出了带宽的承受
能力而至接收音频,接受方对不同的媒体进行不同的处理,而用独立的 RTP 会话
就可以执行单或多媒体处理。
每一个媒体用一个 SSRC 但是在一个 RTP 会话中发送它们可以避免上述的前
三种情况,但是不能解决 后两种情况。
另一方面,在一个 RTP 会话中具有不同 SSRC 值的同一媒体的相关源的多路
复用对多播会话来说是很标准的。上述问题就不会出现:例如,RTP Mixe 可以
合并多个媒体音频源,对它们进行同样的处理。这对具有不同 SSRC 值得相同媒
体的复用也是很合适的,这样就不存在后两个问题了。
5.3 RTP 头的 Profile-Specific 修正
现有的 RTP 数据报文头对一般的 RTP 所支持的应用来说已经是很完善的了。
然而为了与 ALF 设计原理保持一致,头字段可以修剪或是根据附加条款的定义而
增补,仍旧允许监测和记录。
o marker bit 和 payload type 域携带 profile-specific 信息,但是它们
是在定长头字段中分配的,因为很多应用需要它们,不然就的额外增加 32-bit。
包含这些域的字段可以根据需要而作出修改,例如增或减 marker bit。如果有
很多的 marker bit,应该关注那些最重要的位,因为 profile-independent 监
测就可以观测报文丢失和 marker bit 的关系了。
o 特定 payload format 所需要的附加信息,例如视频编码应该在有效载荷
段携带。这可能会是在经常出现在有效载荷段的开始的头部或是由数据类型的保
留值来标识。
PDF 文件使用 "pdfFactory Pro" 试用版本创建 www.fineprint.com.cn
13
![](https://csdnimg.cn/release/download_crawler_static/12581607/bg13.jpg)
RFC 3550 RTP July 2003
o 如有应用需要与 payload format 无关的附加功能的话,在应用下面运行
的 profile 就应该定义固定的域来追踪 SSRC 域。应用可以直接访问附加域,而
profile-independent monitors 或是记录者仍旧可以通过前 12 个字节来识别
RTP 报文和进行相应的处理。
如果是所有 profile 都需要的附加功能的话,那就需要另外定义一个 RTP
版本了。
5.3.1 RTP 头字段扩展
新的独立的有效载荷格式需要在 RTP 数据报文头中携带附加的信息,这就需
要一种扩展的机制。设计这种机制的目的就是为了那些没有进行头字段扩展的
implementation 可以忽略这些。
需要注意的是这种头字段的扩展仅仅是为了有限的应用。更具有潜在价值的
做法是用前面描述的方法。例如对定长头字段的 profile-specific 扩展代价更
小因为它不需要条件或是在变长的区域(location)。特定 payload format 需
要的附加信息不应用这个头扩展而是携带在报文有效载荷区。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined by profile | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extension |
| 。。。。 |
如果 RTP 头中的 X bit 是 1 的话,就必须在 RTP 头附加上变长的头扩展,
如果有 CSRC list 的话就是在它后面。头扩展中包含一个 16-bit 的长度域用来
对扩展中的 32-bit 字个数计数,把 four-octet 的头扩展(有效长度是零)排 出
在 外 。只 能 在 RTP 数据头中附加一个扩展。为了允许具有不同头扩展的交互操作
和为了允许多于一个头扩展的特定操作(multiple interoperating
implementations to each experiment independently with different header
extensions, or to allow a
particular implementation to experiment with more than one type of header
extension),头扩展的前 16 位是用来鉴别 identifier 或是参数的。格式是由执
行操作下面的 profile 来定义的。RTP 不定义任何的头扩展。
PDF 文件使用 "pdfFactory Pro" 试用版本创建 www.fineprint.com.cn
14
![](https://csdnimg.cn/release/download_crawler_static/12581607/bg14.jpg)
RFC 3550 RTP July 2003
6. RTP 控制协议--RTCP
RTP 控制协议(RTCP)是基于在会话中的对所有参与者周期传输的控制报文
的,与 数据报文使用相同的分发机制。协议必须提供对数据报文和控制报文的复
用,例如用 UDP 的不同端口号。RTCP 有下面四个功能:
1。 最基本的功能是对提供分发数据的质量反馈。这是 RTP 作为一个完整的
传输协议所必须的部分,与其它的提供流或拥塞控制的传输协议有关(见第 10
章中关于拥塞控制需求分析)。反馈对控制自适应编码有直接的影响[18,19]。
进一步的 IP 多播实验表明它对从接收者的反馈的作出分发错误诊断也很重要。
将就受报告反馈给所有人就使得关注问题的人知道问题时本地的或是全局的。利
用像 IP 多播的分发机制,可以使像服务提供者这样的实体(entity)收到反馈和
作为第三方监测诊断网络问题的所在。这种反馈的功能有 RTCP sender 和
receiver report 实现,见第 6.4 节。
2。 RTCP 为 RTP source 携带一个稳定的传输级的 identifier,叫 canonical
name 或 CNAME,
见 6.5.1。因为 SSRC identifier 可能因为发现了冲突或是程序重起而改变,接
受者需要 CNAME 追踪每一个参与者。接受者也可以用 CNAME 来协调从一个参与者
而来的一系列相关 RTP 会话的数据流,例如同步音频和视频。Inter-media 同步
需要 NTP 和 RTP timestamps 包含在发送者发送的 RTCP 报文中。
3。 前两个功能需要所有参与者都发送 RTCP 报文,因此必须控制速率使得
RTP 可以让各夺得参与者加入。每个人都对所有人发送他的控制报文,这就使得
人人都可以独立的观察参与者的数量。这个数量用来计算发包的速率见第 6。2
节。
4。 这个功能是可选的,传达最小的会话控制信息,例如在用户界面显示参
与者的身份。这最有可能用在 "loosely controlled" 会话中,因为参与者不需
要身份控制或是参数传递就可以进入或退出。RTCP 扮演一个直达接受者的便利
通道的角色,但是不需要支持所有应用需要的控制通信的全部要求,需要一种更
高一级的会话控制协议,这不在本文当讨论范围之内。
1-3 功能应用在所有情况中,特别是在 IP 多播的情况。RTP 应用设计者应该
避免那些只能工作在单播模式不能提供更多的数量的机制。接受者和发送者各自
控制 RTCP 的传输。见第 6.2 节,例如单向链路不可能从接受者那里收到反馈。
非标准的注释:在一种叫 Source-Specific Multicast(SSM) 的多播路由方法
中,一个"channel"只有一个发送者(一个源地址,组地址对),接收者不能与其
他的 channel 成员(except for the channel source)利用多播直接通信。本建
议仅通过第 6。2 提供的关闭接收者的 RTCP 来调节 SSM。将来会修改文档可以支
持接收者
PDF 文件使用 "pdfFactory Pro" 试用版本创建 www.fineprint.com.cn
15
规范的
更多的
剩余95页未读,继续阅读
![rar](https://img-home.csdnimg.cn/images/20210720083606.png)
![rar](https://img-home.csdnimg.cn/images/20210720083606.png)
![application/x-rar](https://img-home.csdnimg.cn/images/20210720083606.png)
![pdf](https://img-home.csdnimg.cn/images/20210720083512.png)
![pdf](https://img-home.csdnimg.cn/images/20210720083512.png)
![pdf](https://img-home.csdnimg.cn/images/20210720083512.png)
![](https://profile-avatar.csdnimg.cn/f6d8bfa4af664b6dbf6adc4157d3ad11_qq_18998145.jpg!1)
LIEYz
- 粉丝: 54
- 资源: 22
上传资源 快速赚钱
我的内容管理 展开
我的资源 快来上传第一个资源
我的收益
登录查看自己的收益我的积分 登录查看自己的积分
我的C币 登录后查看C币余额
我的收藏
我的下载
下载帮助
![](https://csdnimg.cn/release/wenkucmsfe/public/img/voice.245cc511.png)
最新资源
- 新型矿用本安直流稳压电源设计:双重保护电路
- 煤矿掘进工作面安全因素研究:结构方程模型
- 利用同位素位移探测原子内部新型力
- 钻锚机钻臂动力学仿真分析与优化
- 钻孔成像技术在巷道松动圈检测与支护设计中的应用
- 极化与非极化ep碰撞中J/ψ的Sivers与cos2φ效应:理论分析与COMPASS验证
- 新疆矿区1200m深孔钻探关键技术与实践
- 建筑行业事故预防:综合动态事故致因理论的应用
- 北斗卫星监测系统在电网塔形实时监控中的应用
- 煤层气羽状水平井数值模拟:交替隐式算法的应用
- 开放字符串T对偶与双空间坐标变换
- 煤矿瓦斯抽采半径测定新方法——瓦斯储量法
- 大倾角大采高工作面设备稳定与安全控制关键技术
- 超标违规背景下的热波动影响分析
- 中国煤矿选煤设计进展与挑战:历史、现状与未来发展
- 反演技术与RBF神经网络在移动机器人控制中的应用
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
![](https://img-home.csdnimg.cn/images/20220527035711.png)
![](https://img-home.csdnimg.cn/images/20220527035711.png)
![](https://img-home.csdnimg.cn/images/20220527035111.png)
安全验证
文档复制为VIP权益,开通VIP直接复制
![](https://csdnimg.cn/release/wenkucmsfe/public/img/green-success.6a4acb44.png)