音视频媒体传输协议

1. 多媒体信息

1.1 多媒体信息的两个主要特点：

1. 信息量很大

   • 标准语音：64Kbits(8KHz采样，8位编码)
   • 高质量音频：3Mbps(100KHz采样，12位编码)

2. 在传输多媒体数据时，对时延和时延抖动均有较高要求

1.2 处理时延抖动：

缓存的方式在一定程度上消除了时延抖动，但是增加了时延，因为推迟播放了。

1.3 需要注意的问题

• 在传送时延敏的实时数据时，不仅传输时延不能大，时延抖动也必须限制
• 传送实时数据时，少量分组的丢失是可以容忍的
• 丢失容忍是实时数据的另一个重要特点。
• 发送多媒体数据时应当加一个序号，以按序还原和播放
• 增加一个时间戳，告诉接收端分组的产生时间。比如音频要和字母顺序对应上。

1.4 必须改造现有的互联网

• 大量使用高速路由器和光缆
• 完全改造现有协议，为端到端带宽预留，把无连接协议的互联网转变为面向连接的网络
• 少量改造现有协议，使得能适配这种数据传输

2. 流式存储音频、视频

存储音频/视频不是实时产生的，而是已经录制好的，通常存储在硬盘中。
第一种方式：
第二种方式：元文件

第三种方式：媒体服务器

2.1 下载时使用何种协议

采用UDP的缺点 ：

1. 网络情况多变，接收端很难始终按照规定的速率播放
2. 很多单位的防火墙往往阻拦外部UDP分组的进入
3. 使用UDP传送流媒体时，如果用户希望控制媒体的播放，暂停、快进等，还需要单独的RTP和RTSP协议

采用TCP的场景
现在，对流式存储音频/视频的播放，如YouTube都是采用TCP来传送。

采用UDP的场景：
如果是实时观看实况转播，应当首先考虑采用UDP来传送。

2.2 实时流式协议RTSP

实时流式协议RTSP（Real-Time Streaming Protocol）

• 应用层的多媒体播放控制协议，不传送数据
• 以客户服务器方式工作
• 使用户能对从互联网下载的实时数据进行控制，如暂停，快进，跳跃
• 又称为互联网录像机遥控协议
• RTSP 是有状态的协议，它记录客户机所处的状态（初始状态，播放状态）
• RTSP控制分组可在TCP上传送，也可在UDP上传送

3. 交互式音视频

3.1 实时传输协议RTP

• 实时传输协议RTP（RealTime-Transmission-Protocol）为实时应用提供端到端的运输，但不提供任何服务质量的保证。
• RTP不对音视频数据做任何处理，只是向应用层提供一些附加信息，让应用层知道应当如何处理。
• 音视频数据块先由RTP封装为RTP分组(也称为RTP报文)，再装入传输层的UDP用户数据报后，再向下递交给IP层。
• RTP端口号1025-65535之间选择一个未使用的偶数端口，同一次会话的RTCP则使用下一个奇数UDP端口号。但端口号5004和5005则分别用作RTP和RTCP的默认端口号。

3.2 RTP使用场景

3.2.1 多播音频会议

使用Internet的IP多播服务来进行语音通讯。通过一些分配机制，工作组主持人获得一个多播的组地址和一对端口。一个端口用于音频数据，另一个端口用于控制（RTCP）数据包。该地址和端口信息发布给预定的参与者。

每个与会者所使用的音频会议应用程序，都以small chunk形式（比方说20毫秒一段）来发送音频数据。每个音频数据块都前缀RTP报头；RTP报头和数据然后包含在UDP包中。RTP报头指明了各个包里音频编码的类型（如PCM, ADPCM,LPC），这样发送方可以在会议过程中改变编码格式，例如，为了要适应一个低带宽的参与者，或是要应付网络拥塞。

Internet，偶而会丢包和重排包。为应付这种损伤，RTP报头里包含时间戳和序列号，这样就允许接收方重构 发送方的时间轴。 还有序列号用来被接收方评估包丢失的数目。

由于会议期间不断有工作组成员加入或离开，因此有必要知道任一时刻的实际参与者及他们接收音频数据的状况好坏。出于这个目的，会议中每个音频应用程序，都周期性地多播一个附加着用户名的接收报告到RTCP端口。接收报告指明了当前说话者被收听到的状况，可用于控制自适应性的编码。除了用户名外，可以包含其他标识信息，只要符合控制带宽限制。一个参与者在离开会议时发送RTCP BYE包（章节6.5）。

3.2.2 音频和视频会议

一个会议如果同时使用音频和视频媒体，则二者传输时使用不同的RTP会话。也就是说，两种媒体中RTP包和RTCP包的传输，是使用两个不同的UDP端口对和（或）多播地址。在RTP层次，音频和视频会话没有直接的耦合。

这样分割的其中一个目的是允许一些会议参与者只接受自己选择的某一个媒体（或者音频，或者视频）。尽管两种媒体区分开来了，但通过两个会话RTCP包内载有的计时信息，同源的音频与视频还是能够同步回放。

3.2.3 混频器和转换器

我们皆假设所有站点都收到相同格式的媒体数据。然而这并不总是行得通。考虑一下这种情况，一个地方的参与者只能低速接入会议，而其他大部分参与者都能享受高速连接。与其让强迫大家都忍受低带宽，不如在只能低速接入的地方，放置一个减质量音频编码的RTP层次的中继（称作混频器）。混频器将重新同步输入的音频包，重建发送方产生的20ms固定间隔，混频已重建过的音频流为单一的流，转换音频编码为低带宽格式，最后通过低带宽连接转发数据包流（package stream)。这些包可能被单播到一个接收方，也可能多播到另一个的地址而发给多个接收方。RTP报头为混频器提供了一种方法，使其能辨识出对混频后的包有用的源，从而保证提供给接收方正确的说话者指示。

在音频会议中，一些预定参与者尽管有高带宽连接，但不能通过IP多播直接接入会议。例如，他们可能位于一个不允许任何IP包通过的应用层防火墙后面。对这些站点，可能就不需要混频，而需要另一种称为转换器的RTP层次中继。可以在防火墙两侧分别安装一个转换器，外侧转换器将所有多播包通过安全连接转入内侧转换器，内侧转换器再转发给内部网的一个多播组（multicast group)。

混频器和转换器可以设计成用于各种目的。比如，一个视频混频器在测量多个不同视频流中各人的单独影像后，将它们组合成一个单一视频流来模拟群组场景。又如，在只用IP/UDP和只用ST_II的两个主机群之间通过转换建立连接。再如，在没有重新同步或混频时，用packet-by-packet编码转换来自各个独立源的视频流。

3.3 RTP的层次

3.3.1 RTP分组的首部

1. P：填充位flag
2. X：表示RTP首部后还有扩展首部
3. 参与源数：给出后面参与源标识符的数目
4. M：表示这个RTP分组是否有特殊意义。比如在传送视频流时用来表示每一帧的开始
5. 有效载荷类型：指出后面的RTP数据属于何种格式的应用。收到RTP分组的应用层就根据此字段指出的类型进行相应的处理。
6. 序号：对每一个发送的RTP分组，其序号加1，在一次RTP会话开始时的初始序号是随机选择的。序号使接收端能发现丢失的分组。
7. 时间戳：反应当前RTP分组中数据的第一个字节的采样时刻。在一次会话开始时时间戳是随机选择的，后续按偏移即可。接收端使用时间戳可以准确知道应当在什么时间还原哪个数据块，从而消除时延的抖动，还可以用来使得视频应用中声音和图像同步。
8. SSRC：用来标识RTP流的来源，类似于streamID.有多个RTP流复用同一个UDP用户数据报时，使用SSRC可使得接收端的UDP能够将收到的RTP流送到各自的终点。
9. CSRC：一个32位数，最多15个。用来标志来源于不同地点的RTP流。在多播环境中，可以使中间的一个站把发往同一个地点的多个RTP流混合成一个流，在目的站再根据CSRC的数值把不同的RTP流分开。

3.3.2 复用RTP会话

独立的音频和视频流不应该在一个RTP会话中传输，然后根据负载类型或SSRC来解除复用。单纯使用负载类型区别的问题：

• 两个共用相同RTP会话和相同SSRC标识的音频流，其中一个改变了编码，由此需要一个不同的负载类型。这时就没有办法来识别究竟是哪个音频流改变了编码。
• SSRC标示符是被定义用来确定一个单一的时序和序列号空间。如果媒体的时钟频率不同，那么交错的多种媒体负载类型需要不同的时序空间和不同的序列号空间，由此来指出哪种负载类型发生了数据包丢失。
• RTCP发送方和接受方报告只能对每一个SSRC标示符表述一种时序和序列号空间，并且不能加载负载类型域。
• RTP混合器不能够将不兼容的交叉流合并到一种数据流中。
  为每一种媒体采用一个不同的SSRC标示符，但是仍然将他们放在一个RTP会话中传输可以避免前两个问题，但无法避免最后两个。

3.3.3 RTP头扩展

RTP提供扩展机制以允许实现个性化：某些与负载格式独立的功能要求的附加信息在RTP数据包头中传输。RTP头扩展的格式如下图所示

     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头中的扩展比特位置1，则一个长度可变的头扩展部分被加到RTP固定头之后。RTP固定头之后只允许有一个头扩展

• length: 指示扩展项中header extension的长度，不包括4个字节扩展头。
• defined by profile：为允许多个互操作实现独立生成不同的头扩展，或某种特定实现有多种不同的头扩展，扩展项的前16比特用以识别标识符。

3.4 实时传输控制协议RTCP

RTCP(RTP control Protocol)是与RTP配合使用的协议，与RTP协议不可分割。
主要功能：

• 服务质量的监视和反馈 。反馈可能对自适应编码有直接作用，向所有参与者发送接收反馈报告可以使"观察员"评估这些问题是局部的还是全局的。反馈功能通过RTCP发送者报告和接收者报告实现。
• 媒体间的同步 。RTCP为每个RTP源携带一个固定的传输层识别符，称为规范名（CNAME）。当发生冲突或程序重启时SSRC可能改变，因此接收者要用CNAME来跟踪每个成员。接收者还要用CNAME关联来自同一个成员的多个数据流，例如同步语音和图像。媒体间的同步还需要数据发送者发送的RTCP包中的NTP和RTP时间戳。
• 传输最基本的会话控制信息 。例如在用户界面上显示参与者的标识。这最可能在"松散控制"的会议中起作用，在"松散控制"会议里，成员可以不经过资格控制和参数协商而加入或退出会议。RTCP只是作为一个可以到达所有参与者的方便通道，但是不期望其支持所有的控制功能

3.2.1 RTCP分组(RTCP报文)

• RTCP分组使用UDP传送，但不对音频视频分组进行封装。
• 可将多个RTCP分组封装在一个UDP用户数据报中。
• RTCP分组周期性地在网上发送，它带有发送端和接收端对服务质量的统计信息报告。
  
  多个RTCP包可以形成一个复合RTCP包，在UDP传输时，通常都是将复合包作为一个包传输的。在RTCP复合包中不明确指定有多少个RTCP包，而是依靠底层协议提供的总长度来决定该符合包的结束。

       if encrypted: random 32-bit integer
||

       |[--------- packet --------][---------- packet ----------][-packet-]
||

       |                receiver            chunk        chunk
       V                reports           item  item   item  item
       --------------------------------------------------------------------
       R[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why]
       --------------------------------------------------------------------
||
|---|
|<--------------------------  UDP packet ------------------------->|

    
       #: SSRC/CSRC identifier
    
              Figure 1: Example of an RTCP compound packet
    
    
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
    

复合包中的每个RTCP包可以单独处理，而无需考虑包复合的顺序。然而，为了实现RTCP协议的某些功能，添加以下限制：

• 接收统计信息(SR或RR)只要带宽允许应该尽可能经常的发送，已达到统计的最大分辨率。因此每个周期发送的RTCP复合包必须包含一个报告包。
• 新的参与者需要尽快接收一个源的规范名以识别数据源并开始关联媒体以实现音视屏同步。因此，每个包中必须包含SDES CNAME，除非复合包被分割以进行部分加密。
• 必须限制首次在复合包中出现的包类型的数目，以增加在第一个字中常数比特的数目，这样可以增加RTCP包的有效性，以区分误传的RTP包和其他无关的包。

因此，所有RTCP包必须以复合包的形式发送。复合包中至少有两个RTCP包。具有以下格式：

• 加密前缀：当且仅当复合包被加密时，对每个RTCP复合包前缀一个32位随机数。如果加密需要padding，必须添加到复合包的最后一个封包中。
• SR或RR：复合包中的第一个RTCP包必须是一个报告包，以利于附录A.2中描述的头部验证。即使还没有数据发送和接收，该限制也是适用的。此时必须发送一个空的RR包，同样必须在复合包中搭配一个其他的RTCP包，即使是BYE。
• 额外的RR：若被报告的接收统计源数目超过SR/RR包中最大允许的31个，附加的RR必须跟在最初的报告包后面。
• SDES：除了9.1节描述的情况外，每个RTCP复合包都必须包含一个SDES包。
• BYE或APP：其他RTCP包类型（非SR/RR/SDES packet），包括那些尚未定义的，可以遵循任何顺序，除了BYE必须是最后一个封包(每个BYE包都包含一个给定的SSRC/CSRC)。

每个RTP参与者在一个报告间隔内应只发送一个RTCP复合包，以便正确估计每个参与者的RTCP带宽。除非像9.1节描述的情况——把一个RTCP复合包分割以进行加密。如果数据源的个数太多，以至于不能把RR包都放到同一个RTCP复合包中而不超过路径MTU，那么可在每个间隔中发送RR包的子集。在多个发送间隔中，所有的RR包应该被等概率的选中，这样就可以报告所有数据源的接收数据的情况。要注意的是每个RTCP复合包必须以SR或RR包开头。

3.2.2 RTCP传输间隔

RTP被设计为自动适应不同规模的会话——从几个参与者到几千个参与者不等。例如在一个音频会议中，数据流量本身是自我限制的，因为同时只会有一两个人说话。尽管如此，RTCP却不是自我限制的，随着参与人数的增加，RTCP控制流量也会随着线性增长。因此必须动态调整RTCP报文的发送间隔。

在涉及媒体应用时，会话带宽参数最好由一个会话控制应用提供。但媒体应用可能设置一个默认参数，此参数由单个发送者选择的编码方式的数据带宽算出。会话管理可能会基于多播范围的规则或其他标准确定带宽限制。所有的参与者应使用相同的会话带宽值以保证计算出相同的RTCP间隔。

控制传输带宽（RTCP所使用的带宽）应当是会话带宽的一小部分，这部分所占总的会话带宽的百分比应是已知。建议RTCP控制传输带宽为RTCP会话带宽的5%。其中的1/4分配给发送者；当发送者的比例超过所有参与者的1/4时，其RTCP控制带宽相应增加。所有的会话参与者必须使用相同的常数（以上提到的百分比），以便计算出相同的发送时间间隔。这些常数应在一个特殊的描述文件中确定。
计算出的RTCP复合包的发送时间间隔应该有一个下限，以免参与者数量较少时大量发送RTCP包。在应用开始时，一个延迟应加到第一个的TCP复合包发送之前，以便从其他参与者接收RTCP复合包。这样，发送时间间隔能更快的收敛到正确的值。这个延迟可以设为最小时间间隔的一半。固定的时间间隔建议为5秒。

一个实现可能使RTCP最小发送时间间隔与会话带宽参数成比例。则应满足下列约束：

• 对多播会话，只有活动的数据发送者使用减小的最小化的值计算RTCP复合包的发送时间间隔

• 单播会话，减小的值也可能被不是活动的数据发送者使用，发送初始的RTCP复合包之前的延迟可能是0。

• 对所有会话，在计算参与者的离开时间时，这个固定最小值会被用到。因此，不使用减小的值进行RTCP包的发送，就不会被其他参与者提前宣布超时。

• 减小的最小时间间隔建议为：360/sb(秒)，其中sb：会话带宽（千字节/秒）。当sb>72kb/s时，最小时间间隔将小于5s。
  6.3节所描述的算法和附录A.7将实现本节列出的目标：
  计算出的RTCP包的时间间隔与组中参与者的人数成正比。（参与者越多，发送时间间隔越长，每个参与者占有的RTCP带宽越小）。

• RTCP包的（真实）时间间隔是计算出的时间间隔的0.5～1.5倍之间某个随机的值，以避免所有的参与者意外的同步。

• RTCP复合包的平均大小将会被动态估计，包括所有发送的包和接收的包。以自动适应携带的控制信息数量的变化。

• 由于计算出的时间间隔依赖于组中的人数。因此，当一个的用户加入一个已经存在的会话或者大量的用户几乎同时加入一个新的会话时，就会有意外的初始化效应。这些新用户将在开始时错误的估计组中的人数（估计太小）。因此他们的RTCP包的发送时间间隔就会太短。如果许多用户同时加入一个会话，这个问题就很重要了。为了处理这处问题考虑了一种叫“时间重估”的算法。这个算法使得组中人数增加时，用户能够支持RTCP包的传输。

• 当有用户离开会话，不管是发送BYE包还是超时，组中的人数会减少。计算出的时间间隔也应当减少。因此，应用“逆向重估”算法，使组中的成员更快的减少他们的时间间隔，以对组中的人数减少做出响应。

• BYE包的处理和其他RTCP包的处理不同。BYE包的发送用到一个“放弃支持”算法。以避免大量的BYE包同时发送，使大量参与者同时离开会话。
  这个算法适用于所有参与者都允许RTCP包的情况。此时，会话带宽＝每个发送者的带宽×会话中参与者的总人数。详细算法见随后小节，附录A.7给出了算法的一个实现。

3.2.3 维持会话成员的人数

当侦听到新的站点的时候，应当把他们加入计数。每一个登录都应在表中创建一条记录，并以SSRC或CSRC进行索引。新的登录直到接收到含有SSRC的包或含有与此SSRC相联系的规范名的SDES包才视为有效（见附录A.1）。当一个与SSRC标识符相对RTCP BYE包收到时，登录会被从表中删除。除非一个“掉队”的数据包到达，使登录重新创建。
如果在几个RTCP报告时间间隔内没有RTP或RTCP包收到，一个参与者可能标记另外一个站点静止，并删除它。这是针对丢包提供的一个很强健的机制。所有站点对这个超时时间间隔乘子应大体相同，以使这种超时机制正常工作。因此这个乘子应在特别的描述文件中确定。
对于一个有大量参与者的会话，维持并存贮一个有所有参与者的SSRC及各项信息的表几乎是不可能的因此，只可以只存贮SSRC。其他算法类似。关键的问题就是，任何算法都不应当低估组的规模，虽然它有可能被高估。

3.2.4 RTCP包的发送和接收规则

下面列出了如何发送RTCP包，当接收到的TCP包时该干什么的规则。
为执行规则，一个会话参与者需要维持下列变量：
tp: RTCP包发送的最后时间。
tc: 当前时间。
tn: 估计的下一个RTCP包要发送的时间。
pmembers: tn最后被重新计算时，会计的会话成员的人数。
members: 会话成员人数的当前估计。
senders: 会话成员中发送者人数的估计。
rtcp_bw: 目标RTCP带宽。例如用于会话中所有成员的RTCP带宽。单位bit/s。这将是程序开始时，指定给“会话带宽”参数的一部分。
we_sent: 自当前第二个前面的RTCP发送后，应用程序又发送了数据，则此项为true。
avg_rtcp_size: 此参与者收到的和发送的RTCP复合包的平均大小。单位：bit。按6.2节，此大小包括底层传输层和网络层协议头。
initial: 如果应用程序还未发送RTCP包，则标记为true

3.2.5 计算RTCP传输时间间隔

一个会话参与者包的平均发送时间间隔应当和所在会话组中人数成正比。这个间隔称为计算时间间隔。它由上面提到的各个状态参量结合起来计算得出。计算时间间隔T的计算如下：
1．（1）如果发送者人数≤会话总人数×25%。则T取决于此参与者是否是发送者（we_sent的值）；否则，发送者和接收者将统一处理。

此处可能少个公式

RTP描述文件可能用两个独立的参数（S，R）确定发送者与非发送者。此时，25%和75%只要相应的换成S/(S+R),R/(S+R)即可。注意R＝0的情况。
2．如果initial为true(则未发送过RTCP包)，则设Tmin=2.5s;否则设Tmin=5s。
3．决定性时间间隔（deterministic calculated interval）Td=max(Tmin, n _c)。
4. 实际发送间隔T=Td_λ；其中λ~U(0.5,1.5)。即λ服从0.5到1.5之间的均匀分布。
5. T=T/(e-0.5)≈T/1.21828，补偿时间重估算法，使之收敛到比计算出的平均RTCP带宽小的一个值。
这个算法产生了一个随机的计算时间间隔，并把至少25%的RTCP带宽分配给发送者，其余的分给接收者。若发送者超过会话总人数的25%，此算法将把带宽平均分给所有的参与者。

3.2.6 初始化

一加入会话，参与者的各状态参量初始化为：tp=0； tc=0； senders=0； pmembers=1； members=1； vw_sent=false； rtcp_bw:由会话带宽参数的相应部分得到；initial=true；avg_rtcp_size:初始化为应用程序稍后将发送的RTCP包的可能大小；T：如6.3.1节；tn=T（这意味着，一个计时器将经T时间后被唤醒）；应用程序可以用任何它需要的方式实现计时器。
参与者把它自己的SSRC加到成员列表中。

3.2.7 接收到RTP包或非BYTE的RTCP包

当收到一个参与者的RTP或RTCP包时，若其SSRC不在成员列表中，将其SSRC加入列表；若此参与者被确认有效（如6.2.1节描述），就把列表中成员的值更新。对每个有效的RTP包中的CSRC执行相同的过程。
当收到一个参与者的RTP包时，若其SSRC不在发送者列表中，则将其SSRC加入发送者列表，更新相应的值。
每收到一个RTCP复合包，avg_rtcp_size更新为avg_rtcp_size = 1/16 * packet_size + 15/16 * avg_rtcp_size ；其中packet_size是刚收到的RTCP复合包的大小。

3.3 H.323

3.3.1 H.323的体系架构

3.3.2 H.323指明的四种构件

3.4 会话发起协议SIP

3.4.1 SIP系统的构件

3.4.2 SIP过程

3.4.2.1 SIP登记器

3.5 会话描述协议SDP