第12讲-多媒体传输协议

1第12讲多媒体传输协议要求1.理解网络多媒体传输的基本问题和基本解决方法2.理解流式音频视频的基本原理3.理解交互式音频视频的基本原理4.了解多媒体传输协议RTSP、RTP和RTCP212.1概述计算机网络最初是为传送数据信息设计的因特网IP层提供的“尽最大努力交付”服务，以及每一个分组独立交付的策略，对传送数据信息也是很合适的因特网使用的TCP协议可以很好地解决网络不能提供可靠交付这一问题3多媒体信息的特点多媒体信息（包括声音和图像信息）与不包括声音和图像的数据信息有很大的区别多媒体信息的信息量往往很大在传输多媒体数据时，对时延和时延抖动均有较高的要求多媒体数据往往是实时数据(realtimedata)，它的含义是：在发送实时数据的同时，在接收端边接收边播放4因特网是非等时的模拟的多媒体信号经过采样和模数转换变为数字信号，再组装成分组这些分组的发送速率是恒定的（等时的）传统的因特网本身是非等时的

因此经过因特网的分组变成了非恒定速率的分组tt因特网t模拟信号t采样后的信号构成分组恒定速率非恒定速率5接收端需设置适当大小的缓存

当缓存中的分组数达到一定的数量后再以恒定速率按顺序把分组读出进行还原播放缓存实际上就是一个先进先出的队列。图中标明的T叫做播放时延

在接收端设置缓存tT缓存（队列）恒定速率t非恒定速率有可能发生分组丢失6缓存使所有到达的分组都经受了迟延早到达的分组在缓存中停留的时间较长，而晚到达的分组在缓存中停留的时间则较短以非恒定速率到达的分组，经过缓存后再以恒定速率读出，就能够在一定程度上消除了时延的抖动但，付出的代价是：增加了时延缓存的影响分组发出1

2

3

4

5

6t到达分组数6543211

2

3

4

5

6t缓存时间缓存时间再推迟播放时间如果网络无时延推迟播放分组迟到网络出现时延分组1的时延分组到达1

2

34

5

6t实际的网络78需要解决的问题在传送时延敏感(delaysensitive)的实时数据时，不仅传输时延不能太大，而且时延抖动也必须受到限制对于传送实时数据，很少量分组的丢失对播放效果的影响并不大（因为这是由人来进行主观评价的），因而是可以容忍的。丢失容忍(losstolerant)也是实时数据的另一个重要特点9需要解决的问题由于分组的到达可能不按序，但将分组还原和播放时又应当是按序的因此在发送多媒体分组时还应当给每一个分组加上序号。这表明还应当有相应的协议支持才行要使接收端能够将节目中本来就存在的正常的短时间停顿（如音乐中停顿几拍）和因某些分组的较大迟延造成的“停顿”区分开来这就需要增加一个时间戳(timestamp)，以便告诉接收端应当在什么时间播放哪个分组10是否改造现有的因特网？1、大量使用光缆和高速路由器，网络的时延和时延抖动就可以足够小，在因特网上传送实时数据就不会有问题2、把因特网改造为能够对端到端的带宽实现预留(reservation)，把使用无连接协议的因特网转变为面向连接的网络3、部分改动因特网的协议栈所付出的代价较小，而这也能够使多媒体信息在因特网上的传输质量得到改进11目前因特网提供的音频/视频服务大体上可分为三种类型流式(streaming)存储音频/视频——边下载边播放流式实况音频/视频——边录制边发送交互式音频/视频——实时交互式通信12目前因特网提供的音频/视频服务大体上可分为三种类型流式(streaming)存储音频/视频——边下载边播放在这类应用中，客户机根据需求请求存储在服务器上的被压缩的音频或视频文件目前数以千计的场点提供流式存数音频和视频，包括CNN和Youtube等流式实况音频/视频——边录制边发送交互式音频/视频——实时交互式通信13目前因特网提供的音频/视频服务大体上可分为三种类型流式(streaming)存储音频/视频——边下载边播放流式实况音频/视频——边录制边发送这类应用类似于传统的电台广播和电视，只是它通过因特网来传输而已这些应用允许用户接收从世界任何角落发出的实况无线电广播和电视传输交互式音频/视频——实时交互式通信14目前因特网提供的音频/视频服务大体上可分为三种类型流式(streaming)存储音频/视频——边下载边播放流式实况音频/视频——边录制边发送交互式音频/视频——实时交互式通信这类应用允许人们使用音频/视频互相实时通信因特网上的实时交互音频通常称为因特网电话(Internettelephony)，因为从用户角度来看，它类似于传统的电路交换电话服务15“边下载边播放”中的“下载”“边下载边播放”结束后，在用户的硬盘上没有留下有关播放内容的任何痕迹流媒体(streamingmedia)，即流式音频/视频流媒体特点就是“边下载边播放”(streamingandplaying)

1612.2流式存储音频/视频传统的下载文件方法万维网服务器客户机服务器媒体播放器

GET:音频/视频文件

RESPONSE

音频/视频文件浏览器17传统的浏览器从服务器

下载音频/视频文件

用户从客户机(client)的浏览器上用HTTP协议向服务器请求下载某个音频/视频文件服务器如有此文件就发送给浏览器。在响应报文中就装有用户所要的音频/视频文件。整个下载过程可能会花费很长的时间

当浏览器完全收下这个文件后，就可以传送给自己机器上的媒体播放器进行解压缩，然后播放1812.2.1具有元文件的万维网服务器元文件就是一种非常小的文件，它描述或指明其他文件的一些重要信息万维网服务器客户机服务器媒体播放器

元文件浏览器

GET:元文件

RESPONSEGET:音频/视频文件RESPONSE19使用元文件下载音频/视频文件

浏览器用户使用HTTP的GET报文接入到万维网服务器，这个超链接指向一个元文件，这个元文件有实际的音频/视频文件的统一资源定位符URL

万维网服务器把该元文件装入HTTP响应报文的主体，发回给浏览器客户机浏览器调用相关的媒体播放器，把提取出的元文件传送给媒体播放器媒体播放器使用元文件中的URL，向万维网服务器发送HTTP请求报文，要求下载音频/视频文件万维网服务器发送HTTP响应报文，把该音频/视频文件发送给媒体播放器。媒体播放器边下载边解压缩边播放2012.2.2媒体服务器媒体服务器也称为流式服务器(streamingserver)，它支持流式音频和视频的传送媒体播放器与媒体服务器的关系是客户与服务器的关系媒体播放器不是向万维网服务器而是向媒体服务器请求音频/视频文件媒体服务器和媒体播放器之间采用另外的协议进行交互21使用媒体服务器万维网服务器媒体播放器

元文件浏览器

GET:元文件

RESPONSEGET:音频/视频文件RESPONSE媒体服务器客户机服务器22采用媒体服务器

下载音频/视频文件的步骤~

前三个步骤仍然和上一节的一样，区别就是后面两个步骤媒体播放器使用元文件中的URL接入到媒体服务器，请求下载浏览器所请求的音频/视频文件。下载可以借助于使用UDP的任何协议，例如使用实时传输协议RTP

媒体服务器给出响应，把该音频/视频文件发送给媒体播放器。媒体播放器在迟延了若干秒后，以流的形式边下载边解压缩边播放2312.2.3实时流式协议RTSP

(Real-TimeStreamingProtocol)

RTSP协议以客户/服务器方式工作，它是一个多媒体播放控制协议，用来使用户在播放从因特网下载的实时数据时能够进行控制，如：暂停/继续、后退、前进等因此RTSP又称为“因特网录像机遥控协议”要实现RTSP的控制功能，不仅要有协议，而且要有专门的媒体播放器(mediaplayer)和媒体服务器(mediaserver)

24RTSP简介RTSP协议是由RealNetworks(音频/视频流领域的业界领袖之一)和Netcape共同提出的

RTSP协议是一个流媒体协议，用于视频点播、视频会议、视频监控等领域

知名端口：554

RTSP语法是基于文本的，类似HTTP协议RTSP中的所有操作都是通过服务器和客户端的消息应答来完成的，其消息包括请求(Request)和响应(Response)两种25RTSP不能做什么RTSP没有定义用于音频和视频的压缩方案RTSP没有定义音频和视频在网络传输中是怎样封装在分组中的流式媒体的封装可以通过RTP或专用协议来提供RTSP不限制流式媒体如何传输，它可以在UDP或TCP上传输RTSP不限制媒体播放器如何缓冲音频/视频音频/视频可能在它一到达客户机就开始播放，也可能在延迟几秒后播放，或者完全下载下来再播放

26RTSP特点RTSP允许媒体播放器控制媒体流传输暂停/继续、播放重定位、快进和快退等RTSP信道在很多方面和FTP的控制信道类似RTSP本身并不传送数据，而仅仅是使媒体播放器能够控制多媒体流的传送RTSP是一个带外协议(out-of-bandprotocol)

RTSP报文在带外发送，而媒体流的分组结构没有被RTSP定义，它被认为是“带内”的RTSP报文和媒体流使用不同的端口号27RTSP消息格式RTSP的消息有两大类：请求消息

回应消息请求消息：方法URIRTSP版本CRLF消息头CRLFCRLF消息体CRLF28RTSP消息格式说明方法即可用的命令，如：OPTIONS：客户端用于得到服务器提供的可用方法DESCRIBE：客户端用于得到会话描述信息(SDP)SETUP：客户端提醒服务器建立会话，并确定传输模式PLAY：客户端发送播放请求TEARDOWN：客户端发起关闭请求URI是接受方的地址，如：rtsp://36RTSP版本一般都是RTSP/1.0每行后面的CRLF表示回车换行，需要接受端有相应的解析，最后一个消息头需要有两个CRLF29RTSP消息格式回应消息：RTSP版本状态码解释CRLF消息头CRLFCRLF消息体CRLF说明RTSP版本一般都是RTSP/1.0状态码是一个数值

200表示成功

解释是与状态码对应的文本解释

万维网服务器客户机服务器媒体播放器

元文件浏览器媒体服务器音频/视频流

GET:元文件

RESPONSESETUPRESPONSEPLAYRESPONSE

RESPONSE

TEARDOWN

3031使用RTSP的媒体服务器

的工作过程

浏览器向万维网服务器请求音频/视频文件万维网服务器从浏览器发送携带有元文件的响应浏览器把收到的元文件传送给媒体播放器

RTSP客户与媒体服务器的RTSP服务器建立连接

RTSP服务器发送响应RESPONSE报文

RTSP客户发送PLAY报文，开始下载音频/视频文件

RTSP服务器发送响应RESPONSE报文

RTSP客户发送TEARDOWN报文断开连接

RTSP服务器发送响应RESPONSE报文32RTSP交互示例CSSETUPrtsp://9/zuoyou001.mp4/trackID=65537RTSP/1.0CSeq:5User-Agent:LibVLC/1.1.11(LIVE555StreamingMediav2011.05.25)Transport:RTP/AVP/TCP;unicast;interleaved=2-3Session:183719934190660238633RTSP交互示例SCRTSP/1.0200OKServer:DSS/6.0.3(Build/526.3;Platform/FreeBSD;Release/DarwinStreamingServer;State/Development;)Cseq:5Session:1837199341906602386Last-Modified:Thu,17Jan200211:20:30GMTCache-Control:must-revalidateDate:Wed,04Jan201206:14:53GMTExpires:Wed,04Jan201206:14:53GMTTransport:RTP/AVP/TCP;unicast;interleaved=2-3;ssrc=5B56A40534RTSP交互示例CSPLAYrtsp://9/zuoyou001.mp4/RTSP/1.0CSeq:6User-Agent:LibVLC/1.1.11(LIVE555StreamingMediav2011.05.25)Session:1837199341906602386Range:npt=0.000-35RTSP交互示例SCRTSP/1.0200OKServer:DSS/6.0.3(Build/526.3;Platform/FreeBSD;Release/DarwinStreamingServer;State/Development;)Cseq:6Session:1837199341906602386Range:npt=0.00000-6640.12667RTP-Info:url=rtsp://9/zuoyou001.mp4/trackID=65536;seq=55088;rtptime=37707334,url=rtsp://9/zuoyou001.mp4/trackID=65537;seq=19114;rtptime=55015466836RTSP交互示例CSTEARDOWNrtsp://9/zuoyou001.mp4/RTSP/1.0CSeq:7User-Agent:LibVLC/1.1.11(LIVE555StreamingMediav2011.05.25)Session:183719934190660238637RTSP交互示例SCRTSP/1.0200OKServer:DSS/6.0.3(Build/526.3;Platform/FreeBSD;Release/DarwinStreamingServer;State/Development;)Cseq:7Session:1837199341906602386Connection:Close38RTSP与HTTP的异同注意RTSP和HTTP之间的相似性RTSP在语法和操作上与HTTP/1.1类似，因此HTTP的扩展机制在多数情况下可加入RTSP所有的请求和响应报文都是采用ASCII文本格式，客户机使用标准化的方法（SETUP、PLAY、PAUSE等），服务器用标准化的应答码来响应

39RTSP与HTTP的异同一些区别：RTSP中客户端和服务器都可以发出请求在多数情况下，数据由不同的协议传输RTSP服务器一直跟踪每个正在进行的RTSP会话中的客户机状态如服务器记录客户机是位于初始化状态、播放状态还是暂停状态作为每个RTSP请求和响应的一部分，会话号和序号帮助服务器跟踪会话状态会话号在整个会话中不变，客户机每次发送一个新的报文就增加序号服务器使用会话号和现在的序号来回显4012.3交互式音频/视频

12.3.1IP电话概述狭义的IP电话就是指在IP网络上打电话。所谓“IP网络”就是“使用IP协议的分组交换网”的简称广义的IP电话则不仅仅是电话通信，而且还可以是在IP网络上进行交互式多媒体实时通信（包括话音、图像等），甚至还包括即时通信IM(InstantMessaging)

IP电话网关的几种连接方法分组交换电路交换电路交换

因特网PC到PC公用电话网IP

电话网关

因特网PC到固定电话机公用电话网IP

电话网关公用电话网IP

电话网关因特网固定电话机到固定电话机41IP电话网关是公用电话网与IP网络的接口设备1、在电话呼叫阶段和呼叫释放阶段，进行电话信令的转换2、在通话期间，进行话音编码的转换42IP电话的通话质量在电路交换电话网中，任何两端之间的通话质量都是有保证的，但IP电话则不然IP电话的通话质量主要由两个因素决定：一个是通话双方端到端的时延和时延抖动另一个是话音分组的丢失率但这两个因素是不确定的，是取决于当时网络上的通信量网络通信量非常大，以致发生拥塞，就会影响IP电话的通话质量一个用户使用IP电话的通话质量取决于当时其他的许多用户的行为43IP电话的通话质量当电路交换电话网的通信量太大时，往往使我们无法拨通电话但只要拨通电话，那电信公司就能保证让用户满意的通话质量经验证明，在电话交谈中，端到端的时延不应超过250ms，否则交谈者就能感到不自然陆地公用电话网的时延一般只有50~70ms经过同步卫星的电话端到端时延就超过250ms，因此一般人都不太适应经过卫星传送的过长时延44IP电话的端到端时延(1)话音信号进行模数转换要经受时延(2)话音比特流装配成话音分组的时延(3)话音分组的发送时间，此时间等于话音分组长度与通信线路的数据率之比(4)话音分组在因特网中的存储转发时延(5)话音分组在接收端缓存中暂存所引起的时延(6)话音分组还原成模拟话音信号的时延(7)话音信号在通信线路上的传播时延(8)终端设备的硬件和操作系统产生的接入时延45话音信号在通信线路上的传播时延一般都很小（卫星通信除外），通常可不予考虑当采用高速光纤主干网时，第三项的时延也不大第一、第二和第六项时延取决于话音编码的方法在保证话音质量的前提下，话音信号的数码率应尽可能低些ITU-T已制定出不少话音质量不错的低速率话音编码标准IP电话的端到端时延46适合IP电话的

低速率话音编码标准(1)G.729——速率为8kb/s的共轭结构代数码激励线性预测声码器CS-ACELP(Conjugate-StructureAlgebraic-Code-ExcitedLinearPrediction)

(2)G.723.1——速率为5.3/6.3kb/s的为多媒体通信用的低速率声码器47要减少上述第四和第五项时延较为困难当网络发生拥塞而产生话音分组丢失时，还必须采用一定的策略（称为“丢失掩蔽算法”）对丢失的话音分组进行处理如，可使用前一个话音分组来填补丢失的话音分组的间隙IP电话的端到端时延48接收端缓存空间和播放时延的大小对话音分组丢失率和端到端时延也有很大的影响IP电话的端到端时延49D

分组丢失率端到端时延20%10%5%100ms150ms400msABCN良好基本可用不好长途电话质量接收端播放时延增大越接近坐标原点，话音质量就越好播放时延的最佳值50播放时延的最佳值假定某IP电话的通话质量处于图中的B点位置若增大接收端缓存空间，并增大播放时延

则话音分组丢失率将减少，但端到端的时延将增加（如图中的C点）继续增大播放时延则话音分组丢失率将继续减少，趋向于网络所引起的丢失率（如图中的D点）但D点的端到端时延很大，话音质量很不好51播放时延的最佳值反之，若将接收端缓存空间做得很小，并减小播放时延

则端到端时延将减小，趋向于网络所引起的端到端时延（如图中的A点）但话音分组丢失率将大大增加，话音质量也不好可见，接收端的播放时延有一个最佳值图中的N点，相当于端到端时延和话音分组丢失率都是最小但实际上并不可能工作在这个点上52时延估计据统计，当通话双方相距3200km时，因特网上的时延约为30~100ms（传播和排队）而所有各环节的时延总和约为100~262ms（在两个IP电话网关之间）或170~562ms（在两个PC机之间）[KAST98]可见，为减少时延，应尽可能不要直接用PC机打IP电话53线速路由器提高路由器的转发分组的速率对提高IP电话的质量也是很重要的据统计，一个跨大西洋的IP电话一般要经过2030个路由器若能改用吉比特路由器（又称为线速路由器），则每秒可转发5百万至6千万个分组（即交换速率达60Gb/s左右）。这样还可进一步减少由网络造成的时延54IP电话质量得到很大提高现在很多IP电话的话音质量已经优于固定电话的话音质量一些电信运营商还建造了自己专用的IP电话线路，以便保证更好的通话质量在IP电话领域，最值得一提的就是SkypeIP电话，它给全世界的广大用户带来了高品质并且廉价的通话服务55关于SkypeSkype使用GlobalIPSound公司开发的互联网低比特率编解码器iLBC(internetLowBitrateCodec)，进行话音的编解码和压缩，使其话音质量优于传统的公用电话网（采用电路交换）的话音质量Skype支持两种帧长：20ms，速率为15.2kb/s，一个话音分组块为304bit30ms，速率为13.33kb/s，一个话音分组块为400bit

Skype的另一特点是对话音分组的丢失进行了特殊处理，因而能容忍高达30%的话音分组丢失率，通话的用户一般感受不到话音的断续或延迟，杂音也很小56关于SkypeSkype采用P2P和全球索引（GlobalIndex）技术提供快速路由选择机制，管理成本大大降低。由于用户路由信息分布式存储于因特网的结点中，因此呼叫连接完成得很快Skype采用端对端加密方式，保证信息的安全性Skype使用P2P的技术，用户数据主要存储在P2P网络中，因此必须保证存储在公共网络中的数据是可靠和没有被篡改的。Skype对公共目录中存储的和用户相关的数据都采用数字签名，保证了数据无法被篡改Skype的问世给全球信息技术和通信产业带来深远的影响，也给每一位网络使用者带来生活方式的改变12.3.2IP电话所需要的

几种应用协议57在IP电话的通信中，至少需要两种应用协议：一种是信令协议，它使我们能够在因特网上找到被叫用户另一种是话音分组的传送协议，它使我们用来进行电话通信的话音数据能够以时延敏感属性在因特网中传送TCPUDP信令提高服务质量IPv4/IPv6RTSPRTCPRSVPH.323SIPRTP应用层协议传送音频/视频SDP底层网络5812.3.2IP电话所需要的

几种应用协议5912.3.3实时传输协议RTP

(Real-timeTransportProtocol)

RTP为实时应用提供端到端的传输，但不提供任何服务质量(QoS)的保证多媒体数据块经压缩编码处理后，先送给RTP封装成为RTP分组，再装入传输层的UDP用户数据报，然后再交给IP层RTP是一个协议框架，只包含了实时应用的一些共同的功能RTP自己并不对多媒体数据块做任何处理，而只是向应用层提供一些附加的信息，让应用层知道应当如何进行处理60RTP的层次从应用开发者的角度看，RTP应当是应用层的一部分在应用的发送端，开发者必须编写用RTP封装分组的程序代码，然后把RTP分组交给UDP插口接口在接收端，RTP分组通过UDP插口接口进入应用层后，还要利用开发者编写的程序代码从RTP分组中把应用数据块提取出来61RTP也可看成是

传输层的一个子层RTP封装了多媒体应用的数据块。由于RTP向多媒体应用程序提供了服务（如时间戳和序号），因此也可以将RTP看成是在UDP之上的一个传输层的子层传输层应用层IP数据链路层物理层RTPUDPRTP分组的首部格式12字节序号位01381631有效载荷类型版本PXM参与源数时间戳同步源标识符(SSRC)参与源标识符(CSRC)[0..15]…发送RTP分组UDP用户数据报IP数据报IP首部UDP首部RTP首部RTP数据部分（应用层数据）6263RTP首部版本：占2位。当前使用的是版本2填充P：占1位。特殊情况下用于填充扩展X：X置1表示在此RTP首部后面还有扩展首部，这里不做讨论参与源数：占4位。这个字段给出后面的参与源标识符的数目参与源标识符：这是选项，最多可有15个。也是一个32位数，用来标志来源于不同地点的RTP流64RTP首部标记M：占1位。M置1表示这个RTP分组具有特殊意义如，在传送视频流时，用来表示每一帧的开始有效载荷类型：占7位。指出后面的RTP数据属于何种格式的应用如，对于音频有效载荷：GSM(3)、LPC(7)、G.722(9)、G.28(15)等对于视频有效载荷：活动JPEG(26)、H.261(31)、MPEG1(32)、MPEG2(33)等65RTP首部序号：占16位。对每一个发送出的RTP分组，其序号加1

在一次RTP会话开始时的初始序号是随机选择的

时间戳：占32位。反应了RTP分组中的数据的第一个字节的采样时刻在一次会话开始时时间戳的初始值也是随机选择的即使是在没有信号发送时，时间戳的数值也要随时间而不断地增加66RTP首部同步源标识符SSRC：占32位。是一个数，用于标识RTP流的来源SSRC与IP地址无关，在新的RTP流开始时随机产生两个流被分配相同SSRC的概率是很小的，如果发生了，这两个源应选择一个新的SSRC值6712.3.4实时传输控制协议RTCP(RTPControlProtocol)

RTCP是与RTP配合使用的协议RTCP协议主要功能是：服务质量的监视与反馈、媒体间的同步，以及多播组中成员的标识RTCP分组也使用UDP传送，但RTCP并不对声音或视频分组进行封装可将多个RTCP分组封装在一个UDP数据报中RTCP分组周期性地在网上传送，它带有发送端和接收端对服务质量的统计信息报告(如已发送的分组数和字节数、分组丢失率、分组到达时间间隔的抖动等)

68RTCP使用的五种分组类型1、结束分组BYE，表示关闭一个数据流2、特定应用分组APP，使应用程序能够定义新的分组类型69RTCP使用的五种分组类型3、接收端报告分组RR，用来使接收端周期性地向所有的点用多播方式进行报告接收端每收到一个RTP流（一次会话包含多个RTP流）就产生一个接收端报告分组RRRR分组的内容有：所收到的RTP流的SSRC；该RTP流的分组丢失率（若分组丢失率太高，发送端就应该适当地降低发送分组的速率）；在该RTP流中的最后一个RTP分组的序号；分组到达时间间隔的抖动等70RTCP使用的五种分组类型3、接收端报告分组RR，用来使接收端周期性地向所有的点用多播方式进行报告发送RR分组有两个目的：第一，可以使所有的接收端和发送端了解当前网络的状态第二，可以使所有发送RTCP分组的站点自适应地调整自己发送RTCP分组的速率，使得起控制作用的RTCP分组不要过多地影响传送应用数据的RTP分组在网络中的传输。通常是使RTCP分组的通信量不超过网络中数据分组的数据量的5%，而接收端的通信量又应小于所有RTCP分组的通信量的75%

71RTCP使用的五种分组类型4、发送端报告分组SR，用来使发送端周期性地向所有接收端用多播方式进行报告发送端每发送一个RTP流就要发送一个发送端报告分组SRSR分组的内容有：该RTP流的SSRC；该RTP流中最新产生的RTP分组的时间戳和绝对时钟时间（或墙上时钟时间wallclocktime）；该RTP流包含的分组数；该RTP流包含的字节数。绝对时钟时间是必要的。因为RTP要求每一种媒体使用一个流。例如，要传送视频图像和相应的声音就需要传送两个流。有了绝对时钟时间就可以进行图像和声音的同步。72RTCP使用的五种分组类型5、源点描述分组SDES，给出会话中参加者的描述它包括参加者的规范名CNAME(CanonicalNAME)

规范名是参加者的电子邮件地址的字符串7312.3.5H.323现在的IP电话有两套信令标准：一套是ITU-U定义的H.323协议一套是IETF提出的会话发起协议SIPH.323是国际电信联盟远程通信标准化组织(ITU-T)于1996年制订的一个名称很长的建议书，1998年的第二个版本改用的名称是“基于分组的多媒体通信系统”请注意：H.323不是一个单独的协议，而是一组协议H.323包括系统和构件的描述、呼叫模型的描述、呼叫信令过程、控制报文、复用、话音编解码器、视像编解码器以及数据协议等，但不保证服务质量(QoS)

74H.323终端使用H.323协议

进行多媒体通信分组交换网（例如，因特网）H.323H.323终端H.323终端

75H.323标准指明的四种构件(1)H.323终端——可以是PC机，也可以是运行H.323程序的单个设备(2)网关——网关连接到两种不同的网络，使H.323网络可以和非H.323网络进行通信(3)网闸(gatekeeper)——相当于整个H.323网络的大脑，所有的呼叫都要通过网闸，因为网闸提供地址转换、授权、带宽管理和计费功能(4)多点控制单元MCU(MultipointControlUnit)——支持三个或更多的H.323终端的音频或视频会议76H.323网关用来和

非H.323网络进行连接因特网公用电话网网关网闸H.323终端

多点控制单元MCU77H.323的协议体系结构音频/视频应用音频编解码视频编解码RTCPH.225.0登记信令H.225.0呼叫信令H.245控制信令RTPUDPTCPIP信令和控制数据应用T.120数据H.323的出发点是以已有的电路交换电话网为基础，增加了IP电话的功能（即远距离传输采用IP网络）H.323的信令也沿用原有电话网的信令模式，因此与原有电话网的连接比较容易7812.3.6会话发起协议SIP

(SessionInitiationProtocol)虽然H.323系列现在已被大部分生产IP电话的厂商采用，但由于H.323过于复杂，不便于发展基于IP的新业务，因此IETF的MMUSIC工作组制定了另一套标准，即会话发起协议SIPSIP是一套较为简单且实用的标准，目前已成为因特网的建议标准（RFC3261~3266）7912.3.6会话发起协议SIP

(SessionInitiationProtocol)SIP协议以因特网为基础，把IP电话视为因特网上的新应用SIP协议只涉及到IP电话的信令和有关服务质量问题，而没有提供像H.323那样多的功能SIP没有指定使用RTP协议，但实际上大家还是选用RTP和RTCP作为配合使用的协议80SIP系统的构件SIP使用文本方式的客户服务器协议SIP系统只有两种构件：用户代理

网络服务器

用户代理包括用户代理客户和用户代理服务器

前者用来发起呼叫而后者用来接受呼叫81SIP系统的构件网络服务器分为代理服务器和重定向服务器

代理服务器接受来自主叫用户的呼叫请求，并将其转发给下一跳代理服务器，最后将呼叫请求转发给被叫用户重定向服务器不接受呼叫，它通过响应告诉客户下一跳代理服务器的地址，由客户按此地址向下一跳代理服务器重新发送呼叫请求82SIP地址十分灵活可以是电话号码，也可以是电子邮件地址、IP地址或其他类型的地址但一定要使用SIP的地址格式，例如：电话号码sip:zhangsan@8625-87654321IPv4地址sip:zhangsan@6电子邮件地址sip:zhangsan@83SIP协议和HTTP类似，SIP是基于报文的协议SIP使用了HTTP的许多首部、编码规则、差错码以及一些鉴别机制，它比H.323具有更好的可扩缩性SIP的会话共有三个阶段：建立会话通信终止会话

84一个简单的SIP会话

主叫方被叫方OK:地址ACKINVITE:地址，选项建立会话BYE终止会话电话交谈通信tt85SIP会话的建立和终止上图中，SIP的会话建立和会话终止阶段