我的思科语音学习笔记 语音协议（一）RTP/RTCP 2010.5.20

语音有几个重要的相关协议

Signaling Protocol: 不传递语音，只负责信令

H.323: 由ITU 出的协议，从H.320 ISDN标准演化而来， 使用E.164

MGCP:  IETF后出的为PSTN提供的 gateway control

SIP: IETF 出的协议，比H.323简单，但是不如H.323成熟，使用URL

Media Protocol: 传递语音

RTP: IETF media streaming protocol， 封装在UDP包里

RTCP: RTCP与RTP共存，RTCP是个控制协议

Signaling Protocol 在OSI模型中 处于Session Layer

Media Protocol 在OSI模型中 处于 Transport Layer

下面逐个学习

1. RTP

Real-time Transport Protocol , provide end-to-end delivery services for data with real-time characteristics, such as interactive audio and video.[1]

先看包头结构

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X|  CC   |M|     PT      |       sequence number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

字段解析：

V： Version， 2 bits  可以是 0， 1， 或者2

P： Padding， 1 bit 用来indicateRTP包中是否有Padding

      RTP的包在有些情况下是要求fixed size的，因此padding非常必要

X： Extension 1 bit 用来indicate是否有扩展包头

CC： CSRC count 4 bits 用来indicate包头中CSRC identifier的数目

M： Marker 1 bit 含义由 profile定义， 用于标记一些重要事件，例如frame boundaries

PT： Payload Type 7 bits， 负载类型，注意接受者收到不认识的PT会直接丢包

sequence number： 16 bits，每发一个+1，起始值是随机的

timestamp： 32 bits， 记录着RTP数据第一个8位组取样的时间，起始值是随机的

		注意这里几个同时采集的RTP包其时间戳可以是一样的，并且，时间戳也可以是非单调的，也就是说数据传输的顺序与其被采集的顺序可以不同。同时还要注意，在同步这个问题上并不是单单只靠时间戳的。时间戳需要与一个参考钟（reference clock或者wall clock）配对 从而达到同步的效果。参考钟是所有需要同步的media共享的。

SSRC： 32bits 标识同步源，SS就是 synchronization sources的缩写。实质上是为了标识一个独立的时间以及sequence number的空间。

CSRC： 0-15 items， 每个32 bits，CS就是contributing sources的缩写。如果多于15个contributing source，则只能标识其中的15个。这个list是由mixer生成的。

RTP本身不提供任何按时到达或者QoS保障的机制，这些都依赖于下层协议，比如IP/UDP。同时，RTP所谓的multiplexing也是通过下层协议的destination address实现的，例如IP地址/UDP端口号。

不同的音频视频流也不能在同一个RTP session中传递，首先若类型不同PT字段没法填了，SSRC也无法起到其作用了，这个原因RFC中共列出了5点。

RTP的扩展包头： 一个允许你自己定义payload格式的机制，紧跟在CSRC之后。 扩展包头的长度是32bit为单位的，有多少32bit将在扩展包头的length字段体现出来。

2. RTCP

RTP Control Protocol： 传给session所有参与者的周期性的控制包

四大功能：

 * 反馈数据分发的质量

 * 携带着代表一个RTP源的永久有效的一个所谓的CNAME。原因是SSRC有可能因为冲突或者程序重开而改变。

 * 计算速率

 * 承载最小化的session控制信息，作为一个可达到所有参与者的方便途径

RTCP的这些功能，尤其是前三个，应该应用于IP 组播环境中，一定要避免单播环境中使用。

RTCP的传输可能需要sender与receiver分别做控制，以防单向链路之类的情况发生。

RTCP的包类型： 

SR： sender report

RR： receiver report

SDES： source description items， including CNAME

BYE： 标识结束参与

APP： 应用相关的功能

RTCP的作用机制暂且不提，待碰到具体应用时再研究

References:

[1] RFC 3550  http://www.ietf.org/rfc/rfc3550.txt