RTP/RTCP

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
RFC3550 - RTP: A Transport Protocol for Real-Time Applications
http://www.ietf.org/rfc/rfc3550.txt?number=3550

RFC3551 - RTP Profile for Audio and Video Conferences with Minimal Control
http://www.ietf.org/rfc/rfc3551.txt?number=3551

RFC2198 - RTP Payload for Redundant Audio Data
http://www.ietf.org/rfc/rfc2198.txt?number=2198

RFC2205 - Resource ReSerVation Protocol (RSVP)
http://www.ietf.org/rfc/rfc2205.txt?number=2205

RFC2750 - RSVP Extensions for Policy Control
http://www.ietf.org/rfc/rfc2750.txt?number=2750

RFC3936 - Procedures for Modifying the Resource reSerVation Protocol (RSVP)
http://www.ietf.org/rfc/rfc3936.txt?number=3936

RFC4495 - A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow
http://www.ietf.org/rfc/rfc4495.txt?number=4495

RFC2748 - The COPS (Common Open Policy Service) Protocol
http://www.ietf.org/rfc/rfc2748.txt?number=2748

RFC2749 - COPS usage for RSVP
http://www.ietf.org/rfc/rfc2749.txt?number=2749

RFC4261 - Common Open Policy Service (COPS) Over Transport Layer Security (TLS)
http://www.ietf.org/rfc/rfc4261.txt?number=4261

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

因为IP互联网不是等时系统，所以在发送实时数字数据时需要额外的协议支持。除了允许检测复制或重新排序的分组的基本次序信息之外，每个分组还必须传送单独的时间戳，告诉接收方应该播放分组中的数据的准确时间。
如果网络中有抖动，接收方需要实现回放缓冲区来准确地重建信号。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

在IP互联网上传输数字音频或视频信号所使用的协议是实时传输协议 (Real-Time Transport Protocol, RTP)。RTP不包含确保及时交付的机制，必须由底层系统来保证。

RTP提供两个关键的特性：每个分组中的序号以及时间戳。序号允许接收方检测不按顺序的交付或数据丢失，时间戳允许接收方控制回放。

设计RTP是为了传送包括音频和视频等广泛的实时数据，所以RTP不强制统一的语义解释，而是每个分组以固定的首部开头，首部中的字段指定如何解释其余的首部字段以及如何解释有效载荷。

*********** * **** *********** * **** *********** * **** *********** * **** *********** * ****
The RTP header has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       sequence number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           synchronization source (SSRC) identifier            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|            contributing source (CSRC) identifiers             |
|                             ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            payload (audio, video....)                         |
|                                       +-+-+-+-+-+-+-+-+-+-+-+-+
|                                   ....|  padding  |  count    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

开始12个八进制出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。各段含义如下：

①版本（V）

2位，标识RTP版本。

②填充标识（P）

1位，如设置填充位，在包尾将包含附加填充字，它不属于有效载荷。填充的最后一个八进制包含应该忽略的八进制计数。某些加密算法需要固定大小的填充字，或为在底层协议数据单元中携带几个RTP包。

③扩展（X）

1位，如设置扩展位，固定头后跟一个头扩展。

④CSRC计数（CC）

4位，CSRC计数包括紧接在固定头后CSRC标识符个数。

⑤标记（M）

1位，标记解释由设置定义，目的在于允许重要事件在包流中标记出来。设置可定义其他标示位，或通过改变位数量来指定没有标记位。

⑥载荷类型（PT）

7位，记录后面资料使用哪种 Codec ， receiver 端找出相应的 decoder 解碼出來。

常用 types：

Payload Type	Codec
0	PCM μ -Law
8	PCM-A Law
9	G..722 audio codec
4	G..723 audio codec
15	G..728 audio codec
18	G..729 audio codec
34	G..763 audio codec
31	G..761 audio codec

⑦系列号

16位，系列号随每个RTP数据包而增加1，由接收者用来探测包损失。系列号初值是随机的，使对加密的文本攻击更加困难。

⑧时标

32位，时标反映RTP数据包中第一个八进制数的采样时刻，采样时刻必须从单调、线性增加的时钟导出，以允许同步与抖动计算。时标可以让receiver端知道在正确的时间将资料播放出来。

由上图可知，如果只有系列号，并不能完整按照顺序的将data播放出来，因为如果data中间有一段是没有资料的，只有系列号的话会造成错误，需搭配上让它知道在哪个时间将data正确播放出来，如此我们才能播放出正确无误的信息。

⑨SSRC

32位，SSRC段标识同步源。此标识不是随机选择的，目的在于使同一RTP包连接中没有两个同步源有相同的SSRC标识。尽管多个源选择同一个标识的概率很低，所有RTP实现都必须探测并解决冲突。如源改变源传输地址，也必须选择一个新SSRC标识以避免插入成环行源。

⑩CSRC列表

0到15项，每项32位。CSRC列表表示包内的对载荷起作用的源。标识数量由CC段给出。如超出15个作用源，也仅标识15个。CSRC标识由混合器插入，采用作用源的SSRC标识。
*********** * **** *********** * **** *********** * **** *********** * **** *********** * ****


RTP的关键部分是对变换 (也就是在中间位置改变数据流的编码)或混合 (也就是从多个源接收数据流，把它们组合成一个数据流，然后发送结果)的支持。混合和组播技术的结合能使交付给每个参与主机的数据报减少。

RTP首部中的字段标识发送方，指示是否发生混合。同步源标识符字段指定数据流的源站。每个源站必须选择一个惟一的32位标识符，如果发生冲突，则协议包括解决冲突的机制。当混合器组合多个数据流时，混合器就变成新的数据流的同步源。但是有关初始源的信息没有丢失，这是因为混合器使用大小可变的参与源ID字段提供正在混合的数据流的同步ID。4位CC字段给出参与源的数目，最多可以列出15个源。

传统的TCP 协议是一个面向连接的协议,它的重传机制和拥塞控制机制都是不适用于实时多媒体传输的。RTP 是一个应用型的传输层协议,它并不提供任何传输可靠性的保证和流量的拥塞控制机制。 RTP不像传输协议那样发挥作用，在实际应用中不会在IP中直接封装，而是RTP在UDP上运行，这意味着把每条RTP报文封装到UDP数据报中。使用UDP的主要优点是并发性 -- 单个计算机可以有多个使用RTP的应用程序，而不会互相干扰。RTP不使用保留的UDP端口号，而是为每个会话分配一个端口，因此必须把端口号通知给远程的应用程序。通常情况下RTP选择偶数UDP端口号。



- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

RTP控制协议 (RTCP)，是RTP的一个完整部分，提供需要的控制功能。RTCP允许发送方和接收方相互传输一系列报告，这些报告包含有关正在传输的数据以及网络性能的额外信息。 在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。

当应用程序开始一个rtp会话时将使用两个端口：一个给rtp，一个给rtcp。rtp本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠rtcp提供这些服务。RTCP报文封装在UDP中，以便进行传输，发送时使用比它们所属的RTP流的端口号大1的协议号。

RTCP使用5个基本报文类型允许发送方和接收方交换有关会话的信息。

类型 含义
-------------------------------------------------------------
200 发送方报告 (SR)
201 接收方报告 (RR)
202 源描述报文 (SDES)
203 结束报文 (BYE)
204 应用程序特定报文 (APP)

1. 发送方在停止发送数据流时传输一条结束报文。
2. 应用程序特定报文提供了基本功能的扩展，以允许应用程序定义报文类型。
3. 接收方周期性地传输接收方报告报文，向源通知接收的条件。
4. 发送方周期性地传输发送方报告报文，提供绝对的时间戳。而绝对时间戳为接收方提供了使多个数据流同步的机制。
5. 发送方还传输源站描述报文，提供有关拥有对源站控制权的用户的常规信息。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

H.323不是单个协议，而是制定如何把多个协议组合起来，形成一个实用的IP电话技术系统。

H.323为IP电话技术使用的协议：
协议 目的
-----------------------------------------------
H.225.0 建立通话所使用的信令
H.245 在通话中控制和返回
RTP 实时数据传输（序列和时限）
T.120 交换和通话有关的数据


SIP只涵盖信令，不推荐特殊的编码，也不要求对实时传输使用RTP。SIP使用C/S交互方式。为了提供有关通话的信息，SIP要依靠一个伴生的协议，即会话说明协议 (SDP)。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IETF提供的在IP环境中的QoS方案：
资源预留协议 (Resource Reservation Protocol, RSVP)
通用开放策略服务 (Common Open Policy Services, COPS)

RSVP处理预留请求并进行应答，它不是路由协议，也不强制在建立数据流时就启用策略，而是在发送任何数据之前运转。每个RSVP流是单工的 (simplex)，也就是单向传输的。
端点使用RSVP在指定了QoS界限的IP互联网上请求单工数据流。如果路径上的路由器同意请求，则认可数据流，否则拒绝数据流。如果应用程序需要两个方向上的QoS，则每个端点必须使用RSVP请求单独的数据流。

当RSVP请求抵达时，路由器必须对两个方面进行评估：可行性（也就是路由器是否具有满足请求的资源）和策略（也就是请求是否符合策略约束）。可行性是本地决策，而策略强制要求全局合作。

要实现全局策略，IETF使用两级模型，用C/S模式在两级之间交互作用。当路由器接收到RSVP请求时，它就变成客户，与服务器协商以确定请求是否符合策略约束，该服务器称为策略确定点（Policy Decision Point, PDP）。PDP不处理通信量，只对请求进行评估，检查它是否符合全局策略。如果PDP认可请求，则路由器必须作为策略执行点（Policy Enforcement Point, PEP）进行操作，确保通信量不会超过认可的策略。


COPS协议定义在路由器和PDP之间的C/S交互作用，或者如果组织有多级策略服务器，就定义路由器和本地PDP之间的C/S交互作用。虽然COPS定义它自己的报文首部，但是底层格式和RSVP共享许多具体字段。而且，对于请求报文中的单个数据项，COPS使用和RSVP一样的格式。这样，当路由器接收到RSVP请求时，它可以提取和策略相关的数据项，把它们放在COPS报文中，把结果发送给PDP。