第8章 互联网上的音频/视频服务¶
第 8 章 互联网上的音频 / 视频服务¶
本章首先对互联网提供音频 / 视频服务进行概述。然后介绍流式音频 / 视频中的媒体服务器和实时流式协议 RTSP，并以 IP 电话为例介绍交互式音频 / 视频所使用的一些协议，如实时运输协议 RTP、实时传送控制协议 RTCP、H.323 以及会话发起协议 SIP。接着讨论改进 “尽最大努力交付” 服务的一些措施，包括怎样使互联网能够提高服务质量，并介绍综合服务 IntServ、资源预留协议 RSVP 和区分服务 DiffServ 的要点。
本章最重要的内容是；
8.1 概述¶
计算机网络最初是为传送数据设计的。互联网 IP 层提供的 “尽最大努力交付” 服务以及每一个分组独立交付的策略，对传送数据信息十分合适。互联网使用的 TCP 协议可以很好地解决 IP 层不能提供可靠交付这一问题。
然而技术的进步使许多用户开始利用互联网传送音频 / 视频信息。在许多情况下，这种音频 / 视频常称为多媒体信息 \(^{①}\) 。本来电路交换的公用电话网传送话音和多媒体信息早已是成熟的技术。例如视频会议（又称为电视会议）原先是使用电路交换的公用电话网。使用电路交换的好处是：一旦连接建立了（也就是只要拨通了电话），各种信号在电话线路上的传输质量就有保证。但使用公用电话网的缺点是价格太高。因此要想办法改用互联网。
多媒体信息（包括声音和图像信息）与不包括声音和图像的数据信息有很大的区别，其中最主要的两个特点如下。
第一，多媒体信息的信息量往往很大。¶
含有音频或视频的多媒体信息的信息量一般都很大，下面是简单的说明。
对于电话的声音信息，如采用标准的 PCM 编码（8 kHz 速率采样），而每一个采样脉冲用 8 位编码，则得出的声音信号的数据率就是 64 kbit/s。对于高质量的立体声音乐 CD 信息，虽然它也使用 PCM 编码，但其采样速率为 44.1 kHz，而每一个采样脉冲用 16 位编码，因此这种双声道立体声音乐信号的数据率超过了 1.4 Mbit/s。
再看一下数码照片。假定分辨率为 \(1280 \times 960\) （中等质量）。若每个像素用 24 位进行编码，则一张未经压缩的照片的字节数约合 3.52 MB（这里 1 B = 8 bit, \(1 M = 2^{20}\) ）。
活动图像的信息量就更大，如不压缩的彩色电视信号的数据率超过 250 Mbit/s。
因此在网上传送多媒体信息都无例外地采用各种信息压缩技术。例如在话音压缩方面的标准有：移动通信的 GSM（13 kbit/s），IP 电话使用的 G.729（8 kbit/s）和 G.723.1（6.4 kbit/s 和 5.3 kbit/s）；在立体声音乐的压缩技术有 MP3（128 kbit/s 或 112 kbit/s）。在视频信号方面有：VCD 质量的 MPEG 1（1.5 Mbit/s）和 DVD 质量的 MPEG 2（3\~6 Mbit/s）。由于多媒体信息压缩技术本身不是计算机网络技术范畴，本书将不讨论有关数据压缩方面的内容。
第二，在传输多媒体数据时，对时延和时延抖动均有较高的要求。¶
首先要说明的是，“传输多媒体数据” 隐含地表示了 “边传输边播放” 的意思。因为如果是把多媒体音频 / 视频节目先下载到计算机的硬盘中，等下载完毕后再去播放，那么在互联网上传输多媒体数据就没有什么更多的特点值得我们专门来讨论（仅仅是数据量非常大而已）。设想我们想欣赏网上的某个视频或音频节目。如果必须先花好几个小时（准确的时间事先还不知道）来下载它，等下载完毕后才能开始播放，那么这显然是很不方便的。因此，今后讨论在互联网上传输多媒体数据时，都是指含有 “边传输边播放” 的特点。
我们知道，模拟的多媒体信号只有经过数字化后才能在互联网上传送。就是对模拟信号要经过采样和模数转换变为数字信号，然后将一定数量的比特组装成分组进行传送。这些分组在发送时的时间间隔都是恒定的，通常称这样的分组为等时的 (isochronous)。这种等时分组进入互联网的速率也是恒定的。但传统的互联网本身是非等时的。这是因为在使用 IP 协议的互联网中，每一个分组是独立地传送，因而这些分组在到达接收端时就变成为非等时的。如果我们在接收端对这些以非恒定速率到达的分组边接收边还原，那么就一定会产生很大的失真。图 8-1 说明了互联网是非等时的这一特点。
要解决这一问题，可以在接收端设置适当大小的缓存 \(^{①}\) ，当缓存中的分组数达到一定的数量后再以恒定速率按顺序将这些分组读出进行还原播放。图 8-2 说明了缓存的作用。
从图 8-2 可看出，缓存实际上就是一个先进先出的队列。图中标明的 T 叫作播放时延，这就是从最初的分组开始到达缓存算起，经过时间 T 后就按固定时间间隔把缓存中的分组按先后顺序依次读出。我们看到，缓存使所有到达的分组都经受了迟延。由于分组以非恒定速率到达，因此早到达的分组在缓存中停留的时间较长，而晚到达的分组在缓存中停留的时间就较短。从缓存中取出分组是按照固定的时钟节拍进行的，因此，到达的非等时的分组，经过缓存后再以恒定速率读出，就变成了等时的分组（但请注意，时延太大的分组就丢弃了），这就在很大程度上消除了时延的抖动。但我们付出的代价是增加了时延。以上所述的概念可以用图 8-3 来说明。
图 8-3 画出了发送端一连发送 6 个等时的分组。如果网络没有时延，那么到达的分组数随时间的变化就如图中最左边的阶梯状的曲线所示。这就是说，只要发送方一发出一个分组，在接收方到达的分组数就立即加 1。但实际的网络使每一个分组经受的时延不同，因此这一串分组在到达接收端时就变成了非等时的，这就使得分组到达的阶梯状曲线向右移动，并且变成不均匀的。图 8-3 标注出了分组 1 的时延。图中给出了两个不同的开始播放时刻。黑色小圆点表示在播放时刻对应的分组已经在缓存中，而空心小圆圈表示在播放时刻对应的分组尚未到达。我们可以看出，即使推迟了播放时间（如图中的①），也还有可能有某个迟到分组赶不上播放（如图中的空心小圆圈）。如果再推迟播放时间（如图中的②），则所有的 6 个分组都不会错过播放，但这样做的时延会较大。
然而我们还有一些问题没有讨论。
首先，播放时延 T 应当选为多大？把 T 选择得越大，就可以消除更大的时延抖动，但所有分组经受的平均时延也增大了，而这对某些实时应用（如视频会议）是很不利的。当然这对单向传输的视频节目问题并不太大（如从网上下载一段视频节目，只要耐心多等待一段时间用来将分组放入缓存即可）。如果 T 选择得太小，那么消除时延抖动的效果就较差。因此播放时延 T 的选择必须折中考虑。在传送时延敏感 (delay sensitive) 的实时数据时，不仅传输时延不能太大，而且时延抖动也必须受到限制。
其次，在互联网上传输实时数据的分组时有可能会出现差错或甚至丢失。如果利用 TCP 协议对这些出错或丢失的分组进行重传，那么时延就会大大增加。因此实时数据的传输在运输层就应采用用户数据报协议 UDP 而不使用 TCP 协议。这就是说，对于传送实时数据，我们宁可丢失少量分组（当然不能丢失太多），也不要太晚到达的分组。在连续的音频或视频数据流中，很少量分组的丢失对播放效果的影响并不大（因为这是由人来进行主观评价的），因而是可以容忍的。丢失容忍 (loss tolerant) 也是实时数据的另一个重要特点。
由于分组的到达可能不按序，但将分组还原和播放时又应当是按序的。因此在发送多媒体分组时还应当给每一个分组加上序号。这表明还应当有相应的协议支持才行。
还有一种情况，就是要使接收端能够将节目中本来就存在的正常的短时间停顿（如话音中的静默期或音乐中出现的几拍停顿）和因某些分组产生的较大迟延造成的 “停顿” 区分开来。这就需要在每一个分组增加一个时间戳 (timestamp)，让接收端知道所收到的每一个分组是在什么时间产生的。
有了序号和时间戳，再采用适当的算法，接收端就知道应在什么时间开始播放缓存中收到的分组。这样既可减少分组的丢失率，也可使播放的延迟在人们可容忍的范围之内。
根据以上的讨论可以看出，若想在互联网上传送质量很好的音频 / 视频数据，就需要设法改造现有的互联网使它能够适应音频 / 视频数据的传送。
对这个问题，网络界一直有较大的争论，众说纷纭。有人认为，只要大量使用光缆，网络的时延和时延抖动就可以足够小。再加上使用具有大容量高速缓存的高速路由器，在互联网上传送实时数据就不会有问题。也有人认为，必须将互联网改造为能够对端到端的带宽实现预留 (reservation)，从而根本改变互联网的协议栈 —— 从无连接的网络转变为面向连接的网络。还有人认为，部分改动互联网的协议栈所付出的代价较小，而这也能够使多媒体信息在互联网上的传输质量得到改进。
尽管上述的争论仍在继续，但互联网的一些新的协议也在不断出现。下面我们有选择地讨论与传送音频 / 视频信息有关的若干问题。
目前互联网提供的音频 / 视频服务大体上可分为三种类型：
(1) 流式 (streaming) 存储音频 / 视频 这种类型是先把已压缩的录制好的音频 / 视频文件（如音乐、电影等）存储在服务器上。用户通过互联网下载这样的文件。请注意，用户并不是把文件全部下载完毕后再播放，因为这往往需要很长时间，而用户一般也不大愿意等待太长的时间。流式存储音频 / 视频文件的特点是能够边下载边播放，即在文件下载后不久（例如，一般在缓存中存放最多几十秒）就开始连续播放。请注意，普通光盘中的 DVD 电影文件不是流式视频文件。如果我们打算下载一部光盘中的普通的 DVD 电影，那么你只能花费很长的时间把整个电影文件全部下载完毕后才能播放。请注意，flow 的译名也是 “流”（或 “流量”），但意思和 streaming 完全不同。
(2) 流式实况音频 / 视频 这种类型和无线电台或电视台的实况广播相似，不同之处是音频 / 视频节目的广播是通过互联网来传送的。流式实况音频 / 视频是一对多 (而不是一对一) 的通信。它的特点是：音频 / 视频节目不是事先录制好和存储在服务器中的，而是在发送方边录制边发送 (不是录制完毕后再发送)。在接收时也要求能够连续播放。接收方收到节目的时间和节目中事件的发生时间可以认为是同时的 (相差仅仅是电磁波的传播时间和很短的信号处理时间)。流式实况音频 / 视频按理说应当采用多播技术才能提高网络资源的利用率，
但目前实际上还是使用多个独立的单播。
(3) 交互式音频 / 视频 这种类型是用户使用互联网和其他人进行实时交互式通信。现在的互联网电话或互联网电视会议就属于这种类型。
请注意，对于流式音频 / 视频的 “下载”，实际上并没有把 “下载” 的内容存储在硬盘上。因此当 “边下载边播放” 结束后，在用户的硬盘上没有留下有关播放内容的任何痕迹。播放流式音频 / 视频的用户，仅仅能够在屏幕上观看播放的内容。用户既不能修改节目内容，也不能把播放的内容存储下来，因此也无法进行转发。这对保护版权非常有利。
不过技术总是在不断进步的，现在已经有了能够存储在网上播放的流式音频 / 视频文件的软件。
我们现在常见的词汇流媒体 (streaming media) 就是上面所说的流式音频 / 视频。流媒体最主要的特点就是不是全部都收录下来再开始播放。在国外的一些文献中，常见到 streaming 一词，网上有人译为 “串流” 或 “流播”，但目前还没有找到对 streaming 更好的译名。
限于篇幅，下面简单介绍上面的第一种和第三种音频 / 视频类型的服务。
8.2 流式存储音频 / 视频¶
“流式存储音频 / 视频” 中的 “存储” 二字，表明这里所讨论的流式音频 / 视频文件不是实时产生的，而是已经录制好的，通常存储在光盘或硬盘中。不过有时为了简便，往往省略 “存储” 二字。在讨论从网上下载这种文件之前，我们先回忆一下使用传统的浏览器是怎样从服务器下载已经录制好的音频 / 视频文件的。图 8-4 说明了下载的三个步骤。
为什么不能直接在浏览器中播放音频 / 视频文件呢？这是因为播放器并没有集成在万维网浏览器中。因此，必须使用一个单独的应用程序来播放这种音频 / 视频节目。这个应用程序通常称为媒体播放器 (media player)。现在流行的媒体播放器有 Real Networks 的 RealPlayer、微软的 Windows Media Player 和苹果公司的 QuickTime。媒体播放器具有的主要功能是：管理用户界面、解压缩、消除时延抖动和处理传输带来的差错。
请注意，图 8-4 所示传统的下载文件的方法并没有涉及 “流式”（即边下载边播放）的概念。传统的下载方法最大缺点就是历时太长，这往往使下载者不愿继续等待。为此，已经找出了几种改进的措施。
8.2.1 具有元文件的万维网服务器¶
第一种改进的措施就是在万维网服务器中，除了真正的音频 / 视频文件外，还增加了一个元文件 (metafile)。所谓元文件（请注意，不是源文件）就是一种非常小的文件，它描述或指明其他文件的一些重要信息。这里的元文件保存了有关这个音频 / 视频文件的信息。图 8-5 说明了使用元文件下载音频 / 视频文件的几个步骤。
8.2.2 媒体服务器¶
为了更好地提供播放流式音频 / 视频文件的服务，现在最为流行的做法就是使用两个分开的服务器。如图 8-6 所示，现在使用一个普通的万维网服务器，和另一个媒体服务器 (media server)。媒体服务器和万维网服务器可以运行在一个端系统内，也可以运行在两个不同的端系统中。媒体服务器与普通的万维网服务器的最大区别就是，媒体服务器是专门为播放流式音频 / 视频文件而设计的，因此能够更加有效地为用户提供播放流式多媒体文件的服务。因此媒体服务器也常被称为流式服务器 (streaming server)。下面我们介绍其工作原理。
在用户端的媒体播放器与媒体服务器的关系是客户与服务器的关系。与图 8-5 不同的是，现在媒体播放器不是向万维网服务器而是向媒体服务器请求音频 / 视频文件。媒体服务器和媒体播放器之间采用另外的协议进行交互。
采用媒体服务器后，下载音频 / 视频文件的前三个步骤仍然和上一节所述的一样，区别就是后面两个步骤，即：
上面提到，传送音频 / 视频文件可以使用 TCP，也可以使用 UDP。起初人们选用 UDP 来传送。不采用 TCP 的主要原因是担心当网络出现分组丢失时，TCP 的重传机制会使重传的分组不能按时到达接收端，使得媒体播放器的播放不流畅。但后来的实践经验发现，采用 UDP 会有以下几个缺点。
(1) 发送端按正常播放的速率发送流媒体数据帧，但由于网络的情况多变，在接收端的播放器很难做到始终按规定的速率播放。例如，一个视频节目需要以 1 Mbit/s 的速率播放。如果从媒体服务器到媒体播放器之间的网络容量突然降低到 1 Mbit/s 以下，那么这时就会出现播放器的暂停，影响正常的观看。
(2) 很多单位的防火墙往往阻拦外部 UDP 分组的进入，因而使用 UDP 传送多媒体文件时会被防火墙阻拦掉。
(3) 使用 UDP 传送流式多媒体文件时，如果在用户端希望能够控制媒体的播放，如进行暂停、快进等操作，那么还需要使用另外的协议 RTP（见 8.3.3 节）和 RTSP（见 8.2.3 节）。这样就增加了成本和复杂性。
于是，现在对流式存储音频 / 视频的播放，如 YouTube 和 Netflix \(^{①}\) ，都采用 TCP 来传送。图 8-7 说明了使用 TCP 传送流式视频的几个主要步骤 [KURO17]。
步骤①：用户使用 HTTP 获取存储在万维网服务器中的视频文件，然后把视频数据传送到 TCP 发送缓存中。若发送缓存已填满，就暂时停止传送。
步骤②：从 TCP 发送缓存通过互联网向客户机中的 TCP 接收缓存传送视频数据，直到接收缓存被填满。
步骤③：从 TCP 接收缓存把视频数据再传送到应用程序缓存（即媒体播放器的缓存）。这叫作预先存储。当预先存储在缓存中的视频数据存储到一定数量时，就开始播放。这个过程一般不超过 1 分钟。
步骤④：在播放时，媒体播放器等时地（即周期性地）把视频数据按帧读出，经解压缩后，把视频节目显示在用户的屏幕上。
请注意。这里只有步骤④的读出速率是严格按照源视频文件的规定速率来播放的。而前面的三个步骤中的数据传送速率则可以是任意的。如果用户暂停播放，那么图中的三个缓存将很快被填满，这时 TCP 发送缓存就暂停读取所要传送的视频文件，否则就会引起视频数据的丢失。以后，当用户继续播放时，媒体播放器每读出 n bit，TCP 发送缓存就可以从存储的视频文件再读取 n bit。如果客户机中的两个缓存经常处于填满状态，就能够较好地应付网络中偶然出现的拥塞。
如果步骤②的传送速率小于步骤④的读出速率，那么客户机中的两个缓存中的存量就会逐渐减少。当媒体播放器缓存的数据被取空后，播放就不得不暂停，直到后续的视频数据重新注入进来后才能再继续播放。实践证明，只要在步骤②的 TCP 平均传送速率达到视频节目规定的播放速率的两倍，媒体播放器一般就能流畅地播放网上的视频节目。
这里要指出，如果是观看实况转播，那么最好应当首先考虑使用 UDP 来传送。如果使用 TCP 传送，则当出现网络严重拥塞而产生播放的暂停时，就会使人难于接受。使用 UDP 传送时，即使因网络拥塞丢失了一些分组，对观看的感觉也会比突然出现暂停要好些。
顺便指出，我们在家中的宽带上网并不能保证媒体播放器一定能够流畅地回放任何视频节目。这是因为网络营运商只能保证，从用户家中到网络运营商的某个路由器之间的这段网络的数据速率。但从网络运营商到互联网上下载视频的某个媒体服务器的这段网络状况则是未知的，很可能在某些时段会出现一些网络拥塞。此外，还要考虑所选的视频节目的清晰度所要求的传输带宽。我们都知道，DVD 质量的视频和高清电视或 4K 超高清视频节目所要求的网速就相差很远。
流式媒体播放器问世后就很受欢迎。网民们不需要再随身携带刻录有视频节目的光盘，只要有能够上网的智能手机或轻巧的平板电脑，就能够随时上网观看各种视频音频节目。曾经在城市中很热闹的光盘销售商店，由于受到流式媒体的冲击，现已变得相当萧条。
8.2.3 实时流式协议 RTSP¶
实时流式协议 RTSP (Real-Time Streaming Protocol) 是 IETF 的 MMUSIC 工作组 (Multiparty Multimedia Session Control WG，多方多媒体会话控制工作组) 开发的协议，现在是 RTSP 2.0 [RFC 7826，建议标准]。RTSP 是为了给流式过程增加更多的功能而设计的协议。RTSP 本身并不传送数据，而仅仅是使媒体播放器能够控制多媒体流的传送（有点像文件传送协议 FTP 有一个控制信道），因此 RTSP 又称为带外协议 (out-of-band protocol)。
RTSP 协议以客户 - 服务器方式工作，它是一个应用层的多媒体播放控制协议，用来使用户在播放从互联网下载的实时数据时能够进行控制（像在影碟机上那样的控制），如：暂停 / 继续、快退、快进等。因此，RTSP 又称为 “互联网录像机遥控协议”。
RTSP 的语法和操作与 HTTP 协议的相似（所有的请求和响应报文都是 ASCII 文本）。但与 HTTP 不同的地方是 RTSP 是有状态的协议（HTTP 是无状态的）。RTSP 记录客户机所处于的状态（初始化状态、播放状态或暂停状态）。RFC 7826 还规定，RTSP 控制分组既可在 TCP 上传送，也可在 UDP 上传送。RTSP 没有定义音频 / 视频的压缩方案，也没有规定音频 / 视频在网络中传送时应如何封装在分组中。RTSP 不规定音频 / 视频流在媒体播放器中应如何缓存。
在使用 RTSP 的播放器中比较著名的是苹果公司的 QuickTime 和 Real Networks 公司的 RealPlayer。
图 8-8 表示使用 RTSP 的媒体服务器的工作过程。
此后，音频 / 视频文件被下载，所用的协议是运行在 UDP 上的。可以是后面要介绍的 RTP，也可以是其他专用的协议。在音频 / 视频流播放的过程中，媒体播放器可以随时暂停（利用 PAUSE 报文）和继续播放（利用 PLAY 报文），也可以快进或快退。
⑧ 用户在不想继续观看时，可以由 RTSP 客户发送 TEARDOWN 报文断开连接。
⑨ 媒体服务器的 RTSP 服务器发送响应 RESPONSE 报文。
请注意，以上编号的步骤④至⑨都使用实时流协议 RTSP。在图 8-8 中步骤⑦后面没有编号的 “音频 / 视频流” 则使用另外的传送音频 / 视频数据的协议，如 RTP。
8.3 交互式音频 / 视频¶
限于篇幅，在本节中我们只介绍交互式音频，即 IP 电话。IP 电话是在互联网上传送多媒体信息的一个例子。通过 IP 电话的讨论，可以有助于了解在互联网上传送多媒体信息应当解决好哪些问题。
8.3.1 IP 电话概述¶
1. 狭义的和广义的 IP 电话¶
IP 电话有多个英文同义词。常见的有 VoIP (Voice over IP), Internet Telephony 和 VON (Voice On the Net)。但 IP 电话的含义却有不同的解释。
狭义的 IP 电话就是指在 IP 网络上打电话。所谓 “IP 网络” 就是 “使用 IP 协议的分组交换网” 的简称。这里的网络可以是互联网，也可以是包含有传统的电路交换网的互联网，不过在互联网中至少要有一个 IP 网络。
广义的 IP 电话则不仅仅是电话通信，而且还可以是在 IP 网络上进行交互式多媒体实时通信（包括话音、视像等），甚至还包括即时传信 IM (Instant Messaging)。即时传信是在上网时就能从屏幕上得知有哪些朋友也正在上网。若有，则彼此可在网上即时交换信息（文字的或声音的），也包括使用一点对多点的多播技术。目前流行的即时传信应用程序有微信、Skype、QQ 和 MSN Messenger [CHEN07]，很受网民的欢迎。IP 电话可看成是一个正在演进的多媒体服务平台，是话音、视像、数据综合的基础结构。在某些条件下（例如使用宽带的局域网），IP 电话的话音质量甚至还优于普通电话。
下面讨论狭义的 IP 电话 [COLL01]，而广义的 IP 电话在原理上是一样的。
其实 IP 电话并非新概念。早在 20 世纪 70 年代初期 ARPANET 刚开始运行不久，美国即着手研究如何在计算机网络上传送电话信息，即所谓的分组话音通信。但在很长一段时间里，分组话音通信发展得并不快。主要的原因是：
2. IP 电话网关¶
然而到了 20 世纪 90 年代中期，上述的几个问题才相继得到了较好的解决。于是美国的
VocalTec 公司在 1995 年初率先推出了实用化的 IP 电话。但是这种 IP 电话必须使用 PC。1996 年 3 月，IP 电话进入了一个转折点：VocalTec 公司成功地推出了 IP 电话网关（IP Telephony Gateway），它是公用电话网 \(^{①}\) 与 IP 网络的接口设备。IP 电话网关的作用就是：
(1) 在电话呼叫阶段和呼叫释放阶段进行电话信令的转换。
(2) 在通话期间进行话音编码的转换。
有了这种 IP 电话网关，就可实现 PC 用户到固定电话用户打 IP 电话（仅需经过 IP 电话网关一次），以及固定电话用户之间打 IP 电话（需要经过 IP 电话网关两次）。
图 8-9 画出了 IP 电话几种不同的连接方式。图中最上面的情况最简单，是两个 PC 用户之间的通话。这当然不需要经过 IP 电话网关，但必须是双方都同时上网才能进行通话。图 8-9 中间的一种情况是 PC 到固定电话之间的通话。最后一种情况是两个固定电话之间打 IP 电话，这当然是最方便的。读者应当特别注意在哪一部分是使用电路交换还是分组交换。
3. IP 电话的通话质量¶
IP 电话的通话质量与电路交换电话网的通话质量有很大差别。在电路交换电话网中，任何两端之间的通话质量都是有保证的。但 IP 电话则不然。IP 电话的通话质量主要由两个因素决定，一个是通话双方端到端的时延和时延抖动，另一个是话音分组的丢失率。但这两个因素都是不确定的，而是取决于当时网络上的通信量。若网络上的通信量非常大以致发生了网络拥塞，那么端到端时延和时延抖动以及分组丢失率都会很高，这就导致 IP 电话的通话质量下降。因此，一个用户使用 IP 电话的通话质量取决于当时其他许多用户的行为。请注意，电路交换电话网的情况则完全不是这样。当电路交换电话网的通信量太大时，往往使我们无法拨通电话（听到的是忙音），即电话网拒绝对正在拨号的用户提供接通服务。但是只要我们拨通了电话，那么电信公司就能保证让用户享受满意的通话质量。
经验证明，在电话交谈中，端到端的时延不应超过 250 ms，否则交谈者就会感到不自然。陆地公用电话网的时延一般只有 50\~70 ms。但经过同步卫星的电话端到端时延就超过 250 ms，一般人都不太适应经过卫星传送的过长的时延。IP 电话的时延有时会超过 250 ms，因此 IP 电话必须努力减小端到端的时延。当通信线路产生回声时，则容许的端到端时延就更小些（有时甚至只容许几十毫秒的时延）。
IP 电话端到端时延是由以下几个因素造成的:
(4) 话音分组在互联网中经过许多路由器的存储转发时延。
(5) 话音分组到达接收端在缓存中暂存所引起的时延。
(6) 将话音分组还原成模拟话音信号的数模转换也要产生一定的时延。
(7) 话音信号在通信线路上的传播时延。
(8) 由终端设备的硬件和操作系统产生的接入时延。由 IP 电话网关引起的接入时延约为 20\~40 ms，而用户 PC 声卡引起的接入时延为 20\~180 ms。有的调制解调器（如 V.34）还会再增加 20\~40 ms 的时延（由于进行数字信号处理、均衡等）。
话音信号在通信线路上的传播时延一般都很小（卫星通信除外），通常可不予考虑。当采用高速光纤主干网时，上述的第三项时延也不大。
第一、第二和第六项时延取决于话音编码的方法。很明显，在保证话音质量的前提下，话音信号的数码率应尽可能低些。为了能够在世界范围提供 IP 电话服务，话音编码就必须采用统一的国际标准。ITU-T 已制定出不少话音质量不错的低速率话音编码的标准。目前适合 IP 电话使用的 ITU-T 标准主要有以下两种：
这两种标准的比较见表 8-1。
表 8-1 G.729 和 G.723.1 的主要性能比较
| 标准 | 比特率(kbit/s) | 帧大小(ms) | 处理时延(ms) | 帧长(字节) | 数字信号处理MIPS |
| G.729 | 8 | 10 | 10 | 10 | 20 |
| G.723.1 | 5.3/6.3 | 30 | 30 | 20/24 | 16 |
表中的比特率是输入为 64 kbit/s 标准 PCM 信号时在编码器输出的数据率。帧大小是压缩到每一个分组中的话音信号时间长度。处理时间是对一个帧运行编码算法所需的时间。帧长是一个已编码的帧的字节数（不包括首部）。数字信号处理 MIPS（每秒百万指令）是用数字信号处理芯片实现编码所需的最小处理机速率（以每秒百万指令为单位）。如使用 PC 的通用处理机，则所需的处理机 MIPS 还要高些。不难看出，G.723.1 标准虽然可得到更低的数据率，但其时延也更大些。
要减少上述第四和第五项时延较为困难。当网络发生拥塞而产生话音分组丢失时，还必须采用一定的策略（称为 “丢失掩蔽算法”）对丢失的话音分组进行处理。例如，可使用前一个话音分组来填补丢失的话音分组的间隙。
接收端缓存空间和播放时延的大小对话音分组丢失率和端到端时延也有很大的影响。图 8-10 说明了这一问题。话音质量可分为四个级别，即 “长途电话质量”（这是最好的质量）、“良好”“基本可用” 和 “不好”，各对应于图 8-10 中的一个区域。越接近坐标原点，话音质量就越好。我们假定某 IP 电话的通话质量处在图中 B 点的位置。若增大接收端缓存空间并增大播放时延，则话音分组丢失率将减小，但端到端的时延将增大（如图中的 C 点）。继续增大播放时延，则话音分组丢失率将继续减小，趋向于网络所引起的丢失率（如图中的 D 点），但 D 点的端到端时延很大，话音质量很不好。反之，若将接收端缓存做得很小并减小播放时延，则端到端时延将减小，趋向于网络所引起的端到端时延（如图中的 A 点），但话音分组丢失率将会大大增加，话音质量也不好。
可见接收端的播放时延有一个最佳值。图中有一个点 N，相当于端到端时延和话音分组丢失率都是最小的，但实际上并不可能工作在这个点上。
据统计，当通话双方相距 3200 km 时，互联网上的时延约为 30\~100 ms（传播和排队），而所有各环节的时延总和约为 100\~262 ms（在两个 IP 电话网关之间）或 170\~562 ms（在两个 PC 之间）[KAST98]。可见为了减小时延，应尽可能不要直接用 PC 打 IP 电话。
提高路由器的转发分组的速率对提高 IP 电话的质量也是很重要的。据统计，一个跨大西洋的 IP 电话一般要经过 20\~30 个路由器。现在一个普通路由器每秒可转发 50\~100 万个分组。若能改用吉比特路由器（又称为线速路由器），则每秒可转发 500 万至 6000 万个分组（即交换速率达 60 Gbit/s 左右）。这样还可进一步减少由网络造成的时延。
近几年来，IP 电话的质量得到了很大的提高。现在许多 IP 电话的话音质量已经优于固定电话的话音质量。一些电信运营商还建造了自己专用的 IP 电话线路，以便保证更好的通话质量。在 IP 电话领域里，最值得一提的就是 Skype IP 电话，它给全世界的广大用户带来了高品质并且廉价的通话服务。Skype 使用了 Global IP Sound 公司开发的互联网低比特率编解码器 iLBC (internet Low Bit rate Codec)[RFC 3951, 3952]，进行话音的编解码和压缩，使其话音质量优于传统的公用电话网（采用电路交换）的话音质量。Skype 支持两种帧长：20 ms（速率为 15.2 kbit/s，一个话音分组块为 304 bit）和 30 ms（速率为 13.33 kbit/s，一个话音分组块为 400 bit）。Skype 的另一个特点是对话音分组的丢失进行了特殊的处理，因而能够容忍高达 30% 的话音分组丢失率，通话的用户一般感觉不到话音的断续或迟延，杂音也很小。
Skype 采用了 P2P（见第 6 章 6.9 节的介绍）和全球索引（Global Index）技术提供快速路由选择机制（而不是单纯依靠服务器来完成这些工作），因而其管理成本大大降低，在用户呼叫时，由于用户路由信息分布式存储于互联网的节点中，因此呼叫连接完成得很快。Skype 还采用了端对端的加密方式，保证信息的安全性。Skype 在信息发送之前进行加密，在接收时进行解密，在数据传输过程中完全没有可能在中途被窃听。
由于 Skype 使用的是 P2P 的技术，用户数据主要存储在 P2P 网络中，因此必须保证存储在公共网络中的数据是可靠的和没有被篡改的。Skype 对公共目录中存储的和用户相关的数据都采用了数字签名，保证了数据无法被篡改。
自 2003 年 8 月 Skype 推出以来，在短短 15 个月内，Skype 已拥有超过 5000 万次的下载量，注册量超过 2000 万用户，并且还在以每天超过 15 万用户的速度增长。在 2011 年，在同一时间使用 Skype 的用户数已经突破了 3000 万大关。据统计，在 2014 年的国际长途电话的市场份额中，Skype 已经占据了 40%。Skype 的问世给全球信息技术和通信产业带来深远的影响，也给每一位网络使用者带来生活方式的改变。
8.3.2 IP 电话所需要的几种应用协议¶
在 IP 电话的通信中，我们至少需要两种应用协议。一种是信令协议，它使我们能够在互联网上找到被叫用户 \(^{①}\) 。另一种是话音分组的传送协议，它使我们用来进行电话通信的话音数据能够以时延敏感属性在互联网中传送。这样，为了在互联网中提供实时交互式的音频 / 视频服务，我们需要新的多媒体体系结构。
图 8-11 给出了在这样的体系结构中的三种应用层协议。第一种协议是与信令有关的，如 H.323 和 SIP（画在最左边）；第二种协议是直接传送音频 / 视频数据的，如 RTP（画在最右边）；第三种协议是为了提高服务质量，如 RSVP 和 RTCP（画在中间）。
下面先介绍实时运输协议 RTP 及其配套的协议 —— 实时运输控制协议 RTCP，然后再介
绍 IP 电话的信令协议 H.323 和会话发起协议 SIP。
8.3.3 实时运输协议 RTP¶
实时运输协议 RTP (Real-time Transport Protocol) 是 IETF 的 AVT 工作组 (Audio/Video Transport WG) 开发的协议，现已成为互联网标准 [RFC 3550, STD64] [RFC 3551, STD65]。
RTP 为实时应用提供端到端的运输，但不提供任何服务质量的保证。需要发送的多媒体数据块（音频 / 视频）经过压缩编码处理后，先送给 RTP 封装成为 RTP 分组（也可称为 RTP 报文 \(^{①}\) ）。RTP 分组装入运输层的 UDP 用户数据报后，再向下递交给 IP 层。RTP 现已成为互联网正式标准，并且已被广泛使用。RTP 同时也是 ITU-T 的标准（H.225.0）。实际上，RTP 是一个协议框架，因为它只包含了实时应用的一些共同功能。RTP 自己并不对多媒体数据块做任何处理，而只是向应用层提供一些附加的信息，让应用层知道应当如何进行处理。
图 8-11 把 RTP 协议画在应用层。这是因为从应用开发者的角度看，RTP 应当是应用层的一部分。在应用程序的发送端，开发者必须编写用 RTP 封装分组的程序代码，然后把 RTP 分组交给 UDP 套接字接口。在接收端，RTP 分组通过 UDP 套接字接口进入应用层后，还要利用开发者编写的程序代码从 RTP 分组中把应用数据块提取出来。
然而 RTP 的名称又隐含地表示它是一个运输层协议。这样划分也是可以的，因为 RTP 封装了多媒体应用的数据块，并且由于 RTP 向多媒体应用程序提供了服务（如时间戳和序号），因此也可以把 RTP 看成是在 UDP 之上的一个运输层子层的协议。
RTP 还有两点值得注意。首先，RTP 分组只包含 RTP 数据，而控制是由另一个配套使用的 RTCP 协议提供的（这在下一节介绍）。其次，RTP 在端口号 1025 到 65535 之间选择一个未使用的偶数 UDP 端口号，而在同一次会话中的 RTCP 则使用下一个奇数 UDP 端口号。但端口号 5004 和 5005 则分别用作 RTP 和 RTCP 的默认端口号。
图 8-12 给出了 RTP 分组的首部格式，下面进行简单的介绍。
在 RTP 分组的首部中，前 12 个字节是必需的，而 12 字节以后的部分则是可选的。下面按照各字段重要性的顺序来进行介绍。
(1) 有效载荷类型 (payload type) 占 7 位。这个字段指出后面的 RTP 数据属于何种格式的应用。收到 RTP 分组的应用层就根据此字段指出的类型进行处理。例如，对于音频有效载荷（每一种格式后面括弧中的数字就表示其有效载荷类型的编码）： \(\mu\) 律 PCM (0), GSM (3), LPC (7), A 律 PCM (8), G.722 (9), G.728 (15) 等。对于视频有效载荷：活动 JPEG (26), H.261 (31), MPEG1 (32), MPEG2 (33) 等。
(2) 序号 占 16 位。对每一个发送出的 RTP 分组，其序号加 1。在一次 RTP 会话开始时的初始序号是随机选择的。序号使接收端能够发现丢失的分组，同时也能将失序的 RTP 分组重新按序排列好。例如，在收到序号为 60 的 RTP 分组后又收到了序号为 65 的 RTP 分组。那么就可推断出，中间还缺少序号为 61 至 64 的 4 个 RTP 分组。
(3) 时间戳 占 32 位。时间戳反映了 RTP 分组中数据的第一个字节的采样时刻。在一次会话开始时时间戳的初始值也是随机选择的。即使在没有信号发送时，时间戳的数值也要随时间而不断地增加。接收端使用时间戳可准确知道应当在什么时间还原哪一个数据块，从而消除时延的抖动。时间戳还可以用来使视频应用中声音和图像同步。在 RTP 协议中并没有规定时间戳的粒度，这取决于有效载荷的类型。因此 RTP 的时间戳又称为媒体时间戳，以强调这种时间戳的粒度取决于信号的类型。例如，对于 8 kHz 采样的话音信号，若每隔 20 ms 构成一个数据块，则一个数据块中包含有 160 个样本（0.02 × 8000 = 160）。因此发送端每发送一个 RTP 分组，其时间戳的值就增加 160。
(4) 同步源标识符 占 32 位。同步源标识符 SSRC (Synchronous SouRCe identifier) 是一个数，用来标志 RTP 流 (stream) 的来源。SSRC 与 IP 地址无关，在新的 RTP 流开始时随机地产生。由于 RTP 使用 UDP 传送，因此可以有多个 RTP 流（例如，使用几个摄像机从不同角度拍摄同一个节目所产生的多个 RTP 流）复用到一个 UDP 用户数据报中。SSRC 可使接收端的 UDP 能够将收到的 RTP 流送到各自的终点。两个 RTP 流恰好都选择同一个 SSRC 的概率是极小的。若发生这种情况，这两个源就都重新选择另一个 SSRC。
(5) 参与源标识符 这是选项，最多可有 15 个。参与源标识符 CSRC (Contributing SouRCe identifier) 也是一个 32 位数，用来标志来源于不同地点的 RTP 流。在多播环境中，可以用中间的一个站（叫作混合站 mixer）把发往同一个地点的多个 RTP 流混合成一个流（可节省通信资源），在目的站再根据 CSRC 的数值把不同的 RTP 流分开。
(6) 参与源数 占 4 位。这个字段给出后面的参与源标识符的数目。
(7) 版本 占 2 位。当前使用的是版本 2。
(8) 填充 P 占 1 位。在某些特殊情况下需要对应用数据块加密，这往往要求每一个数据块有确定的长度。如不满足这种长度要求，就需要进行填充。这时就把 P 位置 1，表示这个 RTP 分组的数据有若干填充字节。在数据部分的最后一个字节用来表示所填充的字节数。
(9) 扩展 X 占 1 位。X 置 1 表示在此 RTP 首部后面还有扩展首部。扩展首部很少使用，这里不再讨论。
(10) 标记 M 占 1 位。M 置 1 表示这个 RTP 分组具有特殊意义。例如，在传送视频流时用来表示每一帧的开始。
8.3.4 实时运输控制协议 RTCP¶
实时运输控制协议 RTCP (RTP Control Protocol) 是与 RTP 配合使用的协议 [RFC 3550, 3551]，实际上，RTCP 协议也是 RTP 协议不可分割的部分。
RTCP 协议的主要功能是：服务质量的监视与反馈、媒体间的同步（如某一个 RTP 发送的声音和图像的配合），以及多播组中成员的标志。RTCP 分组（也可称为 RTCP 报文）也使用 UDP 来传送，但 RTCP 并不对音频 / 视频分组进行封装。由于 RTCP 分组很短，因此可以把多个 RTCP 分组封装在一个 UDP 用户数据报中。RTCP 分组周期性地在网上传送，它带有发送端和接收端对服务质量的统计信息报告（例如，已发送的分组数和字节数、分组丢失率、分组到达时间间隔的抖动等）。
表 8-2 是 RTCP 使用的五种分组类型，它们都使用同样的格式。
表 8-2 RTCP 的五种分组类型
| 类型 | 缩写表示 | 意义 |
| 200 | SR | 发送端报告 |
| 201 | RR | 接收端报告 |
| 202 | SDES | 源点描述 |
| 203 | BYE | 结束 |
| 204 | APP | 特定应用 |
结束分组 BYE 表示关闭一个数据流。
特定应用分组 APP 使应用程序能够定义新的分组类型。
接收端报告分组 RR 用来使接收端周期性地向所有的点用多播方式进行报告。接收端每收到一个 RTP 流（一次会话包含有许多的 RTP 流）就产生一个接收端报告分组 RR。RR 分组的内容有：所收到的 RTP 流的 SSRC；该 RTP 流的分组丢失率（若分组丢失率太高，发送端就应当适当降低发送分组的速率）；在该 RTP 流中的最后一个 RTP 分组的序号；分组到达时间间隔的抖动等。
发送 RR 分组有两个目的：第一，可以使所有的接收端和发送端了解当前网络的状态；第二，可以使所有发送 RTCP 分组的站点自适应地调整自己发送 RTCP 分组的速率，使得起控制作用的 RTCP 分组不要过多地影响传送应用数据的 RTP 分组在网络中的传输。通常是使 RTCP 分组的通信量不超过网络中数据分组的通信量的 5%，而接收端报告分组的通信量又应小于所有 RTCP 分组的通信量的 75%。
发送端报告分组 SR 用来使发送端周期性地向所有接收端用多播方式进行报告。发送端每发送一个 RTP 流，就要发送一个发送端报告分组 SR。SR 分组的主要内容有：该 RTP 流的同步源标识符 SSRC；该 RTP 流中最新产生的 RTP 分组的时间戳和绝对时钟时间（或墙上时钟时间 wall clock time）；该 RTP 流包含的分组数；该 RTP 流包含的字节数。
绝对时钟时间是必要的。因为 RTP 要求每一种媒体使用一个流。例如，要传送视频图像和相应的声音就需要传送两个流。有了绝对时钟时间就可进行图像和声音的同步。
源点描述分组 SDES 给出会话中参加者的描述，它包含参加者的规范名 CNAME (Canonical NAME)。规范名是参加者的电子邮件地址的字符串。
8.3.5 H.323¶
现在 IP 电话有两套信令标准：一套是 ITU-T 定义的 H.323 协议，另一套是 IETF 提出的会话发起协议 SIP (Session Initiation Protocol)。我们先介绍 H.323 协议。
H.323 是 ITU-T 于 1996 年制定的为在局域网上传送话音信息的建议书。1998 年 H.323 的第二个版本改用的名称是 “基于分组的多媒体通信系统”。在 2009 年已更新到 H.323v7。基于分组的网络包括互联网、局域网、企业网、城域网和广域网。H.323 是互联网的端系统之间进行实时声音和视频会议的标准。请注意，H.323 不是一个单独的协议而是一组协议。H.323 包括系统和构件的描述、呼叫模型的描述、呼叫信令过程、控制报文、复用、话音编解码器、视像编解码器，以及数据协议等。图 8-13 示意了连接在分组交换网上的 H.323 终端使用 H.323 协议进行多媒体通信。
H.323 标准指明了四种构件，使用这些构件连网就可以进行点对点或一点对多点的多媒体通信。
网关、网闸和 MCU 在逻辑上是分开的构件，但它们可实现在一个物理设备中。在 H.323 标准中，将 H.323 终端、网关和 MCU 都称为 H.323 端点 (end point)。
图 8-14 表示了利用 H.323 网关使互联网能够和公用电话网进行连接。
图 8-15 给出了 H.323 的体系结构。可以看出，H.323 是一个协议族，它可以使用不同的运输协议。H.323 包括以下一些组成部分：
图 8-15 H.323 的协议体系结构
| 音频/视频应用 | 信令和控制 | 数据应用 | ||||
| 音频 编解码 | 视频 编解码 | RTCP | H.225.0 登记 信令 | H.225.0 呼叫 信令 | H.245 控制 信令 | T.120 数据 |
| RTP | ||||||
| UDP | TCP | |||||
| IP | ||||||
(1) 音频编解码器 H.323 要求至少要支持 G.711（64 kbit/s 的 PCM）。建议支持如 G.722（16 kbit/s 的 ADPCM），G.723.1（5.3/6.3 的 LPC），G.728（16 kbit/s 的低时延 CELP）和 G.729（8 kbit/s 的 CS-ACELP）等。
(2) 视频编解码器 H.323 要求必须支持 H.261 标准（176×144 像素）。
(3) H.255.0 登记信令，即登记 / 接纳 / 状态 RAS (Registration/Admission/Status)。H.323 终端和网闸使用 RAS 来完成登记、接纳控制和带宽转换等功能。
(4) H.225.0 呼叫信令用来在两个 H.323 端点之间建立连接。
(5) H.245 控制信令 用来交换端到端的控制报文，以便管理 H.323 端点的运行。
(6) T.120 数据传送协议 这是与呼叫相关联的数据交换协议。用户在参加音频 / 视频会议时，可以和其他与会用户共享屏幕上的白板。由于使用 TCP 协议，因此能够保证数据传送的正确（在传送音频 / 视频文件时使用的是 UDP，因此不能保证服务质量）。
(7) 实时运输协议 RTP 和实时运输控制协议 RTCP 这两个协议前面已讨论。
H.323 的出发点是以已有的电路交换电话网为基础，增加了 IP 电话的功能（即远距离传输采用 IP 网络）。H.323 的信令也沿用原有电话网的信令模式，因此与原有电话网的连接比较容易。
8.3.6 会话发起协议 SIP¶
虽然 H.323 系列现在已被大部分生产 IP 电话的厂商采用，但由于 H.323 过于复杂（整个文档多达 736 页），不便于发展基于 IP 的新业务，因此 IETF 的 MMUSIC 工作组制定了另一套较为简单且实用的标准，即会话发起协议 SIP (Session Initiation Protocol) [RFC 3261—3264]，目前已成为互联网的建议标准。SIP 使用了 KISS 原则：即 “保持简单、傻瓜” (Keep It Simple and Stupid)。
SIP 协议的出发点是以互联网为基础，而把 IP 电话视为互联网上的新应用。因此 SIP 协议只涉及 IP 电话所需的信令和有关服务质量的问题，而没有提供像 H.323 那样多的功能。SIP 没有强制使用特定的编解码器，也不强制使用 RTP 协议。然而，实际上大家还是选用 RTP 和 RTCP 作为配合使用的协议。
SIP 使用文本方式的客户 - 服务器协议。SIP 系统只有两种构件，即用户代理 (user agent) 和网络服务器 (network server)。用户代理包括两个程序，即用户代理客户 UAC (User Agent Client) 和用户代理服务器 UAS (User Agent Server)，前者用来发起呼叫，后者用来接受呼叫。网络服务器分为代理服务器 (proxy server) 和重定向服务器 (redirect server)。代理服务器接受来自主叫用户的呼叫请求（实际上是来自用户代理客户的呼叫请求），并将其转发给被叫用户或下一跳代理服务器，然后下一跳代理服务器再把呼叫请求转发给被叫用户（实际上是转发给用户代理服务器）。重定向服务器不接受呼叫，它通过响应告诉客户下一跳代理服务器的地址，由客户按此地址向下一跳代理服务器重新发送呼叫请求。
SIP 的地址十分灵活。它可以是电话号码，也可以是电子邮件地址、IP 地址或其他类型的地址。但一定要使用 SIP 的地址格式，例如：
和 HTTP 相似，SIP 是基于报文的协议。SIP 使用了 HTTP 的许多首部、编码规则、差错码以及一些鉴别机制。它比 H.323 具有更好的可扩缩性。
SIP 的会话共有三个阶段：建立会话、通信和终止会话。图 8-16 给出了一个简单的 SIP 会话的例子。图中的建立会话阶段和终止会话阶段，都是使用 SIP 协议，而中间的通信阶段，则使用如 RTP 这样的传送实时话音分组的协议。
在图 8-16 中，主叫方先向被叫方发出 INVITE 报文，这个报文中含有双方的地址信息以及其他一些信息（如通话时话音编码方式等）。被叫方如接受呼叫，则发回 OK 响应，而主叫方再发送 ACK 报文作为确认（这和建立 TCP 连接的三报文握手相似）。然后双方就可以通话了。当通话完毕时，双方中的任何一方都可以发送 BYE 报文以终止这次的会话。
SIP 有一种跟踪用户的机制，可以找出被叫方使用的 PC 的 IP 地址（例如，被叫方使用 DHCP，因而没有固定的 IP 地址）。为了实现跟踪，SIP 使用登记的概念。SIP 定义一些服务器作为 SIP 登记器 (registrar)。每一个 SIP 用户都有一个相关联的 SIP 登记器。用户在任何时候发起 SIP 应用时，都应当给 SIP 登记器发送一个 SIP REGISTER 报文，向登记器报告现在使用的 IP 地址。SIP 登记器和 SIP 代理服务器通常运行在同一台主机上。
图 8-17 说明了 SIP 登记器的用途。主叫方把 INVITE 报文发送给 SIP 代理服务器。这个 INVITE 报文中只有被叫方的电子邮件地址而没有其 IP 地址。SIP 代理服务器就向 SIP 登记器发送域名系统 DNS 查询（这个查找报文不是 SIP 的报文），然后从回答报文得到了被叫方的 IP 地址。代理服务器把得到的被叫方的 IP 地址插入到主叫方发送的 INVITE 报文中，转发给被叫方。被叫方发送 OK 响应，然后主叫方发送 ACK 报文，完成了会话的建立。