Laura

版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://qinxp.blogbus.com/logs/13781574.html

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

-----------------------------------All Translation By Laura------------------------------

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

2.RTP使用细节

    接下来的部分将介绍RTP使用的一些方面，举例说明应用程序使用RTP时的一些基本操作，不限制RTP的使用场合。在这些例子中，RTP是基于IP和UDP的，并遵循在RFC 3551中确定的音频、视频框架特性。

-----------------------------------第5页---------------------------------

2.1简单多播音频会议

    IETF的一个工作组开会讨论了最新的协议文档，使用基于Internet的IP多播服务提供语音通信，通过分配机制，工作组获得一个多播组地址和一对端口。其中的一个端口用于语音数据，另一个用于控制(RTCP)包。这组地址和端口信息将分配给与会者。如果需要加密服务，数据和控制包可以按照9.1节的方式进行加密处理，在这种情况下，必须产生一个密钥并且将之分发。关于如何生成密钥以及分发的细节问题已经超出RTP的论述范围，这里不做赘述。

   音频会议的参与者使用音频会议应用程序来发送音频数据，音频数据按块来划分，假定每20ms为一块，每一块音频数据头部都加上RTP报头；RTP报头和数据又依次包含在UDP包中。RTP报头指明每个包中音频编码的类型(例如：PCM,ADCPM或者LPC，以便在会议过程中发送者可以随时更改编码类型，例如，当一个与会者通过低速链路参与会议，或者遇到网络拥塞时，可以通过更改编码方式来适应这种情况。

    Internet，和其他分组网络一样，因为随机的延迟，有时候会产生丢包和乱序的情况。为了应付这种不利情况，RTP报头附带了时间信息和序列号，以便接受者可以通过同步信息重构数据源发送的数据，所以，在这个例子里，音频数据包可以以20ms的间隔连续的播放说话者的声音。在会议中，每个RTP包可以通过同步信息被单独的重构并执行。接受者也可以通过序列号统计丢包率。

    因为工作组中的成员在会议过程中有可能加入和离开，所以有必要了解谁会一直参加会议，以及他们的音频质量如何，出于这个目的，会议中的每个音频程序通过在RTCP端口上附加上自己的用户名来周期性的广播接收报告。接收报告表明当前接收到的说话者的声音质量如何，也可以用于控制发送端的音频编码方式以适应网络状况。除了用户名外，也可以包含其他的鉴别信息，以用于带宽限制的控制。与会者可以通过发送BYE包来离开会议。

-----------------------------------第6页---------------------------------

    如果在会议中同时用到了音频和视频，他们将使用独立的RTP会话来传输。也就是说，独立的RTP和RTCP包将使用两对不同的UDP端口和(或者)多播地址来传输各自的媒体数据。在RTP的层次上，音频和视频会话并没有直接的耦合，除非与会者在两个会话的RTCP包上使用了相同的标识，这样，RTP会话才能关联起来。

    这样，把它们分开传输的目的，允许一些与会者可以选择只接收一种媒体。关于这个话题，在5.2中，将给出进一步的解释。尽管分开传输，但源端音频与视频在接收端的同步回放可以通过各自会话中RTCP包携带的时间信息来完成。

2.3混频器和转换器

    到目前为止，我们假定所有的与会者所要接收的媒体数据都为同一格式。然而，这并不总是行得通的。考虑到这样一种情况，某个区域的与会者是通过低速链路接入会议的，而大多数其他的与会者却拥有高速网络接入。与其让所有与会者降低语音编码质量，使用低速带宽，还不如在低速带宽的区域附近加上一个称为混频器的工作于RTP层次的设备。混频器在入口处将发送方发来的间隔为20ms的语音包进行同步重构，然后将之转换为一个能在低速链路上传输的音频流。这些包可能被传送到一个单独的接收者那里，也有可能通过多播传到多个不同的接收者。RTP报头有一个字段用于混频器识别源端，以使混合后的数据包能正确的传送到接收端。

   一些特定的语音会议与会者可能通过高带宽链路接入，但没有直接可获得的IP来通过多播接入。例如，他们可能在一个不允许任何IP数据包通过的应用级防火墙的后面，对这些点来说，并不需要混频器，而是需要另一种工作于RTP级的称为转换器的设备。这样的转换器需要两个，分别安装在防火墙的两端，连接在防火墙外部的转换器通过一个安全连接，将接收到的多播数据包传到位于防火墙内部的转换器上。内部转换器再将这些数据包以多播的形式发送给被限制在内部网上的多播组。

-----------------------------------第7页---------------------------------

    混频器和转换器可能是为了多个目的而设计。一个例子是，图像混合控制台摄取个人图像，得到单独的视频流，然后将之混合成一路视频流，来模拟一个工作组场景。另一个关于转换器的例子是，一组使用IP/UDP的主机要和另一组使用ST-IId的主机连接时，在他们之间需要转换器才能进行连接，抑或对来自独立视频源的没有同步和混频的数据进行逐包解码时，也需要转换器。混频器和转换器的操作细节见章节7。

2.4  分层编码

    多媒体应用程序应该可以根据接收者和网络拥塞来调整传输速率，部分应用把速率调整放在源端。这样的方法却不适用于多播传输，因为不同的接收端需求的带宽可能不一样，结果就像最小公分母一样，网络中带宽最小的节点决定了整个实况多媒体的质量和逼真度。
  
    所以，可以把分层编码与分层传输系统结合起来，把速率调整放到接收端。通过基于IP多播的RTP上下文，源端可以把这种改进的分层再划为分级的信号，即多条RTP会话，形成多个多播组，每条会话携带一个多播组的数据，接收端可以根据自己所在网络的的带宽，在众多的多播组中找到一个适合自己带宽的组加进去。

    在6.3.9，8.3和11节中，将会详细论述RTP的分层编码。