多媒体网络

日常使用网络时，发部分流量都是由视频产生，对于多媒体网络我们也有必要了解详情。

一、多媒体网络应用

我们将多媒体网络应用定义为任何应用音频或视频的网络应用。

视频的性质

视频最为显著的特点或许是它的高比特率(high bitrate)。经因特网分发的视频的典型传输速率从用于低质量视频会议的100kbps到用于流式高分辨率电影的3Mbps。

我们简要地考虑三个不同的用户，他们每人使用了一种不同的因特网应用。第一位用户Frank，他打算迅速将照片张贴到他中国的“优酷” 的品牌。而人们不仅观看因特网视频，他们也使用诸如YouTube这样的站点来上载和分发和 Amazon(Youku) 和“看看” (Kankan))实际上已经成为家喻户晓的朋友的脸书页面上。我们假设Frank每10秒查找一次新照片，并且这些照片的平均大小是200KB。 (简单地假定1KB = 8000比特。)第二位用户Martha正从因特网(“云中”)向她的智能手机流式传输音乐。我们假定Martha正在听许多MP3歌曲，一首接着一首，都以128kbps速率进行编码。第三位用户Victor则正在观看以2Mbps编码的视频。最后，我们假设所有三位用户的会话长度是4000秒 (大约67分钟)。

我们看到这时流式视频消耗了最多的带宽，其比特率比脸书和流式音乐应表三种因特网应用的比特率需求的比较用的带宽大10倍。因此，当设计网络视频应用时，我们心中必须记住的第一件事是视频的高比特率需求。

视频的另一种重要特点是它能被压缩，因而要在视频质量与比特率间进行折中。视频是一个图像序列，图像通常以恒定的速率显示，例如每秒24幅或30幅图像。一个没有压缩、数字编码的图像由像素阵列组成，每个像素被编码为一定数量的比特来表示亮度和颜色。在视频中有两种类型的冗余，它们都可以用来进行视频压缩(video compression)。空间冗余是给定图像的内部冗余。从直觉上讲，一个主要由空白组成的图像具有高度的冗余，能够有效地压缩而不会明显降低图像质量。时域冗余反映一幅图像和后续图像的重复程度。例如，如果幅图像和后续图像完全一致，没有理由对后续图像再进行编码；相反，在编码过程中直接指出后续图像是完全一样的则更为有效。今天现成的压缩算法能够将视频压缩为所希望的任何基本比特率。当然，比特率越高，图像质量越好，总体用户视觉体验也越好。

音频的性质

模拟音频的基本编码技术称为脉冲编码调制（PCM）：

• 模拟音频信号首先以某种固定速率采样，例如每秒8000个样本。每个采样值是一 个任意的实数。
• 然后每个采样值被“四舍五入”为有限个数值中的一个。这种操作被称为量化 (quantization)。这些有限个数值(称为量化值)通常是2的幕，例如256个量化值。
• 每个量化值由固定数量的比特表示。例如，如果有256个量化值，那么每个值 (因此每个音频采样)用一个字节来表示。所有样本的比特表示级联在一起就形成了该信号的数字表示。举例来说，如果一个模拟信号以每秒8000个样值采样，而每个样本被量化并用8比特表示，则得到的数字信号的速率就为每秒64 000比特。通过音频扬声器播放，这个数字信号则能够转换回来(也就是解码)，形成一个模拟信号。然而，解码后的模拟信号仅是初始信号的近似，并且声音质量也许有明显的下降(例如，高频的声音可能在解码信号中丢失了)。通过增加采样速率和量化值的数量，解码信号能够更好地接近初始的模拟信号。因此(与视频一 样)，在解码信号的质量和比特率与数字信号存储空间之间存在一种折中。

然而，PCM编码的语音和音乐很少在因特网中使用。与视频一样，取而代之的是使用压缩技术来减小流的比特速率。人类语音能被压缩到小于10kbps并仍然可懂。一种接近 CD质量立体声音乐的流行压缩技术是MPEG1第3层，更通常的叫法是MP3。MP3编码器通常能够压缩为许多不同的速率；128kbps是最常使用的编码速率，并且能够产生非常小的声音失真。一种相关的标准是高级音频编码(Advanced Audio Coding，AAC), 该标准已经随苹果公司而流行起来。与视频一样，能够以不同的比特率生成多重版本的预先录制 的音频流。

多媒体网络应用的类型

三大类：①流失存储音频/视频；②会话式IP语音/视频；③流式实况音频/视频。

流式存储音频和视频

我们讨论流式存储视频，流失存储视频的是那个不同特色：

• 流。在流式存储视频应用中，客户开始从服务器接收文件几秒之后，通常就开始播放视频。这意味着当客户正在从视频的一个位置开始播放时，与此同时正在从服务器接收该视频的后续部分。这种技术被称为流(streaming)，它避免了在开始播放之前必须下载整个视频(并且引起一个潜在的长时延)。
• 相互作用。因为媒体是预先录制的，用户可以对多媒体内容进行暂停、重新配置前进、重新配置倒退、快进等操作。从一个客户提出这种请求到该动作在客户端表现出来，可接受的响应时间应该小于几秒。
• 连续播放。一旦视频开始播放，它应该根据初始记录的时序进行。因此，为了在客户端播放，必须从服务器中及时接收数据；否则，用户经历视频帧停滞(这时客户等待延迟的帧)或帧跳过(这时客户漏掉延迟的帧)。

对流式视频最重要的性能测度是平均吞吐量。为了提供连续的播放，网络为流式应用提供的平均吞吐量必须至少与该流视频本身的比特率一样大。通过使用缓存和预取，即使在吞吐量波动的时候，提供连续播放也是可能的，只要平均吞吐量(在5~10秒区间平均)保持在视频速率之上。

对于许多流式视频应用，预先录制的视频被存储起来，并且从CDN而非从单一的数据中心流式播放。也有许多P2P视频流式应用，其中视频被存储在用户主机(对等方)上，不同视频块从可能分布在全球的不同对等方到达。在得知了因特网流式视频的性能后，特别关注客户缓存、预取、对可用带宽的适应性质量和CDN分发。

会话式IP语音和视频

在因特网上的实时会话式语音通常称为因特网电话 (Internet telephony)，因为从用户的角度看，它类似于传统的电路交换电话服务。它也常被称为IP语音(Voice-over-IP，VoIP)。会话式视频与之类似，除了它包括参与者的语音以及视频外。今天的大多数语音和视频会话式系统允许用户生成具有三个或更多个参与者的会议。会话式语音和视频广泛地应用于今天的因特网中，因特网公司Skype、QQ和Google Talk自称每天都有数亿用户。

服务需求：定时考虑、容忍丢包。

• 定时考虑。定时考虑是很重要的，因为音频和视频会话式应用是高度时延敏感(delay sensitive) 的。对于具有两个或更多个交互讲话者的会话来说，从用户讲话或移动开始到该动作显现在其他端的时延应当小于几百毫秒。对于语音，小于150ms的时延不会被人类听者觉察到，150〜400ms的时延能够被接受，当时延超过400ms 时，即使不会使对话变得完全无法理解，也会使语音会话变得令人沮丧。
• 容忍丢包。会话式多媒体应用容忍丢包(loss-tolerant)，即偶尔的丢失只会在音频/视频回放时偶尔出现干扰信号，而且这些丢失经常可以部分或者全部地隐藏。这些时延敏感但容忍丢包的特性明显不同于那些弹性数据应用(如Web浏览、电子邮件、社交网络和远程 注册等)的特性。对于这些弹性应用，长时延令人烦恼，但并不是特别有害，然而传输数据的完全和完整性是首要的。特别关注适应性播放、前向纠错和差错掩盖是如何减缓网络引入的分组丢失和时延的。

流式实况音频和视频

这种第三类应用类似于传统的电台广播和电视，只是它通过因特网来传输而已。这些 应用允许用户接收从世界上任何角落发出的实况无线电广播和电视传输。今天有数以千计、遍及全球的无线电台和电视台正在因特网上广播内容。

实况是类似于广播的应用，它们经常有很多接收相同音频/视频节目的客户。在今天的因特网中，这种应用通常是用CDN来实现的。由于使用流式存储多媒体，网络必须为每个实况多媒体流提供大于该视频消耗速率的平均吞吐量。因为事件是直播的，尽管定时限制没有会话式语音那么严格，但时延也可能成为问题。从用户选择观看一个实 况传输到播放开始，能够容忍的时延最多为10秒。用于流式实况媒体的许多技术(如初始缓存时延、适应性带宽使用和CDN分发)都类似于流式存储媒体所使用的技术。

二、流式存储视频

对于流式视频应用，预先录制的视频放置在服务器上，用户向这些服务器发送请求按需观看这些视频。用户可能从开始到结束都在观看视频而没有中断它，也可能在视频结束前停止观看它，或者通过暂停、重新定位到后面或前面镜头来与视频交互。流式视频系统可分为三种类型：UDP流 (UDP streaming) 、HTTP流 (HTTP streaming) 和适应性HTTP流(adaptive HTTP streaming)。尽管在实践中所有这三种系统都在使用，但绝大多数今天的系统应用了 HTTP流和适应性HTTP流。

所有这三种形式的视频流的共同特点是广泛使用了客户端应用缓存，以此来缓解变化的端到端时延和变化的服务器和客户之间可用带宽量的影响。对于流式视频(存储的和实况的)，用户通常能够容忍在客户请求某视频与该流视频在客户端播放之间有几秒的初始小时延。所以，当视频开始到达客户时，客户不必立即开始播放，反而能够在应用程序缓存中建立该视频的储备。一旦该客户建立起几秒“已缓存但尚未播放”的视频储备，客户就可以开始视频播放了。这种客户缓存(client buffering)具有两种重要的优点。第一，客户端缓存能够吸收服务器到客户时延中的波动。如果某特殊部分的视频数据延迟了，只要它在“接收到但尚未播放”的视频耗尽之前到达，这个长时延将不会被注意到。第二，如果服务器到客户带宽暂时低于视频消耗速率，用户能够继续享受连续的播放，只要客户应用缓存仍没有完全排尽。

UDP流

使用UDP流，服务器通过UDP以一种稳定的速率记录下视频块，用与客户的视频消耗速率相匹配的速率传输视频。例如，如果视频消耗率是2Mbps，每个UDP分组承载8000比特视频，则服务器将每隔(8000比特)/(2Mbps)=4ms向其套接字发送一个 UDP分组。因为UDP未采用某种拥塞控制机制，所以服务器能够以视频的消耗速率将分组推进网络中，而无TCP的速率控制的限制。UDP流通常使用很小的客户端缓存，空间维持小于1秒视频就足够了。

在将视频块传递给UDP之前，服务器将视频块封装在运输分组中，该运输分组是专门为传输音频和视频而设计的，使用了实时传输协议(Real-Time Transport Protocol，RTP)或某种类似(可能是专用)的方案。

UDP流的另一种不同的性质是，除了服务器到客户的视频流外，两者间还并行地维护一个单独的控制连接，通过该连接，客户可发送有关会话状态变化的命令(如暂停、重新开始、重定位等)。这种控制连接在许多方面类似FTP控制连接。

尽管UDP流已经在多个开源系统和专用产品中得到应用，但它有三个重大不足：

• 首先，由于服务器和控制之间的可用带宽无法预测并且是变化的，恒定速率UDP流不能够提供连续的播放。例如考虑以下场景：视频消耗速率为1Mbps,服务器到客户可用带宽通常超过1 Mbps，但每过几分钟就有几秒时间其可用带宽低于1Mbps。在这种场景下，以1Mbps恒定速率经RTP/UDP传输视频的UDP流系统很可能将提供不好的用户体验，在可用带宽低于1Mbps之后产生停滞或漏帧。
• UDP流的第二个缺点是它要求如RTSP服务器这样的媒体控制服务器，以对每个进行中的客户会话处理客户到服务器的交互请求和跟踪客户状态(例如在视频中的客户播放点，视频是否被暂停或播放等)。这增加了部署大规模的按需视频系统的总体成本和复杂性。
• 第三个缺点是许多防火墙配置为阻塞UDP流量，防止这些防火墙后面的用户接收UDP视频。

HTTP流

在HTTP流中，视频直接作为具有一个特定URL的普通文件存储在HTTP服务器上。 当用户要看视频时，客户和服务器之间建立一个TCP连接，并且发送一个对该URL的HTTP GET请求。服务器则尽可能快地在HTTP响应报文中发送该视频文件，这就是说，以TCP拥塞控制和流控制允许的尽可能快的速率进行处理。在客户端上，字节收集在一个 客户应用缓存中。一旦在缓存中字节数量超过了预先设定的阈值，该客户应用程序开始播放，具体而言，它周期性地从客户应用缓存中抓取视频帧，对帧解压缩并在用户屏幕上显示它们。

在TCP上使用HTTP也使得视频穿越防火墙和NAT(它们常常被配置为阻挡UDP流量但允许大部分HTTP流量通过)更为容易。HTTP流消除了因需要媒体控制服务器(如RTSP服务器)带来的不便，减少了在因特网上大规模部署的成本。由于所有这些优点，今天的大多数流式视频应用(包括YouTube和Netflix)都使用HTTP流(在TCP上)作为它的底层流式协议。

• 预取视频。

如同我们刚才所学的那样，客户端缓存可用于缓解变化的端到端时延和变化的可用带宽的影响。服务器以视频播放的速率传输。然而，对于流式存储视频，客户能够尝试以高于消耗速率的速率下载视频，因此预取(prefetching)将来会被消耗的视频帧。该预取的视频当然存储在客户应用缓存中。这样的预取自然伴随TCP流岀 现，因为TCP拥塞避免机制将试图使用服务器和客户之间的所有可用带宽。

假设视频消耗速率是1Mbps，而网络从服务器到客户能够以恒定的1.5Mbps速率交付视频。客户则不仅能够以非常小的播放时延播放该视频，而且还能够以每秒500Kb的量增加缓存的视频数据。以这种方式，如果后来该客户在一段短暂时间内以小于1Mbps的速率接收数据，该客户由于在其缓存中的储备将能够继续提供连续的播放。

• 客户应用缓存和TCP缓存。

在服务器侧，视频文件中的白色部分已经通过服务器的套接字进行发送，而黑色部分是留下待发送的部分。在“通过套接字的门传送”之后，放置在TCP发送缓存中的字节在被传输进因特网之前，因为TCP发送缓存显示为满，服务器立即防止从视频文件向套接字发送更多的字节。在客户侧，客户应用程序(媒体播放器)从TCP接收缓存(通过其客户套接字) 读出字节并将字节放入客户应用缓存中。与此同时，客户应用程序周期性地从客户应用缓 存中抓取视频帧，解压缩并显示在用户屏幕上。注意到如果客户应用缓存大于该视频文件，则从服务器存储器到客户应用缓存移动字节的整个过程等价于普通文件经HTTP的下载过程，即客户直接将视频用TCP允许的尽可能快的速率从服务器中拉出来。

现在考虑在流播放期间当用户暂停视频时将发生的现象。在暂停期间，比特未从客户应用缓存中删除，甚至比特继续从服务器进入缓存。如果客户应用缓存是有限的，它可能 最终会变满，这将反过来引起对服务器的“反向压力”。具体而言，一旦客户应用缓存变 满，字节不再从客户TCP接收缓存中删除，因此它也会变满。一旦客户TCP接收缓存变满，字节不再从服务器TCP发送缓存删除，因此它也变满。一旦服务器TCP发送缓存变满，服务器不能向套接字中发送任何更多的字节。因此，如果用户暂停视频，服务器可能被迫停止传输，在这种情况下服务器被阻塞，直到用户恢复该视频。

事实上，甚至在常规的播放过程中(即没有暂停)，如果客户应用缓存变满，反向压力将引起TCP缓存变满，这将迫使服务器降低其速率。为了决定其产生的速率，注意到当客户缓存删除f比特，它在客户应用缓存中产生了f比特的空间，这依次允许服务器发送额外的f比特。因此，服务器发送速率不能比客户端视频消耗速率更高。因此，当使用HTTP流时，一个满的客户应用缓存间接地对服务器到客户能够发送的视频速率施加了限制。

• 流式视频的分析。

B表示客户应用缓存的长度(以比特计)，Q表示在客户应用缓存开始播放之前必须被缓存的比特数量。(当然，Q

视频的早期终止和重定位

HTTP流系统经常利用HTTP GET请求报文中的HTTP字节范围首部(HTTP byte- range header)，该首部指示了客户当前要从所希望的视频中获取的字节范围。当用户要在视频中及时重定位(即跳跃)到未来点时，这特别有用。当用户重定位到一个新位置时，客户发送一个新HTTP请求，用字节范围首部指出服务器应当从文件的哪个字节起发送数据。当服务器接收到该新的HTTP请求时，它能够忘记任何较早的请求，而是由字节范围请求中指示的字节开始发送。

在我们讨论重定位主题的时候，我们简要地提及当某用户重定位到视频中的某个未来点或提前终止视频时，某些由服务器发送的已预取但尚未观看的数据将不会被观看，即导致了网络带宽和服务器资源的浪费。例如，假设在视频中的某时刻t₀客户缓存充满B比特，在此时用户重定位到视频中的某个瞬间t>t₀+B/r，然后从这点起观察视频直到结束。 在这种情况下，缓存中的所有B比特将未被观看，用于传输这B比特的带宽和服务器资源完全被浪费掉了。在因特网中，有大量的带宽因提前终止而浪费，这些成本可能相当大，特别是对于无线链路。由于这个原因，许多流系统仅使用了长度适当的客户应用缓存，或者将限制在HTTP请求中使用字节范围首部预取的视频数量。

三、IP语音

经因特网的实时会话式语音经常被称为因特网电话(Internet telephony)，因为从用户的视角看，它类似于传统的电路交换电话服务。它通常也被称为IP语音(Voice-over-IP，VoIP)。在本节中我们描述VoIP所依据的原则和协议。会话式视频在许多方面类似于VoIP，除了它包括参与者的视频以及他们的语音以外。为了使讨论重点突出且具体，我们这里仅关注语音，而不是语音和视频的结合。

尽力而为服务的限制

因特网的网络层协议IP提供了尽力而为的服务。那就是说服务尽全力将每个数据报从源尽可能快地移动到目的地，但是没有就在某些时延界限内使分组到达目的地或丢包百分比的限制做任何承诺。缺失这种保证对实时会话式应用的设计提出了严峻挑战，这些应用对分组时延、时延抖动和丢包非常敏感。

在本节中，我们将讨论加强尽力而为网络上的VoIP性能的几种方式。我们的重点将在应用层技术上，即这些技术并不要求在网络核心甚至在端系统的运输层有任何变化。为了使讨论具体，我们将讨论在一个特定的VoIP例子环境下尽力而为IP服务的限制。发送方以每秒8000字节的速率产生字节，且每20ms将字节汇聚成块。每个块和一个特殊的首部(在下面讨论)封装在一个UDP报文段中(通过一个到套接字接口的呼叫)。因此，一 个块中的字节数为(20ms)x(8000字节/秒)=160字节，每20ms发送一个UDP报文段。

如果每个分组以恒定的端到端时延到达接收方，那么分组每隔20ms就能周期性地到达接收方。在这种理想的情况下，只要每个块一到达，接收方就能直接播放它。但不幸的是，某些分组可能丢失，大多数分组没有相同的端到端时延，即使在一个轻度拥塞的因特网中也是如此。因此，接收方必须更仔细地判断：①什么时候播放一个块；②如何处理一 个丢失块。

• 丢包。

考虑由VoIP应用产生的一个UDP报文段。这个UDP报文段封装在IP数据报中。当数据报在网络中徘徊时，在它等待出链路传输时要经过路由器的缓存(即队列)。从发送方到接收方的路径上的一个或多个缓存有可能是满的，不能接纳该IP数据报。在这种情况下，这个IP数据报就被丢弃了，永远不会到达接收方的应用程序。

通过TCP (它提供了可靠数据传输)而不是UDP发送分组可以消除丢失。然而，重传机制对于诸如VoIP这样的会话式实时音频应用，通常认为是不可接受的，因为它们增加了端到端时延。此外，当丢包后，由于TCP的拥塞控制，发送方的传输速率可能减少到低于接收方的排空速率，可能导致缓存“饥饿”。这可能会对接收方的语音可理解程度产生严重影响。由于这些原因，几乎所有现有的VoIP应用默认运行在UDP上。

但是分组的丢失并不一定会造成人们想象中的灾难。实际上，取决于语音是如何编码和传输的以及接收方隐藏丢包的方式，1%〜20%的丢包率是可以忍受的。例如，前向纠错(FEC)能够有助于隐藏丢包。我们后面可以看到，通过使用FEC，将冗余信息和初始信息一起传输，以便能够从冗余信息中恢复一些丢失的初始数据。无论如何，如果发送方和接收方之间的一段或多段链路严重拥塞，丢包率超过10%~20% (例如在无线链路上)，那么无论采取何种措施都无法获得可以接受的声音质量了。显然，尽力而为服务有它的局限性。

• 端到端时延。

端到端时延(end-to-end delay)是以下因素的总和：路由器中的传输、处理和排队时延，链路中的传播时延和端系统的处理时延。对于实时会话式应用，例如VoIP，听电话的人对于小于150ms的端到端时延是觉察不到的；在 150ms和400ms之间的时延能够接受，但是不够理想；超过400ms的时延可能严重妨碍语音谈话的交互性。VoIP应用程序的接收方通常忽略时延超过特定阈值(例如超过400ms)的任何分组。因此，时延超过该阈值的分组等效于丢弃。

• 分组时延抖动。

端到端时延的一个关键成分是一个分组在网络路由器中经历的变化的排队时延。由于这些可变的时延，从在源中产生分组到它在接收方收到的这段时间，对于不同的分组可能会有波动，这个现象称为时延抖动(jitter)。

时延抖动通常可以通过使用序号(sequence number)、时间戳(timestamp)和播放时延(playout delay)来消除。

在接收方消除音频的时延抖动

对于VoIP应用，周期性地产生分组，接收方应该在存在随机网络时延抖动的情况下尝试提供播放语音块。这经常通过结合下面两种机制来实现：

• 为毎个块预先计划一个时间戳( timestamp)。发送方用每个块产生的时刻为它加上时间印记。
• 在接收方延迟播放(delaying playout)块。如我们前面讨论所见，接收的音频块的播放时延必须足够长，以便大多数分组在它们的预定播放时间之前接收到。这个播放时延可能在整个音频会话期间是固定的，或者在音频会话生命期中适应性地变化。

我们现在讨论如何结合这两种机制来减轻甚至消除时延抖动的影响。我们研究两种播放策略：固定播放时延和适应性播放时延。

固定播放时延

使用固定播放时延策略，接收方试图在块产生正好q ms后播放它。因此如果一个块在时刻/打上时间戳，接收方在时刻t+q播放这个块，假设这个块在那个时间已经到达。在预定播放时间之后到达的分组将被丢弃，并被认为已经丢失。

q选择什么值为好呢？尽管使用更小的q值可以获得更令人满意的会话体验，但VoIP能够支持高达约400ms的时延。另一方面，如果q比400ms小得多，那么由于网络引入的分组时延抖动会使许多分组可能错过了它们的预定播放时间。概括地说，如果端到端时延经常发生大的变化，用一个大的q更好；另一方面，如果时延很小并且时延变化也很小，用一个较小的、可能小于150ms的q更好。

上图表示了单个话音突峰期的分组产生和播放的时间。考虑了两种不同的初始播放时延。如最左边的阶梯所示，发送方以规则的间隔(比方说每20ms)产生一组分组。 在这个话音突峰期中的第一个分组在时刻厂被接收到。如该图所示，由于网络时延抖动，后续分组的到达间隔是不均匀的。

对于第一个播放调度时间，固定的初始播放时延设置为p-r。使用这个方案，第四个分组没有在它调度的播放时间到达，接收方认为它丢失了。对于第二个调度时间，固定的初始播放时延设置为p‘-r。对于这个方案，所有分组都在它们调度的播放时间之前到达，因此没有丢失。

适应性播放时延

对于固定播放时延，如果初始播放时延设置的比较大，大多数分组能在他们的截止时间内到达，因此存在的对视将可以忽略，但是我们希望播放时延最小化，使丢包低于一定百分比的限制即可。

处理这种折中的自然方法是估计网络时延和网络时延变化，并且在每个话音突峰期的开始相应地调整播放时延。在话音突峰期开始时适应性地调整播放时延将导致发送方静默期的压缩和拉长；然而，静默期的少量压缩和拉长在谈话中是不易觉察的。

从丢包中恢复

广义的丢包：如果某分组不能到达接收方，或者在它调度的播放时间之后才到达，该分组丢失。

两种丢包的预期方案是：前向纠错（FEC）、交织。

前向纠错

FEC的基本思想是给初始的分组流增加冗余信息，以稍微增加传输速率为代价，这些冗余信息可以用来重建一些丢失分组的近似或者准确版本。

• 第一种机制是每发送n个块之后发送一个冗余编码的块。

这个冗余块通过异或n个初始块来获得。以这种方式，在这n + 1个分组的组中，如果任何一个分组丢失，接收方能够完全重建丢失的分组。但是如果这一组中有两个或更多分组丢失，接收方则无法重建丢失的分组。通过让组的长度n + 1比较小，当丢失不是很多时，大部分丢失分组都可以恢复。然而组的长度越小，相对增加的传输速率就越大。特别是若传输速率以1/n因子增加的话，例如n=3，则传输速率增加33%。此外，这个简单的方案增加了播放时延，因为接收方在能够开始播放之前，必须等待收到整个组的分组。

• 第二个FEC机制是发送一个较低分辨率的音频流作为冗余信息。

例如，发送方可能创建一个标称的音频流和一个相应的低分辨率、低比特率的音频流。(这个标称流可能是一 个64kbps的PCM编码，而这个较低质量的流可能是一个13kbps的GSM编码。)这个低比特率流被认为是冗余信息。发送方通过从这个标称流中取出第n个块并附加上第(n-1)个块的冗余信息，以构建第n个分组。以这种方式，只要没有连续分组的丢失，接收方都可以通过播放和后续分组一起到达的低比特率编码块来隐藏丢失。当然，低比特率块比标称块的质量要低。然而，在一个流主要是由高质量块组成、偶尔出现低质量块并且没有丢失的块的情况下，其整体的音频质量良好。注意到在这种方案中，接收方在播放前只需接收两个分组，因此增加的时延小。此外，如果低比特率编码比标称编码少得多，那么传输速率的额外增加并不大。

为了处理连续丢失，我们能够使用一个简单的修正方案。发送方不再仅为第n个标称块附加上第(n-1)个低比特率块，而是附加上第(n-1)个和第(n-2)个低比特率块，或者附加第(n -1)个和第(n-3)个低比特率块等等。通过给每个标称块附加 上更多低比特率块，在各种恶劣的尽力而为服务环境下接收方的音频质量变得可接受。在 另一方面，附加的块增加了传输带宽和播放时延。

交织

作为冗余传输的另一种替代方案，VoIP应用可以发送交织的音频。发送方在传输之前对音频数据单元重新排序，使得最初相邻的单元在传输流中以一定距离分离开来。交织可以减轻丢包的影响。例如，如果每个单元长为5ms,块是20ms (也就是每 个块4个单元)，那么第一个块可能包含1、5、9和13单元；第二个块可能包含2、6、10 和14单元等等。显示了一个交织流的单个丢包导致重建流中的多个小间隙，这与在非交织流中将会导致单个大间隙形成对照。

交织能够明显地提高音频流可感觉到的质量。它的开销也较低。交织明显的缺点是增加了时延。这限制了它在如VoIP这样的会话式应用中的使用，然而它能够很好地处理流式存储音频。交织的一个主要优点是它不增加流的带宽需求。

差错掩盖

差错掩盖方案试图为丢失的分组产生一个与初始分组类似的替代物。因为音频信号(特别是语音)呈现出大量的短期自相似性，故该方案是可行的。正因为如此，这些技术适合于工作在相对小的丢包率(低于15%)和小分组(4〜40ms)的情况。当丢失长度接近音素的长度(5 ~ 100ms)时，这些技术就失效了，因为整个音素可能被听者错过。

也许基于接收方的恢复的最简单方式是分组重复。即用在丢失之前刚到达的分组的副本来代替丢失的分组。这种方法的计算复杂度低，并且工作得相当好。基于接收方恢复的另一种形式是内插法，它使用在丢失之前和之后的音频内插形成一个合适分组来隐藏丢失。内插法比分组重复稍微好一些，但是显然需要更高的计算强度。

四、实时会话式应用的协议

借助于实时会话式应用的适当标准，各个独立公司正在创造新的能够互相操作的产品。我们探讨用于实时会话式应用的RTP和SIP。这两个标准正广泛地应用于工业产品中。

RTP

我们知道VoIP应用的发送端在将块传递给运输层之前为它们附加上首部字段。这些首部字段包括了序号和时间戳。因为大多数多媒体网络应用能够利用序号和时间戳，因此有一个包括音频/视频数据、序号、时间戳以及其他潜在有用字段的标准分组结构是方便的。定义在RFC 3550中的RTP就是这样一个标准。RTP能够用于传输通用格式，如用于声音的PCM、ACC和MP3，用于视频的MPEG和H.263。它也可以用于传输专用的声音和视频格式。目前，RTP在许多产品和研究原型中得到广泛实现。它也是其他重要的实时交互协议(如 STP) 的补充。

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经常和SIP—起使用，SIP是一种因特网电话的重要标准。

应该强调的是，RTP并不提供任何机制来确保数据的及时交付，或者提供其他服务质量(QoS)保证；它甚至不保证分组的交付，或防止分组的失序交付。RTP封装的东西确仅为端系统所见。路由器不区分携带RTP分组的IP数据报和不携带RTP分组的IP数据报。

RTP允许为每个源(例如一架照相机或者一个麦克风)分配一个它自己的独立RTP 分组流。例如，对于在两个参与者之间的一个视频会议，可能打开4个RTP流，即两个流传输音频(一个方向一个)，两个流传输视频(也是一个方向一个)。然而，在编码过程中很多流行的编码技术(包括MPEG1和MPEG2)将音频和视频捆绑在单个流中。当音频和视频与编码器捆绑时，每个方向只产生一个RTP流。

RTP分组并非限用于单播应用，它们也可以经过一对多和多对多的多播树发送。对于一个多对多的多播会话，所有的会话发送方和源通常使用同样的多播组来发送它们的RTP流。在一起使用的RTP多播流，例如在视频会议应用中从多个发送方发出的音频和视频流，同属于一个RTP会话(RTP session)。

RTP分组首部字段

4个主要的RTP分组首部字段是有效载荷类型、序号、时间戳和源标识符字段。

• 序号字段。

序号字段长为16比特。每发送一个RTP分组则该序号增加1，而且接收方可以用该序号来检测丢包和恢复分组序列。例如，如果应用的接收方收到的 RTP分组流在序号86和89之间存在一个间隙，那么接收方则知道分组87和88丢失了。那么接收方能够设法来隐藏该丢失数据。

• 时间戳字段。

时间戳字段长32比特。它反映了RTP数据分组中的第一个字节的采样时刻。如我们在上一节所见，接收方能够使用时间戳来去除网络中引入的分组时延抖动，提供接收方的同步播放。时间戳是从发送方的采样时钟中获得的。举例来说，对于音频的每个采样周期(例如对于8kHz的采样时钟每125us为一个周期)时间戳时钟增加1；如果该音频应用产生由160个编码采样组成的块的话，那么当源激活时，对每个RTP分组则时间戳增加160。即使源未激活，该时间戳时钟也将继续以恒定速率增加。

• 同步源标识符（SSRC）。

SSRC字段长为32比特。它标识了RTP流的源。通常在RTP会话中的每个流都有一个不同的SSRC。SSRC不是发送方的IP地址，而是当新的流开始时源随机分配的一个数。两个流被分配相同SSRC的概率是很小的。如果发生了，这两个源应当选择一个新的SSRC值。

SIP

会话发起协议(Session Initiation Protocol，SIP)。

一个开放和轻型的协议，其功能如下：

• 提供了在主叫者和被叫者之间经IP网络创建呼叫的机制。它允许主叫者通知被叫者它要开始一个呼叫。它允许参与者约定媒体编码，也允许参与者结束呼叫。
• 提供了主叫者确定被叫者的当前IP地址的机制。因为用户可能动态地分配到地址（使用DHCP），而且因为它们可能有多个IP设备，每个都有一个不同的IP地址，所以用户不具有单一的、固定的IP地址。
• 提供了用于呼叫管理的机制，这些机制包括在呼叫期间增加新媒体流、在呼叫期 间改变编码、在呼叫期间邀请新的参与者、呼叫转移和呼叫保持等。

向已知IP地址建立一个呼叫

Alice在使用PC,并 且她要呼叫Bob, Bob也在使用PC工作。Alice和Bob的PC都配有基于SIP的软件来产生和接收电话呼叫。在这个初始的例子中，我们将假设Alice知道Bob PC的IP地址：

我们看到当Alice给Bob发送一个INVITE报文(这类似于HTTP请求报文)时，一个SIP会话开始了。该INVITE报文通过UDP发送给SIP的周知端口5060。(SIP报文也可以经TCP发送。)该INVITE报文包括了对Bob的标识(bob@ 193.64.210.89)、 Alice当前IP地址的指示、Alice希望接收的音频的指示(该音频以格式AVP 0编码，即u律PCM编码，并在RTP中封装)，以及她希望在端口38060接收RTP分组的指示。在收到了 Alice的INVITE报文之后，Bob发送一个SIP响应报文(该报文类似HTTP的响应报文)。该响应SIP报文也被发送到SIP端口5060。Bob的响应包括一个200 OK和他的IP地址的指示、他希望接收的编码和分组化，以及音频数据应该发送到达的端口号。注意到在这个例子中，Alice和Bob准备使用不同的音频编码机制：要求Alice使用GSM来对她的音频编码，而要求Bob使用u律PCM对他的音频编码。在接收到Bob的响应后，Alice向 Bob发送SIP确认报文。在这个SIP事务之后，Bob和Alice可以交谈了。他们通常可以同时进行交谈。Bob会根据要求对音频进行编码和分组化，并将音频分组发送给IP地址167. 180. 112. 24的端口号38060。Alice也会根据要求对音频进行编码和分组化，并将音频分组发送给IP地址193. 64.210. 89 的端口号48753。

SIP的关键特性：

第一，SIP是一个带外协议，即发送和接收SIP报文使用了一个不同于发送和接收媒体数据的套接字。

第二，SIP报文本身是可读的ASCII，这与HTTP报文类似。

第三，SIP要求所有的报文都要确认，因此它能够在UDP或者TCP上运行。

SIP地址

在前面的例子中，Bob的SIP地址是sip: [email protected]。然而，我们希望许多 (即使不是大多数)SIP地址类似于电子邮件地址。例如，Bob的地址可以是sip: bob@domain. com。当Alice的SIP设备发送INVITE报文，该报文包括这种类似于电子邮件地址的地址；然后SIP的基本设施将该报文转发给Bob正在使用的IP设备。 其他可能的SIP地址形式可以是Bob过去的电话号码或者只是Bob的名字/中间名/姓氏(假设它是唯一的)。

SIP地址的一个有趣特点是它们能够被包括在Web页面中，就像人们的电子邮件地址用mailto URL形式包含在Web页面中那样。例如，假设Bob有个人主页，并且他要为这个主页的访问者提供一个呼叫他的方法。于是他可能只是在主页中包括该URL sip: bob@domain. como当访问者点击该URL，访问者设备中的SIP应用将启动，并向Bob发送IN VITE报文。

SIP报文

这个INVITE行包括SIP的版本，这与HTTP请求报文一样。任何时候SIP报文通过一 个SIP设备(包括产生该报文的设备)时，它附加上一个Via首部来指示该设备的IP地址。与电子邮件报文类似，SIP报文包括一个From首部行和一个To首部行。该报文包括 一个Call-ID (呼叫标识符)，它唯一地标识该呼叫(类似电子邮件中的报文ID)；包括一个Content-Type (内容类型)首部行，定义用于描述包含在SIP报文中的内容的格式；还包括Content-Length (内容长度)首部行，提供报文中内容的字节长度。最后，在一个回车和换行之后，该报文包含内容部分。在这个例子中，内容提供了有关Alice的IP地址和 Alice要如何接收该音频的信息。

名字翻译和用户定位

我们假设Alice的SIP设备知道能够联系到Bob的IP地址。但是这种假设是很不真实的，不仅因为IP地址通常是通过DHCP动态分配的，而且Bob可能 有多个IP设备(例如，在家里、工作中和汽车里有不同的设备)。因此现在我们假设 Alice只知道Bob的电子邮件地址bob@domain. com，而且对基于SIP的呼叫使用同样的地 址。在这种情况下，Alice需要获得用户bob@ domain. com 正在使用的设备的IP地址。

代理服务器只需要转发Alice的INVITE报文给Bob的注册器/代理即可。然后注册器/代理将该报文转发给Bob现在的SIP设备。

五、支持多媒体的网络

能够对多媒体应用提供网络层支持的三种宽泛的方法：

至此，多媒体网络大概就这样了。