文章目录
- 前言
- 多媒体网络
-
- [IP 语音](#IP 语音)
-
- 尽力而为服务的限制
- 在接收方消除音频的时延抖动
- 从丢包中恢复
- [学习案例：使用 Skype 的 VoIP](#学习案例：使用 Skype 的 VoIP)
- 实时会话式应用的协议
- 参考目录
前言
阅读本文前请注意最后编辑时间，文章内容可能与目前最新的技术发展情况相去甚远。欢迎各位评论与私信，指出错误或是进行交流等。
本文是关于《计算机网络：自顶向下方法（第七版）》的学习分享，内容书写顺序也是按照书中的顺序。本文并不会提及书中的所有内容，主要写重点的知识，以及自己感兴趣的内容。会对原文中的内容进行一定的精简，或者加上个人的理解。
多媒体网络
IP 语音
经因特网的实时会话式语音经常被称为因特网电话 (Internet telephony) , 因为从用户的视角看，它类似于传统的电路交换电话服务。 它通常也被称为 IP语音 (Voice-over-IP , VoIP) 。 在本节中我们描述 VoIP 所依据的原则和协议。 会话式视频在许多方面类似于VoIP, 为了使讨论重点突出且具体，我们这里仅关注语音，而不是语音和视频的结合＿
尽力而为服务的限制
因特网的网络层协议IP提供了尽力而为的服务。 那就是说服务尽全力将每个数据报从源尽可能快地移动到目的地，但是没有就在某些时延界限内使分组到达目的地或丢包百分比的限制做任何承诺。 缺失这种保证对实时会话式应用的设计提出了严峻挑战，这些应用对分组时延、时延抖动和丢包非常敏感。在本节中，我们将讨论加强VoIP性能的几种方式。 我们的重点将在应用层技术上，即这些技术并不要求在网络核心甚至在端系统的运输层有任何变化。 为了使讨论具体，我们将讨论在一个特定的 VoIP例子。 发送方以每秒8000字节的速率产生字节，且每20ms将字节汇聚成块。 每个块和一个特殊的首部封装在一个UDP报文段中。 因此， 一个块中的字节数为 (20ms) x (8000 字节／秒） = 160 字节，每20ms 发送一个 UDP报文段。
如果每个分组以恒定的端到端时延到达接收方，那么分组每隔20rns 就能周期性地到达接收方。 在这种理想的清况下，只要每个块一到达，接收方就能直接播放它。 但不幸的是，某些分组可能丢失，大多数分组没有相同的端到端时延，即使在一个轻度拥塞的因特网中也是如此。 因此，接收方必须更仔细地判断： 1.什么时候播放一个块； 2.如何处理一个丢失块。
- 丢包
考虑由 VoIP应用产生的一个 UDP报文段。 这个UDP报文段封装在 lP数据报中。 当数据报在网络中徘徊时，在它等待出链路传输时要经过路由器的缓存（即队列）。 从发送方到接收方的路径上的一个或多个缓存有可能是满的，不能接纳该IP数据报。 在这种情况下，这个IP数据报就被丢弃了，永远不会到达接收方的应用程序。
通过TCP (它提供了可靠数据传输）而不是 UDP发送分组，可以消除丢失问题。 然而， 重传机制对于诸如VoIP这样的会话式实时音频应用，通常认为是不可接受的．因为它们增加了端到端时延。 此外， 当丢包后，由于TCP 的拥塞控制，发送方的传输速率可能减少到低于接收方的排空速率，可能导致缓存＂饥饿＂。 这可能会对接收方的语音可理解程度产生严重影响。 由于这些原因，几乎所有现有的 VoIP应用默认运行在 UDP上。报告称 Skype 使用了 UDP, 除非用户位于阻碍 UDP 报文段的 NAT 或防火墙之后（这时使用TCP)。
但是分组的丢失并不一定会造成人们想象中的灾难。 实际上，取决于语音是如何编码和传输的以及接收方隐藏丢包的方式， 1% ~20%的丢包率是可以忍受的。 例如，前向纠错 (FEC) 能够有助于隐藏丢包。 我们后面可以看到，通过使用FEC, 将冗余信息和初始信息一起传输，以便能够从冗余信息中恢复一些丢失的初始数据。 无论如何，如果发送方和接收方之间的一段或多段链路严重拥塞，丢包率超过 10% ~ 20% (例如在无线链路上），那么无论采取何种措施都无法获得可以接受的声音质量了。 显然，尽力而为服务有它的局限性。 - 端到端时延
端到端时延 (end-to-end delay) 是以下因素的总和：路由器中的传输、 处理和排队时延，链路中的传播时延和端系统的处理时延。 对于实时会话式应用，例如VoIP, 听电话的人对于小于 150ms 的端到端时延是觉察不到的；在 150rns 和400ms 之间的时延能够接受，但是不够理想；超过400ms 的时延可能严重妨碍语音谈话的交互性。 VoIP应用程序的接收方通常忽略时延超过特定阈值（例如超过400ms) 的任何分组。 因此，时延超过该阈值的分组等效于丢弃。 - 分组时延抖动
端到端时延的一个关键成分是一个分组在网络路由器中经历的变化的排队时延。 由于这些可变的时延，从在源中产生分组到它在接收方收到的这段时间，对于不同的分组可能会有波动， 这个现象称为时延抖动 (jitter)。 举一个例子，考虑在 VoIP应用中两个连续的分组。发送方在发送第一个分组20ms之后发送第二个分组。 但是在接收方，这两个分组之间的间隔可能变得大于20ms。 为了理解这一点，假设第一个分组到达路由器的一个几乎为空的队列，但是恰好在第二个分组到达该队列之前，从其他源来的大量分组也到达了相同的队列。 因为在这个路由器中第一个分组经受了很小的排队时延，而第二个分组经受了较大的排队时延，这两个连续的分组之间的时间间隔变得大于20ms 了。两个连续分组的间隔也可能会小于20ms。为了理解这种情况，再次考虑两个连续的分组。假设第一个分组加入一个有大量分组队列的队尾，并且第二个分组到达这个队列时第一个分组尚未被传输，而且来自其他源的分组尚未到达该队列。 在这种情况下，这两个分组发现它们在队列中互相紧挨着。 如果在路由器的出链路传输一个分组所需时间小于20ms,则第一个分组和第二个分组的间隔就变得小于20ms了。
如果接收方忽略了时延抖动的存在， 一旦该块到达就开始播放，那么在接收方产生的音频质量很容易变得不可理解。 幸运的是， 时延抖动通常可以通过使用序号 (sequence number) 、 时间戳 (timestamp) 和播放时延 ( playout delay) 来消除，如下面所讨论的内容。
在接收方消除音频的时延抖动
对于 VoIP 应用、周期性地产生分组，接收方应该在存在随机网络时延抖动的情况下尝试提供播放语音块。这经常通过结合下面两种机制来实现：
• 为每个块预先计划一个时间戳 (timeslamp)。 发送方用每个块产生的时刻为它加上时间印记。
• 在接收方延迟播放 (delaying playout) 块。 如我们前面讨论所见，接收的音频块的播放时延必须足够长．以便大多数分组在它们的预定播放时间之前被接收到。 这个播放时延可能在整个音频会话期间是固定的，或者在音频会话生命期中适应性地变化。
我们现在讨论如何结合机制来减轻甚至消除时延抖动的影响。 我们研究两种播放策略：固定播放时延和适应性播放时延。
- 固定播放时延
使用固定播放时延策略，接收方试图在块产生正好q ms后播放它。 因此如果一个块在时刻t 打上时间戳，接收方在时刻t+q播放这个块，假设这个块在那个时间已经到达。在预定播放时间之后到达的分组将被丢弃，并被认为已经丢失。
q 选择什么值为好呢？尽管使用更小的q值可以获得更令人满意的会话体验，但VoIP能够支持高达约400ms 的时延。 另一方面，如果q 比400ms小得多，那么由于网络引入的分组时延抖动会使许多分组可能错过了它们的预定播放时间。 概括地说，如果端到端时延经常发生大的变化，用一个大的 q更好；另一方面，如果时延很小并且时延变化也很，用一个较小的、 可能小于150ms 的 q更好。 - 适应性播放时延
当使用固定播放时延来设计播放策略时，若初始播放时延设置得比较大，大多数分组能在它们的截止时间内到达，因此存在的丢失将可忽略不计； 然而，对于如VoIP这样的会话式服务，长时延即使不是不能忍受的，至少也是令人厌恶的。 在理想情况下，我们希望播放时延最小化，使丢包低于一定百分比的限制。
处理这种折中的自然方法是估计网络时延和网络时延变化，并且在每个话音突峰期的开始相应地调整播放时延。 在话音突峰期开始时适应性地调整播放时延将导致发送方静默期的压缩和拉长； 然而，静默期的少量压缩和拉长在谈话中是不易觉察的。
我们现在描述一种接收方可以用于适应性地调整它的播放时延的通用算法。 为此，令
ti=笫 i 个分组的时间戳 ＝该分组在发送方产生的时间
ri =分组 i 被接收方接收的时间
pi = 分组 i 在接收方播放的时间
第 i 个分组的端到端网络时延是ri- ti,。 由于网络时延抖动，这个时延在不同的分组之间会发生变化。 令di 表示接收到第i个分组时的平均网络时延的估计值。 这个估计值根据如下的时间戳来构造：
di = (1 - u) di-1 + u ( ri - ti)
式中 u 是一个固定的常数（例如， u= 0. 01 ) 。这样 di 是观察到的网络时延的一个平滑均值。 这个估计值为最近观察到的网络时延设置了比过去一段时间观察到的网络时延有更大的权重。 令v, 表示 平均网络时延 与 真实网络时延 的平均偏差值。 这个估计值也可从这些时间戳构建：
vi= (1 - u) vi-1 + u | ri - ti - di |
一旦计算完了这些估计值，接收方为分组播放应用下列的算法。 如果分组i是一个话音突峰期的第一个分组，它的播放时间pi计算如下：
pi = ti + di + Kvi
这里 k是一个正的常数 （例如 K= 4) 。Kvi目的是给将来设置足够大的播放时间，以便话音突峰期中 有一小部分分组由于迟到而丢失。 在一个话音突峰期中任何后续分组的播放点被计算为对于这个话音突峰期的第一个分组播放时间点的偏移。
从丢包中恢复
我们已经较为详细地讨论了一个 VoIP应用能够怎样处理分组时延抖动。 我们现在简要地描述在存在丢包的情况下几种试图保护可接受的音频质量的方案。 这样的方案被称为丢包恢复方案 (loss recovery scheme) 。 这里我们定义了广义的丢包：如果某分组不能到达接收方或者在它设定的播放时间之后才到达，该分组则丢失。 我们再次用 VoIP例子作为描述丢包恢复方案的环境。在诸如 VoIP 等会话式实时应用中，重传丢失的分组通常是不可行的。 的确，重传一个已经错过了播放截止时间的分组是绝对没有意义的。 而且重传一个在路由器队列溢出的分组通常不能足够快地完成。 由于这些考虑， VoIP应用通常使用两种类型的丢包预期方案是前向纠错 (Forward Error Correction , FEC ) 与交织 (interleaving) 。
- 前向纠错
FEC 的基本思想是给初始的分组流增加冗余信息。 以稍微增加传输速率为代价，这些冗余信息可以用来重建一些丢失分组的近似或者准确版本。 我们简单概括两种简单的 FEC 机制。 第一种机制是每发送 n 个块之后发送一个冗余编码的块。 这个冗余块通过异或n个初始块来获得。 以这种方式，在这n+1 个分组的组中，如果任何一个分组丢失，接收方能够完全重建丢失的分组。 但是如果这一组中有两个或更多分组丢失，接收方则无法重建丢失的分组。 通过让组的长度n+1 比较小， 当丢失不是很多时，大部分丢失分组都可以恢复。 此外，这个简单的方案增加了播放时延，因为接收方在能够开始播放之前，必须等待收到整个组的分组。 有关FEC在多媒体传输上如何工作的更多实践细节
参见 [RFC 5109] 。
第二个FEC 机制是发送一个较低分辨率的音频流作为冗余信息。 例如，发送方可能创建一个标准的音频流和一个相应的低分辨率、 低比特率的音频流。 （这个标准流可能是一个64kbps 的 PCM 编码，而这个较低质量的流可能是一个 13kbps 的 GSM 编码。）这个低比特率流被认为是冗余信息。 如图9-5 所示．发送方通过从这个标准流中取出第n个块并附加上第 (n-1) 个块的冗余信息，以构建第n个分组。 以这种方式，只要没有连续分组的丢失，接收方都可以通过播放和后续分组一起到达的低比特率编码块来隐藏丢失。 当然，低比特率块比标准块的质量要低。 然而，在一个流主要是由高质量块组成、偶尔出现低质量块并且没有丢失的块的情况下，其整体的音频质量良好。 注意到在这种方案中，接收方在播放前只需接收两个分组，因此增加的时延小。 此外，如果低比特率编码比标准编码少得多，那么传输速率的额外增加并不大
为了处理连续丢失，我们能够使用一个简单的修正方案。 发送方不再仅为第n个标准块附加上第 (n-1) 个低比特率块，而是附加上第 (n- 1) 个和第 (n-2) 个低比特率块，或者附加第 (n-1) 个和第 (n-3) 个低比特率块等等。 通过给每个标准块附加上更多低比特率块，在各种恶劣的尽力而为服务环境下接收方的音频质量变得可接受。 在另一方面，附加的块增加了传输带宽和播放时延。 - 交织
作为冗余传输的另一种替代方案， VoIP应用可以发送交织的音频。如图9-6所示，发送方在传输之前对音频数据单元重新排序，使得最初相邻的单元在传输流中以一定距离分离开来。 交织可以减轻丢包的影响。 例如，如果每个单元长为5ms, 块是20ms (也就是每个块4个单元），那么第一个块可能包含1、 5、 9 和 13单元；第二个块可能包含2、 6、 10和 14 单元等等。图9-6 显示了一个交织流的单个丢包导致重建流中的多个小间隙，这与在非交织流中将会导致单个大间隙形成对照。
交织能够明显地提高音频流可感觉到的质量。 它的开销也较低。 交织明显的缺点是增加了时延。 这限制了它在如 VoIP这样的会话式应用中的使用，然而它能够很好地处理流式存储音频。 交织的一个主要优点是它不增加流的带宽需求。 - 差错掩盖
差错掩盖方案试图为丢失的分组产生一个与初始分组类似的替代物。 因为音频信号（特别是语音）呈现出大量的短期自相似性，故该方案是可行的。 正因为如此，这些技术适合于工作在相对小的丢包率 （低于 15%) 和小分组 (4 ~40ms) 的情况。 当丢失长度接近音频的长度 (5 ~ 100ms) 时，这些技术就失效了。
也许基于接收方的恢复的最简单方式是分组重复。 即用在丢失之前刚到达的分组的副本来代替丢失的分组。 这种方法的计算复杂度低，并且工作得相当好。 基于接收方恢复的另一种形式是内插法，它使用在丢失之前和之后的音频内插形成一个合适分组来隐藏丢失。 内插法比分组重复稍微好一些， 但是显然需要更高的计算强度。
学习案例：使用 Skype 的 VoIP
Skype 是一个流行的VoIP 应用，每天都有超过5000 万个活跃的账户。 Skype 除了提供主机到主机的VoIP服务，还提供主机到电话的服务， 电话到主机的服务，以及多方主机到主机的视频会议服务。 （这里，主机仍然是任一种因特网连接IP设备，包括PC平板电脑和智能手机。） Skype 于2011 年被微软公司收购。
因为Skype 协议是专用的，并且因为所有 Skype 的控制和媒体分组是加密的，所以精确地确定Skype 的工作过程是非常困难的。 无论如何， 从Skype 的 Web 网站和几项测量研究，研究人员已经知道了 Skype 总体上是怎样工作的。 对于语音和视频， Skype 客户都有许多自行支配的不同编解码器，这些编解码器能够以宽泛的速率和质量对媒体进行编码。 例如，测量表明 Skype 的视频速率从用于低质量会话的低至30kbps 到用于高质量会话的高至 1Mbps左右。 一般而言， Skype 语音质量好于由有线电话系统提供的 "POTS（简单老式电话服务）"的质量。 (Skype编解码器通常以 16000 样本／秒或更高速率对语音抽样，这提供比 POTS 更为丰富的音色， POTS 的抽样率为 8000/秒。）在默认状态下，Skype 通过 UDP 发送音频和视频分组。 然而，控制分组经TCP 发送、并且当防火墙阻挡UDP 流时，媒体分组也通过 TCP发送。 Skype 对于经 UDP发送的语音和视频流使用 FEC处理丢包恢复。 Skype 客户还通过选择视频质量和 FEC 开销，使它所发送的音频和视频流适应当前的网络情况。
Skype 以一些创新方式使用 P2P技术，很好地阐述了P2P是如何应用于除内容分发和文件共享之外的应用中的。 主机到主机因特网电话应用了P2P技术，因为用户对（即对等方）彼此实时通信。 但是Skype也对两个其他重要功能应用了 P2P技术，这两个功能是用户定位和 NAT穿越。
如图9-7 所示， Skype 中的对等方（主机）组织成为一个等级制覆盖网络，其中每个对等方分类为超级对等方和普通对等方。 Skype维护一个索引，该索引将 Skype 用户名映射为当前的IP地址（和端口号）。 该索引经过超级对等方分发。 当 Alice 要呼叫 Bob 时，她的客户端搜索该分布式索引以决定Bob 的当前IP地址。 因为Skype 协议是专用的，所以当前并不知道该索引映射是怎样跨越这些超级对等方进行组织的，采用某种形式的 DHT组织结构是非常可能的。
P2P技术也被用于Skype 中继 (relay) 中，中继对于创建家庭网络中主机之间的呼叫是有用的。 许多家庭网络配置提供通过NAT接入因特网。 前面讲过NAT 防止来自家庭网络外部的主机发起的对家庭网络内部主机的连接。 如果两个Skype 呼叫方都具有NAT, 则存在一个问题，即任一方都不能接受由其他一方发起的呼叫，使得呼叫看起来不可能实现。 明智地使用超级对等方和中继很好地解决了这个问题。 假设
当 Alice 注册进入系统，她被指派了一个非 NAT的超级对等方并对那个超级对等方发起一个会话。 （因为是 Alice 发起了该会话，所以她的 NAT允许该会话。）这个会话允许Alice和她的超级对等方交换控制报文。 当 Bob 注册进入系统时发生了同样的事情。 此时， 当Alice 要呼叫 Bob, 她通知她的超级对等方，超级对等方依次通知 Bob 的超级对等方， Bob的超级对等方依次通知 Bob 说 "Alice的呼叫到了＂。 如果 Bob 接受了该呼叫，这两个超级对等方选择一个第三方非 NAT 超级对等方（即中继对等方），中继对等方的工作是中继 Alice和Bob 的数据。 Alice 和 Bob 的超级对等方则分别指示Alice 和 Bob 与该中继发起会话。 如图 9-7 所示， Alice 经过连接向该中继发送语音分组（该连接由 Alice 发起），并且中继到 Bob转发这些分组（该连接由 Bob 发起）；从Bob 到 Alice 的分组反方向地流经相同的两条中继连接。 瞧! Bob 和 Alice 有了一条端到端连接，即使他们都不能接受一条源千外部的会话。
到现在为止，我们有关Skype 的讨论关注涉及两人的呼叫。 现在我们观察多方音频会议呼叫。 对于N>2个参与者，如果每个用户希望向每个其他N-1 个用户发送它的音频流的一个副本，则总共有N(N-1) 个音频流将需要发送到网络中去， 为了减少这种带宽使用. Skype 应用了一种明智的发送技术。 具体而言，每个用户向会议发起方发送它的音频流。 会议发起方将这些音频流结合为一个流（基本上是将所有的音频信号加在一起），然后再向每个其他N- 1 个参与者发送每个结合流的一个副本。 以这种方式，流的数量被减少到2(N-1) 条。 对普通的两人视频会议， Skype路由对等方到对等方呼叫，除非需要NAT穿越，此时呼叫通过一个非NAT对等方中继，如前面所述。
对于一个涉及N>2 个参与者的视频会议呼叫，由于视频媒体的性质， Skype不像对语音呼叫那样在一个位置将呼叫结合进一条流中，然后将流向所有参与者重新分发。 相反，每个参与者的视频流被路由到一个服务器集群，该集群依次将N-1 个其他参与者的N-1 条流中继到每个参与者 。 你可能想知道为什么每个参与者向服务器而不是向每个其他N-1 其他参与者直接发送其视频流的副本呢？的确，对两种方法而言， N(N- 1 ) 个视频流正由会议中的N个参与者共同接收。 其原因是，在大多数接入链路中上行链路带宽比下行链路带宽要低得多，上行链路可能不支持使用P2P方法的 N-1 条流。
实时会话式应用的协议
实时会话式应用（包括VoIP 和视频会议）引人入胜并且非常流行。 因此标准机构如TETF 和 ITU 多年来一直忙于（而且要继续忙下去！）苦心推敲这类应用的标准是毫不奇怪的。 借助于实时会话式应用的适当标准，各个独立公司正在创造新的能够互相操作的产品。 在本节中，我们探讨用于实时会话式应用的RTP和SIP。 这两个标准正广泛地应用于工业产品中。
RTP
在前一节中，我们知道VolP应用的发送端在将块传递给运输层之前为它们附加上首部字段。 这些首部字段包括了序号和时间戳。 因为大多数多媒体网络应用能够利用序号和时间戳，因此有一个包括音频／视频数据、序号、时间戳以及其他潜在有用字段的标准分组结构是方便的。 定义在RFC 3550 中的 RTP就是这样一个标准。 RTP能够用于传输通用格式，如用于声音的PCM、 ACC 和 MP3、用于视频的 MPEG和 H.263。 它也可以用于传输专用的声音和视频格式。目前， RTP在许多产品和研究原型中得到广泛实现。 它也是其他重要的实时交互协议 （如STP) 的补充，
本节我们介绍RTP。 我们也鼓励读者去访问 Henning Schulzrinne 的 RTP 站点, 该网站提供有关这个主题的很多信息。 读者也可以访问 RAT 站点 , 它记载了使用 RTP 的 VoIP 应用
- RTP 基础
RTP 通常运行在 UDP之上。 发送端在RTP分组中封装媒体块，然后在 UDP报文段中封装该分组，然后将该报文段递交给 IP。 接收端从 UDP报文段中提取出这个 RTP分组，然后从RTP分组中提取出媒体块，并将这个块传递给媒体播放器来解码和呈现。
举例来说，考虑使用 RTP来传输语音。 假设语音源采用了64kbps 的 PCM 编码（也就是采样、量化和数字化）。 再假设应用程序在20ms块中收集这些编码数据、也就是一个块中有 160 字节。 发送端在每个语音数据块的前面加上一个 RTP首部 (RTP header) , 这个首部包括音频编码的类型、序号和时间戳。 RTP首部通常是 12 字节。音频块和 RTP首部一起形成RTP分组 (RTP packet)。 然后向 UDP 套接字接口发送该 RTP分组。在接收端，应用程序从它的套接字接口收到该RTP分组．从 RTP分组中提取出该音频块， 并且使用RTP 分组的首部字段来适当地解码和播放该音频块。
如果一个应用程序集成了 RTP, 而非一种提供负载类型、序号或者时间戳的专用方案，则该应用程序将更容易和其他网络的多媒体应用程序互操作。例如，如果两个不同的公司都开发VoIP软件，并且都在它们的产品中集成了 RTP, 则希望使用一种 VoIP产品的用户能够和使用另一种VoIP产品的用户进行通信。
应该强调的是， RTP并不提供任何机制来确保数据的及时交付，或者提供其他服务质量 (QoS) 保证； 它甚至不保证分组的交付，或防止分组的失序交付。 RTP封装的东西确仅为端系统所见。 路由器不区分携带RTP分组的 IP数据报和不携带 RTP分组的 IP数据报。
RTP 允许为每个源（例如一个摄像头或者一个麦克风）分配一个它自己的独立 RTP分组流。 例如，对于在两个参与者之间的一个视频会议，可能打开4个RTP流，即两个流传输音频（一个方向一个），两个流传输视频 （也是一个方向一个）。然而，在编码过程中很多流行的编码技术（包括MPEG1 和 MPEG2) 将音频和视频捆绑在单个流中。 当音频和视频与编码器捆绑时，每个方向只产生一个RTP流。
RTP 分组并非限用于单播应用，它们也可以经过一对多和多对多的多播树发送。 对于一个多对多的多播会话，所有的会话发送方和源通常使用同样的多播组来发送它们的 RTP流。 在一起使用的RTP多播流，例如在视频会议应用中从多个发送方发出的音频和视频流，同属千一个RP会话 (RTP session) - RTP 分组首部字段
如图9-8 所示， 4个主要的 RTP分组首部字段是有效载荷类型、序号、时间戳和源标识符字段。
RTP 分组中的有效载荷类型字段的长度是7 比特。 对于音频流，有效载荷类型字段用于指示所使用的音频编码类型（例如 PCM、适应性增量调制、线性预测编码）。 如果发送方在会话过程中决定改变编码， 发送方可以通过该有效载荷类型字段来通知接收方这种变化。 发送方可能要通过改变该编码来提高语音质量或者减小RTP流比特率。表9-2列出了当前 RTP 支持的一些音频有效载荷类型。
对于一个视频流，有效载荷类型用于指示视频编码类型（例如运动JPEG、 MPEG1、MPEG2 、 H. 261 ) 。 发送方也可以在会话期间动态改变视频编码。 表9-3 列出了当前 RTP支持的一些视频有效载荷类型.
其他重要的字段如下：
- 序号字段。序号字段长为 16 比特。每发送一个RTP分组则该序号增加 1，而且接收方可以用该序号来检测丢包和恢复分组序列。 例如，如果应用的接收方收到的RTP 分组流在序号86 和89 之间存在一个间隙，那么接收方则知道分组87 和88 丢失了 ， 那么接收方能够设法来隐藏该丢失数据
- 时间戳字段。时间戳字段长32 比特。 它反映了 RTP数据分组中的第一个字节的采样时刻。如我们在上一节所见，接收方能够使用时间戳来去除网络中引入的分组时延抖动，提供接收方的同步播放。 时间戳是从发送方的采样时钟中获得的。 举例来说，对于音频的每个采样周期（例如对于8kHz的采样时钟每 125µs 为一个周期）时间戳时钟增加1; 如果该音频应用产生由 160个编码采样组成的块的话，那么当源激活时，对每个RTP分组则时间戳增加 160。 即使源未激活，该时间戳时钟也将继续以恒定速率增加。
- 同步源标识符 (SSRC)。SSRC 字段长为 32 比特。 它标识了 RTP 流的源。 通常在RTP 会话中的每个流都有一个不同的SSRC。SSRC 不是发送方的 IP地址，而是当新的流开始时源随机分配的一个数。 两个流被分配相同SSRC 的概率是很小的。 如果发生了，这两个源应当选择一个新的SSRC值。
参考目录
书籍：《计算机网络：自顶向下方法（第七版）》