[系统运维]【计算机网络】第六部分 应用层(29) 多媒体

近年来，技术的进步已改变了人们使用音频和视频的方式。过去，通过收音机收听广播，通过电视收看视频节目，通过电话网与另一方交互式通信。但时代已经变了，人们使用因特网不仅限于文字和图像通信，而且用于音频和视频服务。这里集中介绍因特网在音频和视频方面的应用。

我们可以把音频和视频服务分为三大类：流式存储音频/视频 streaming stored audio/video 、流式实时音频/视频 streaming live audio/video 和交互式音频/视频 interactive audio/video ，如图29.1所示。流式意味着用户在文件下载的同时就可以收听（或者观看）。

• 第一类，流式存储音频/视频是一些经过压缩并存储在服务器中的文件。客户机通过因特网下载这些文件，这就是我们有时所说的音频/视频点播 on-demand audio/video 。存储音频文件的例子有：歌曲、交响乐、磁带，存储视频文件的例子有：电影、电视节目和音乐视频剪辑等。即，流式存储音频/视频是指对压缩的音频/视频文件的点播请求。
• 第二类，流式实时音频/视频是指用户通过因特网收听、收看音频和视频节目。一个较好的应用实例是因特网广播。许多广播电台仅仅在因特网上播出它们的节目，还有一些电台用因特网和无线电波播放节目。即，流式实时音频/视频是指电台和电视台通过因特网播放节目。
• 第三类，交互式音频/视频，人们使用因特网进行彼此间的交互式通信。一个较好的实例是因特网电话和因特网远程会议。即，交互式音频/视频是指使用因特网实现交互式音频/视频应用。
  

这里讨论这三种应用，首先要讨论与音频/视频有关的其他一些问题，如音频/视频数字化和音频/视频压缩 digitizing audio and video and compressing audio and video. 。

29.1 音频与视频的数字化

在音频和视频信号通过因特网发送之前，需要进行数字化处理，下面将音频和视频分开讨论。

29.1.1 音频数字化

麦克风接收到声音时，会产生电子模拟信号 electronic analog signal ，该信号表示声音振幅随时间的变化（函数）。这种信号称为模拟音频信号 analog audio signal 。

模拟信号（如音频信号）可以数字化而产生数字信号。根据奈奎斯特定理，如果信号的最高频率是 $f$ ，则需要每秒对信号采样 $2f$ 次。有许多用于将音频信号进行数字化的方法，但原理是一样的。

声音每秒采样 $8000$ 次，每次采样值是 $8$ 位，其结果是 $64\text{Kbps}$ 的数字信号。音乐则每秒采样 $44100$ 次，每个采样值是 $16$ 位，这样会产生单声道 $705.6\text{Kbps}$ 和立体声 $1.411\text{Mbps}$ 的数字信号。

29.1.2 视频数字化

视频由一系列的帧构成。如果帧在屏幕上显示足够快，我们就会有运动的感觉。原因是人的眼睛不能够分辨出快速闪过的单帧图像。每秒的帧数没有统一的标准。在北美，常见的是每秒 $25$ 帧。但是为了避免闪烁的情况出现，需要不断重复刷新帧。电视需要每一帧刷新两次，也就是说需要发送到帧。换言之，如果在发送方有存储器的话，发送的 $25$ 帧中每一帧都要从存储器中提取重画两次。

每一帧会被分为更小的栅格，称为图像元素或者像素 pixel 。对于黑白电视，每个 $8$ 位的像素可以表示为 $256$ 个不同的灰度等级。对于彩色电视，每个像素是 $24$ 位，每一种三原色（红、绿和蓝）占用 $8$ 位。

可以计算出在特定分辨率下每秒所用的位数。在最低分辨率下，一个彩色帧由 $1024\times 768$ 个像素构成。这表示我们需要 $2\times 25\times 1024\times 768\times 24=944\text{Mbps}$ 。这种数据速率需要一种高数据速率技术，如同步光纤网络SONET技术。如果使用低速率技术发送视频，就需要对视频进行压缩。

29.2 音频和视频压缩

通过因特网传送音频和视频需要进行压缩。本节先讨论音频压缩，然后再讨论视频压缩。

29.2.1 音频压缩

音频压缩可以用于语音和音乐。对于语音，需要压缩为 $64\text{KHz}$ 的数字化信号，对于音乐，需要压缩为 $1.411\text{MHz}$ 的信号。用于音频压缩的两类技术是：预测编码和感知编码。

1. 预测编码

在预测编码 predictive encoding 技术中，对样本之间的差异 the differences between the samples 进行编码，而不是对所有采样值进行编码。这种类型的压缩技术常用于语音。已经定义了几种标准，如 GSM (13kbps) 、G.729 (8kbps) 和 G.723.3 (6.4 or 5.3kbps) 。对这些技术的详细讨论已经超出了范围。

2. 感知编码: MP3

用于创建CD质量音频 CD-quality audio 的最常用的压缩技术是基于感知编码 perceptual encoding 的技术。如前所述，这种类型的音频至少需要 $1.411\text{Mbps}$ ，如果不进行压缩是无法通过因特网进行发送的。MP3 MPEG audio layer 3 ，作为MPEG标准的一部分（在视频压缩的小节中讨论）就使用这种技术。

感知编码应用了声音心理学的科学知识。声音心理学是研究人们如何感知声音的。这种思想是基于人类听觉系统的某些缺陷：一些声音可以遮掩其他声音，遮掩现象在频率和时间上都可以出现。如频率遮掩 frequency masking ，某一频率范围内的较强声音，能够部分或者全部遮掩另一个频率范围内较弱的声音。例如，如果在一个房间里，一个重金属乐队正在演奏，我们很难听到舞伴在说什么。在暂时遮掩 temporal masking 中，很强的声音可以使耳朵在它停止后的短时间内失去听觉。

MP3利用频率遮掩和暂时遮掩这两种现象来压缩音频信号。这种技术对频谱进行分析、并分为不同的组。完全被掩盖的频率分配零比特 Zero bits are allocated to the frequency ranges that are totally masked ，部分遮掩的频率分配的比特数较小，无遮频率分配的比特数值较大。

MP3产生三种数据速率：$96\text{Kbps}$ 、$128\text{Kbps}$ 和 $160\text{Kbps}$ 。该速率基于原始模拟音频中的频率范围。

29.2.2 视频压缩

前面已经讲过，视频是由多个帧构成的，每一帧是一幅图像。可以通过先压缩图像的方法来压缩视频。市场上目前有两种常用的标准。联合图像专家组 Joint Photographic Experts Group, JPEG 用于压缩图像，而运动图像专家组 Moving Picture Experts Group, MPEG 用于压缩视频。首先简单讨论JPEG，然后再讨论MPEG。

1. 图像压缩: JPEG

如前所述，如果图片不是彩色的（灰度），那么每个像素可以用 $8$ 位的整数（$256$ 级灰度）来表示。如果图片是彩色的，那么每个像素可以用 $24$ 位（$3\times 8$ 位）表示，红、绿、蓝 RGB 分别用 $8$ 位表示。为了简化讨论，只关注灰度图片。

在JPEG中，灰度图片被分割为 $8\times 8$ 的像素块（如图29.2所示）。将图片分割为块的目的是为了减少计算量。下面很快就会看到，每一张图片的数据计算次数是单元数目的平方 the number of mathematical operations for each picture is the square of the number of units. 。

JPEG的总体思想是，将图片转换成一个线性的数字集合（向量）a linear (vector) set of numbers ，以显示冗余。然后，可以使用一种文本压缩方法来删除冗余（缺少变化）的部分。图29.3是一个简化版本的处理过程。

(1) 离散余弦变换

这一步将每个 $64$ 像素的块进行一种变换，称为离散余弦变换 Discrete Cosine Transform, DCT 。变换会改变这 $64$ 个值，这样就可以保持像素之间的相对关系、但却显示冗余部分。这里不给出公式，只给出三种情况下的变换结果。

• 第一种情况：在这种情况下，我们有一个单一灰度的块，每个像素的值是 $20$ 。当我们进行变换时，我们得到的第一个元素的值是非 $0$ 值（左上角），其余像素的值是 $0$ 。$T(0,0)$ 的值是 $P(x,y)$ 值的平均值（乘以一个常数），称为 direct current, dc 值（即直流电，从电子工程中借用）；$T(m,n)$ 中的其余值称为 ac 值，表示像素值的变化，由于没有变化，所以其余的值都是 $0$（如图29.4所示）。（DC、AC？）
  
• 第二种情况：在第二种情况下，我们有一个块，它带有两种不同均匀灰度的区域 a block with two different uniform gray scale sections 。在两种像素值之间发生一个突变（从 $20$ 到 $50$ ）。做变换时，得到一个 dc 值与一系列非 $0$ 的 ac 值。但是，只有少数非 $0$ 值聚集在 dc 值的周围，多数值是 $0$（如图29.5所示）。
  
• 第三种情况：在第三种情况下，我们有一个块，它是逐步变化的。也就是说，相邻像素间的值没有突变。当我们做变换时，得到一个 dc 值，也得到了很多非 $0$ 的 ac 值（如图29.6所示）。
  

通过图29.4、图29.5和图29.6，我们可以得出下面的结论:

• 变换从表 $P$ 中建立表 $T$ 。
• dc 值是所有像素的平均值（乘以一个常数）。
• ac 值是变化的。
• 相邻像素之间没有变化时，生成 $0$ 值。

(2) 量化

$T$ 表建立以后，将数值进行量化、以减少编码所需要的位数。以前在量化 quantization 时，我们从每个值中去掉小数部分，只保留整数部分。这里，我们用一个常数除每一个数，然后再舍掉小数部分 divide the number by a constant and then drop the fraction ，这样会更进一步减少所需要的位数。在大多数实现方法中，量化表（ $8\times 8$ ）定义了如何量化每一个数值。除数取决于值在T表中的位置 The divisor depends on the position of the value in the T table 。这样做是为了，优化每一个特定应用中位的数量和 $0$ 的数量。

处理过程中唯一不可逆的阶段是量化阶段 the only phase in the process that is not reversible is the quantizing phase 。在这里会丢掉某些信息，而且是不可恢复的。事实上，JPEG称为有损压缩 lossy compression 的唯一原因，是因为存在这个量化阶段。

(3) 压缩

量化以后，从表中读取所有的值，并把冗余的 $0$ 去掉。但是，为了把 $0$ 聚集在一起 to cluster the 0s together ，表是按对角呈"之"字形读取的，而不是按行或者按列读取。原因是，如果图片平滑地变化，则T表的右下角会是全 $0$ 。图29.7说明了这一过程。

2. 视频压缩: MPEG

运动图像专家组 MPEG 方法用于压缩视频。从原理上讲，运动图像是按顺序快速移动的一组帧，每一帧都是一幅图像 a motion picture is a rapid flow of a set of frames, where each frame is an image 。换句话说，帧是像素的空间组合，而视频是顺序发送的帧的时间组合 a frame is a spatial combination of pixels, and a video is a temporal combination of frames that are sent one after another 。压缩视频，其含义是在空间上压缩每一帧，而在时间上压缩一组帧 spatially compressing each frame and temporally compressing a set of frames 。

(1) 空间压缩

每一帧的空间压缩 spatial compression 通过JPEG完成（或者JPEG的修改版）。每一帧是一幅图像，可以单独进行压缩。

(2) 时间压缩

在时间压缩 temporal compression中会去掉冗余帧。当我们看电视时，每秒接收 $50$ 帧（不一定）。但是，大多数的连续帧几乎是相同的。例如，假设某个人在说话，除了帧中嘴唇部分外，大多数帧与前一帧是相同的，而嘴唇这一部分在每一帧中都可能会变化。

在时间域上压缩数据，MPEG方法首先将帧分为三类：I-frames, P-frames, and B-frames ，如图29.8所示。

• I-帧，即内部编码帧 intracoded frame, I-frame 。一个I-帧是一个独立帧，与其他任何帧没有关系（与之前或之后发送的帧都没有关系）。它们以固定的时间间隔出现（例如，every ninth frame is an I-frame ）。I-帧必须定期出现，以处理前面的帧和后面的帧 the previous and following frames 无法显示的、帧中的某些突然变化。
  此外，当播放视频时，观看者可能会随时调整它的接收机。如果在广播开始时只有一个I-帧，那么晚调接收机的观众，可能会接收不到完整的画面。I-帧独立于其他帧，不能从其他帧中构造。
• P-帧，即预测帧 predicted frame, P-frame ，与前面的I-帧或P-帧有关。换言之，每一个P--帧只包含前一帧中变化的部分。这些变化的部分当然不能覆盖大的段 The changes, however, cannot cover a big segment 。例如，对于一个快速移动的物体，这些新变化可能不会记录在P-帧中。P-帧只能够从前面的I-帧或P-帧来构造。P-帧比其他类型的帧携带的信息要少得多，压缩后占用的位数甚至更少 P-frames carry much less information than other frame types and carry even fewer bits after compression。
• B-帧，即双向帧 bidirectional frame, B-frame ，与前面和后面的I-帧或P-帧有关。换句话说，每一个B-帧与过去和将来都有关联。注意，一个B-帧与另一个B-帧没有任何关系。
  

图29.9显示了I-帧、P-帧和B-帧是如何从连续的七个帧中构
造的。

MPEG已经发展了两个版本。MPEG1用于数据速率是 $1.5\text{Mbps}$ 的CD-ROM，MPEG2用于数据速率是 $3\text{Mbps}～6\text{Mbps}$ 的高质量DVD。

29.3 流式存储的音频/视频

既然已经讨论过了音频/视频的数字化和压缩 digitizing and compressing audio/video ，那么现在就可以把注意力转向一些特定的应用了。首先是流式存储的音频和视频 streaming stored audio and video 。从Web服务器中下载这些类型的文件，可能与下载其他类型的文件有所不同。要理解这一概念，我们先讨论四种方法，每一种都有不同的复杂度。

29.3.1 第一种方法：使用 Web服务器

压缩的音频/视频文件，可以像文本文件一样下载。客户端（浏览器）使用HTTP服务，发送GET报文下载文件。Web服务器可以将压缩的文件发送到浏览器中。然后，浏览器借助于一个通常称为媒体播放器 media player 的应用程序播放文件。图29.10说明了这一方法。

这种方法很简单，还没有涉及到流 streaming 。但是，它存在缺陷。即使压缩以后，一个音频/视频文件通常仍然很大。音频文件可能包含几十兆字节，而视频文件可能包含几百兆字节。在这种实现方法中，文件在播放之前需要完整地下载下来，使用目前的数据速率，用户在文件播放之前，需要几秒或者几十秒的时间来下载文件。

29.3.2 第二种方法：使用带有元文件的Web服务器

在这种方法中，媒体播放器直接连接到Web服务器、并下载音频/视频文件。Web服务器存储两种文件，实际的音频/视频文件和一个元文件 metafile ，元文件中包含了音频/视频文件的有关信息。图29.11说明了这种方法的步骤。

1. HTTP客户端使用GET报文访问Web服务器。
2. 响应中包含元文件的有关信息。
3. 元文件传输到媒体播放器。
4. 媒体播放器使用元文件中指定的URL，访问音频/视频文件。
5. Web服务器做出响应。
   

29.3.3 第三种方法：使用媒体服务器

第二种方法中存在的问题是，浏览器和媒体播放器都使用HTTP服务，而HTTP是运行在TCP之上的。它适合于检索元文件，但是不适合检索音频/视频文件。原因在于TCP会重发丢失或者损坏的段，这刚好与流的原理相反 TCP retransmits a lost or damaged segment, which is counter to the philosophy of streaming 。所以我们不需要使用TCP和它的纠错控制，而是应该使用UDP。但用于访问Web服务器的HTTP、以及Web服务器自身，都是为TCP设计的，所以需要另外一种服务器，即媒体服务器 media server ，图29.12说明了这一思想。

1. HTTP客户端使用GET报文访问Web服务器。
2. 响应中含有元文件的有关信息。
3. 元文件传送到媒体播放器。
4. 媒体播放器使用元文件中的URL访问媒体服务器以下载文件。下载可以通过任何使用UDP的协议进行 Downloading can take place by any protocol that uses UDP 。
5. 媒体服务器做出响应。
   

29.3.4 第四种方法:使用媒体服务器和 RTSP

实时流协议 Real-Time Streaming Protocol, RTSP 是一种控制协议，被设计用来为流的处理增加更多的功能。使用 RTSP，可以控制音频/视频的播放。RTSP是一种带外控制协议，与FTP中的第二种连接很相似 RTSP is an out-of-band control protocol that is similar to the second connection in FTP 。图29.13说明了媒体服务器和RTSP。

1. HTTP客户使用GET报文访问Web服务器。
2. 响应中含有元文件的有关信息。
3. 元文件传送到媒体播放器。
4. 媒体播放器发送一条 SETUP 报文，建立与媒体服务器的连接。
5. 媒体服务器晌应。
6. 媒体播放器发送一条 PLAY 报文以启动播放（下载）。
7. 使用一种运行在UDP之上的协议，下载音频/视频文件。
8. 使用 TEARDOWN 报文断开连接。
9. 媒体服务器响应。
   

媒体播放器能够发送其他类型的报文。例如，一条 PAUSE 报文能够暂时中止下载过程；通过 PLAY 报文，可以重新开始下载。

29.4 流式实时音频/视频

流式实时音频/视频 streaming live audio/video 类似于通过电台和电视台播放的音频和视频节目。区别在于站台通过因特网、而不是无线电波播出 Instead of broadcasting to the air, the stations broadcast through the Internet 。

流式存储音频/视频与流式实时音频/视频之间有一些相似性，它们都对延迟很敏感，并且都不能接受重新传输。但也有一些区别——在第一种应用情况下，通信是单播和点播的 unicast and on-demand 。在第二种情况下，通信是多播和实时的 multicast and live 。实时流 live streaming 更适合于IP多播服务和「UDP与RTP等协议的使用（稍后讨论）」。但是目前，实时流仍然使用TCP和多个单播代替多播 using TCP and multiple unicasting instead of multicasting 。在这一方面，仍然有许多需要改进的地方。

29.5 实时交互式音频/视频

在实时交互式音频/视频 real-time interactive audio/video 中，人们相互之间进行实时通信。因特网电话或者IP语音是这种应用的实例。视频会议是另一个例子，人们可以进行可视化通信和交谈。在讨论这类应用使用的协议之前，先讨论一下实时音频/视频通信的一些特性。

1. 时间关系

在分组交换网络上的实时数据，需要保持一次会话期间各分组之间的时间关系。例如，我们假定有一个实时视频服务器创建了实时视频图像，并在线发送。视频被数字化并打包分组。只有三个分组，每个分组保存 $10$ 秒的视频信息。第一个分组从 $00:00:00$ 开始，第二个分组从 $00:00:10$ 开始，第三个分组从 $00:00:20$ 开始。假定每个分组花费 $1$ 秒的时间到达目的地（为了简化，夸张了一些），接收方可以在 $00:00:01$ 播放第一个分组，在 $00:00:11$ 播放第二个分组，在 $00:00:21$ 播放第三个分组。虽然「服务器发送的内容」与「客户端在计算机屏幕上看到的内容」之间存在 $1$ 秒的时间差，但操作基本是实时的，分组之间的时间关系被保留，而 $1$ 秒的时间延迟并不重要。图29.14说明了这种思想。

但是，如果这些分组有不同的时间延迟，到达后会发生什么情况呢？例如，第一个分组在 $00:00:01$ 到达（ $1$ 秒的延迟），第二个分组在 $00:00:15$ 时刻到达（ $5$ 秒的延迟），第三个分组在 $00:00:27$ 到达（ $7$ 秒的延迟）。如果接收方在 $00:00:01$ 时刻播放第一个分组，则会在 $00:00:11$ 时刻结束播放。但是下一个分组还没有到达，要在 $4$ 秒之后才会到达。远方站点观看这一视频时，在第一个分组和第二个分组之间会出现间断，同样在第二个分组和第三个分组之间也有时间间断。这种现象称为抖动 jitter（由于分纽之间的延迟，实时数据中会有抖动现象）。图29.15说明了这种情况。

2. 时间戳

解决抖动的一种方案是为分组加上时间戳 timestamp ，将播放时间与到达时间进行分离。如果每一个分组都有一个时间戳，标明它相对于第一个（或前一个）分组的产生时间 the time it was produced relative to the first (or previous) packet ，那么接收方就能够将它的播放开始时间加上这一段时间 add this time to the time at which it starts the playback 。换句话说，接收方能够确定每一个分组的播放起始时间。

在上面的例子中，假设第一个分组的时间戳是 $0$ ，第二分组的时间戳是 $10$ ，第三个分组的时间戳是 $20$ 。如果接收方在 $00:00:08$ 时刻播放第一个分组，则第二个分组会在 $00:00:18$ 时刻开始播放，第三个在 $00:00:28$ 时刻开始播放。这样在分组之间就没有间断了。图29.16说明了这种情况。

3. 回放缓冲区

为了将到达时间与播放时间分离开，需要一个缓冲区存储数据、直到回放开始。该缓冲区称为回放缓冲区 playback buffer 。当会话开始（第一个分组的第一位到达）时，接收方会延迟播放数据，直到到达一个阈值。在上一个例子中，第一个分组的第一位在 $00:00:01$ 到达，阈值是 $7$ 秒，回放时刻是 $00:00:08$ 。阈值通过数据的时间单元计算 The threshold is measured in time units of data 。一直等到数据的时间单元数等于阈值时，重新播放才会开始。

数据可能以可变的速率存储在缓冲区中，但它们是以固定速率提取和回放的 Data are stored in the buffer at a possibly variable rate, but they are extracted and played back at a fixed rate 。请注意，缓冲区中的数据量可以缩小或扩大，但只要延迟小于回放阈值数据量的时间 as long as the delay is less than the time to play back the threshold amount of data ，就不会出现抖动。图29.17显示了示例中在不同时刻的缓冲区。

4. 排序

除了时间关系信息和用于实时通信量 real-time traffic 的时间戳以外，还需要更多的特性。每一个分组需要一个序列号 sequence number 。只靠时间戳是不能通知接收方是否有分组丢失的。例如，假定时间戳是 $0$ 、$10$ 和 $20$ 。如果第二个分组丢失了，那么接收方只收到两个分组，时间戳是 $0$ 和 $20$ 。接收方假定时间戳为 $20$ 的分组是第二个分组，也就是第一个分组 $20$ 秒钟以后产生的。接收方没有办法确定第二个分组已经丢失。要处理这种情况，需要一个序列号对分组进行排序。

5. 多播

多媒体播放在音频和视频会议中发挥着重要作用。（实时）通信量负载可能很重，数据通过使用多播 multicasting 的方式进行分发。会议在接收方和发送方之间需要双向通信。

6. 转换

实时通信量有时需要转换 translation ，转换器是一台计算机，它能够将高带宽视频信号的格式、转换为低质量的窄带信号。这种转换是必要的，例如，源方以 $5\text{Mbps}$ 的速率创建了一种高质量的视频信号，并通过低于 $1\text{Mbps}$ 的带宽发送给接收方。要接收到这种信号，就需要转换器将信号解码，然后再次编码成只需要低带宽的低质量视频信号。转换的含义是改变有效载荷的编码，降低其质量、以匹配接收方的网络带宽 Translation means changing the encoding of a payload to a lower quality to match the bandwidth of the receiving network 。

7. 混合

如果有多个源方能够同时发送数据（如在视频或者音频会议中），通信量由多个数据流组成。要将通信量减少为一个数据流，就需要将来自多个源方的数据混合为一个数据流。混合器 mixer 通过数学算法将来自多个源方的信号相加，建立单一信号。混合意味着将通信量中的多个数据流纽合为一个数据流。

8. 传输层协议的支持

前面各小节提到的各个过程，在应用层都能够实现。但是由于它们在实时应用中有共同的特性，因而在传输层实现应该是更可取的。现在看一下，哪一种现有的传输层协议适合于这种类型的通信量。

尽管有很多高级的特性，TCP不适合交互式通信 interactive traffic 。它不提供时间戳，也不支持多播。但是它能够提供排序（序列号）。TCP的一个使它特别不适合于交互式通信量的特性，就是纠错控制机制。在交互式通信中，不允许重新发送一个丢失或者损坏的分组。如果分组在交互通信中丢失或损坏，则必须忽略它。重发会破坏时间戳和回放的整体思想 Retransmission upsets the whole idea of time-stamping and playback 。目前，在音频和视频信号（即使经过压缩）中存在大量冗余，我们可以简单地忽略一个丢失的分组，远方的收听者和观看者甚至不会察觉到这种情况。

UDP更适合于交互式多媒体通信。UDP支持多播、并且没有重发策略。但是，UDP不支持时间戳、排序和混合。一个新的传输层协议，实时传输协议 Real-time Transport Protocol, RTP 提供了这些混合的特性、用来弥补UDP的不足。

29.6 实时传输协议

实时传输协议 Real-Time Transport Protocol, RTP 是用来处理因特网上实时通信的协议。RTP没有分发机制（多播、端口号等），它必须与UDP一起使用。RTP位于UDP和应用程序之间 RTP stands between UDP and the application program 。RTP的主要作用是时间戳、排序和混合功能 time-stamping, sequencing, and mixing facilities 。图29.18说明了RTP在协议族中的位置。

29.6.1 RTP分组格式

图29.19说明了RTP分组头部的格式。这个格式非常简单、而且通用，适合于所有的实时应用。如果应用需要更多的信息，则可以将其添加到有效负载的开头。 下面是每个字段的描述说明。
如果将该I位字段设置为1，则表示数据包末尾存在填充。在这种情况下，填充中最后一个字节的值定义了填充的长度。如果数据包是加密的，填充是常态。如果P字段的值为0，则没有填充

• 版本 Ver 。这是一个 $2$ 位的字段，定义了版本号。现在的版本是 $2$ 。
• 填充位 P 。这是一个 $1$ 位的宇段。如果值为 $1$ ，则表示分组末尾存在填充，此时填充中最后一个字节的值为填充的长度 the value of the last byte in the padding defines the length of the padding 。如果分组是加密的，则填充是标准的 Padding is the norm if a packet is encrypted 。如果值为 $0$ ，则没有填充。
• 扩展标记位 X 。这是一个 $1$ 位的宇段。如果值为 $1$ ，则说明在基础头部与数据之间有额外的扩展头部 an extra extension header between the basic header and the data 。如果值为 $0$ ，则没有额外的扩展头部。
• 贡献源计数 Contributor count 。这是一个 $4$ 位的字段，说明了参与者的个数。注意：$4$ 位字段只能允许的最大数为 $15$ ，所以最多参与者为 $15$ 。
• 标志位 M 。这 $1$ 位的字段是由应用指示的标志 an extra extension header between the basic header and the data ，例如用来表示数据的结束。
• 有效载荷类型 Payload type 。这是一个 $7$ 位的字段，说明了有效载荷的类型。目前为止，已经定义了许多有效载荷类型。在表29.1中列出了一些常用的应用。对这些类型的讨论超出了范围。
  
• 序列号 Sequence number 。这是 $16$ 位长的字段，用来给RTP分组进行编号。第一个分组的序列号是随机选择的、对后续的每一个分组则加 $1$ 。接收者用序列号检测丢失或者次序颠倒的分组 detect lost or out-of-order packets 。
• 时间戳 Timestamp 。这是 $32$ 位长的字段，用来说明各分组之间的时间关系。第一个分组的时间戳是一个随机数，对随后的每一个分组，它的时间戳的值为前一分组的值与第一个字节产生的时间之和（取样值） the value is the sum of the preceding timestamp plus the time the first byte is produced (sampled) 。时钟计时单元 clock tick 的值依赖于应用，例如，音频应用通常产生 $160$ 字节的大块，那么这个应用的时钟计时单元就是 $160$ 。 对每个RTP分组，该应用程序的时间戳增加 $160$ 。（？）
• 同步源标识符 Synchronization source identifier 。如果只有一个源，那么这个 $32$ 位就定义了源。然而，如果存在多个源，那么混合器是同步源，其他源都是贡献源 the mixer is the synchronization source and the other sources are contributors 。源标识符的值是由源选取的一个随机数。协议提供了冲突情况下的一个策略（两个源以相同的序列号开始）。
• 贡献源标识符 Contributor identifier 。这些 $32$ 位标识符中的每个（最大个数是 $15$ ）定义一个源。当一个会话中有多个源时，混合器是同步源、而其余的源都是贡献源。

29.6.2 UDP端口

尽管RTP本身是一种传输层协议，但RTP分组并非直接封装为IP数据报。相反，RTP被当作应用程序对待，被封装成UDP用户数据报。但是，与其他应用程序不同，没有为RTP分配熟知端口号。端口可以按需要选择，这里只有一个限制：RTP使用的临时端口号必须是偶数 RTP uses a temporary even-numbered UDP port 。（它的）下一个端口号（奇数）由RTP的伴随协议一一实时传输控制协议使用。

29.7 实时传输控制协议

RTP只支持一种类型的报文，该报文负责将数据从源方传送到目的方 RTP allows only one type of message, one that carries data from the source to the destination 。在多数情况下，在会话中还需要其他报文。这些报文用于控制流量和数据质量，允许接收方向一个或者多个源方发送反馈。实时传输控制协议 Real-Time Transport Control Protocol, RTCP 就是为这种目的而设计的。

RTCP有五种类型的报文，如图29.20所示。紧跟在每个方格后面的数字定义了报文的类型。

29.7.1 发送方报告

发送方报告 Sender Report 由会议中的主动发送方定期发送，用来报告在一定的时间间隔内、所有RTP分组的发送和接收的统计数据。发送方报告包括一个绝对时间戳，是从1970年1月1 日午夜算起的秒数。绝对时间戳允许接收方同步不同的RTP报文 The absolute timestamp allows the receiver to synchronize different RTP messages 。当音频和视频同时传输时（音频和视频传输使用单独的相对时间戳），这显得特别重要。

29.7.2 接收方报告

接收方报告 Receiver Report 是给被动参与者的 for passive participants ，这些被动参与者不发送RTP分组。报告通知发送方和接收方有关服务质量的信息。

29.7.3 源描述报文

源方周期性发送源描述报文 Source Description Message ，提供关于自身的附加信息。这种信息可能是名字、电子邮件地址、电话号码、源控制者或者所有者的地址。

29.7.4 关闭报文

源方发送关闭报文 Bye Message 来关闭流。它允许源方宣布要离开会议。尽管其他源方能够检测到一个源方的缺席，但是这条报文是一个直接的宣告 this message is a direct announcement. 。它对混合器也是非常有用的。

29.7.5 特定应用报文

特定应用报文 Application-Specific Message 是希望使用新的应用（没有在标准中定义）的一个应用的分组 a packet for an application that wants to use new applications (not defined in the standard) 。它允许定义新的报文类型。

29.7.6 UDP端口

与RTP一样，RTCP不使用熟知的UDP端口。它使用临时端口，且选择的UDP端口号，必须是紧随「为RTP选定的UDP端口号」后面的那个数，它必须是一个编号为奇数的端口。

29.8 IP语音

下面主要讨论一种实时交互式音频/视频应用 real-time interactive audio/video application ：IP语音 voice over IP ，即因特网电话。它的思想是将因特网作为电话网络使用，并且提供一些附加功能。这种应用允许通过分组交换网络实现双方通信，从而取代了电路交换网络中的通信。

SIP和H.323两种协议用来处理这种类型的通信。下面简要介绍一下这两种协议。

29.8.1 SIP

会话初始化协议 Session Initiation Protocol, SIP
由IETF设计。它是一种应用层协议，能够建立、管理和终止多媒体会话（呼叫）。它可以用来创建双方、多方或者多播会话 two-party, multiparty, or multicast sessions 。SIP在设计上是独立于下面的传输层的，它能够运行在UDP、TCP或者SCTP之上。

1. 报文

SIP是一种类似HTTP的基于文本的协议。与HTTP类似，SIP也使用报文。己定义的六种SIP报文如图29.21所示。

每一种报文都有头部和主体。头部由多行构成，描述了报文的结构、呼叫方的功能、媒体类型等。下面给出每一种报文的简单描述，然后在简单会话中说明它们的应用。

• 呼叫方使用 INVITE 报文初始化会话。
• 被呼叫方应答呼叫，呼叫方发送 ACK 报文用于确认。
• BYE 报文可以终止会话。
• OPTIONS 报文查询一台机器的功能。
• CANCEL 报文取消已经启动的初始化进程。
• REGISTER 报文在被呼叫方不可用时，建立一个连接 The REGISTER message makes a connection when the callee is not available 。

2. 地址

在常规的电话通信中，一个电话号码可用于识别发送方，而另一个电话号码用于识别接收方。SIP非常灵活。在SIP 中，电子邮件地址、IP地址、电话号码和其他类型的地址都能用于识别发送方和接收方。但是，地址必须使用SIP格式（也称为 scheme )。图29.22列出了一些常用的格式。

3. 简单会话

一个使用SIP的简单会话由三个模块组成：建立、通信和终止。图29.23说明一个使用SIP的简单会话。

• 建立会话：在SIP中建立一次会话需要三次握手。呼叫方使用UDP、TCP或者SCTP发送 INVITE 报文开始通信。如果被呼叫方愿意启动会话，它会发送一条响应报文。为了确认已经接收到的回复代码，呼叫方会发送一条 ACK 报文进行确认。
• 通信：会话建立以后，呼叫方和被呼叫方能够通过两个临时端口进行通信。
• 终止会话：任何一方发送一条 BYE 报文，会话就会结束。

4. 跟踪被呼叫方

如果被呼叫方没有坐在终端前面，会发生什么情况呢？她可能离开了自己的系统，或者在另一台终端前面。如果使用DHCP，他甚至不会有固定的IP地址。

SIP使用一种机制（与DNS中的一种类似），能够查找到被呼叫方所处的终端的IP地址。要执行跟踪，SIP使用注册 registration 的概念。SIP规定了一些服务器、作为注册服务器 register server 。任何时刻，用户至少注册到一台服务器上，这台服务器就能知道被呼叫方的IP地址。

当呼叫方需要与被呼叫方通信时，呼叫方可以用电子邮件地址、代替在 INVITE 报文中的IP地址。报文会传送到代理服务器。代理服务器发送一条查询报文（不属于SIP的一部分）到某台被呼叫方注册的服务器。当代理服务器从注册服务器接收到回复报文时，代理服务器取出呼叫方的 INVITE 报文，插入新发现的被呼叫方的IP地址，然后将这条报文发送到被呼叫方。图29.24说明了这一过程。

29.8.2 H.323

H.323是ITU制定的一个标准，它允许公共电话网络上的电话与连接到因特网上的计算机（在H.323中，称为 terminals ）进行通话。图29.25说明了H.323的总体结构。

网关 gateway 将因特网连接到电话网络中。通常，网关是一种五层设备，能够把报文从一个协议栈转换到另一个协议栈。此处的网关实际上做同样的事情，它将电话网络报文转换为因特网报文。本地局域网的关守 gatekeeper ，承担着注册服务器的角色，正如在SIP协
议中讨论的一样。

1. 协议

H.323使用多种协议来建立和维护音频（或者视频）通信。图29.26列出了这些协议。

H.323使用G.71或G.723.1进行压缩。使用一个名为H.245的协议，实现通信方之间压缩方法的协商。Q.931协议用于建立和终止连接。H.225或 Registration/Administration/Status, RAS 协议用于与关守的注册。

2. 操作

下面用一个简单的例子，说明使用H.323协议进行电话通信的操作步骤。图29.27说明了一台计算机终端与一部电话之间通信的步骤。

1. 终端向关守发送广播报文。关守用它自己的IP地址响应。
2. 终端与关守通信，使用H.225协商带宽。
3. 终端、关守、网关和电话使用Q.931通信，以建立连接。
4. 终端、关守、网关和电话通信，使用H.245协商压缩方法。
5. 终端、网关和电话使用RTP，在RTCP的管理下交换音频。
6. 终端、网关和电话使用Q.931终止通信。
   

超强干货来袭

云风专访：近40年码龄，通宵达旦的技术人生