第12讲-多媒体传输协议

,单击此处编辑母版标题样式,*,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,1,第,12,讲 多媒体传输协议,要求,1.,理解网络多媒体传输的基本问题和基本解决方法,2.,理解流式音频视频的基本原理,3.,理解交互式音频视频的基本原理,4.,了解多媒体传输协议,RTSP,、,RTP,和,RTCP,2,12.1,概述,计算机网络最初是为传送数据信息设计的,因特网,IP,层提供的“,尽最大努力交付,”服务，以及,每一个分组独立交付,的策略，对传送数据信息也是很合适的,因特网使用的,TCP,协议可以很好地解决网络不能提供,可靠交付,这一问题,3,多媒体信息的特点,多媒体信息（包括声音和图像信息）与不包括声音和图像的数据信息有很大的区别,多媒体信息的信息量往往很大,在传输多媒体数据时，对,时延,和,时延抖动,均有较高的要求,多媒体数据往往是,实时数据,(real time data),，它的含义是：在发送实时数据的同时，在接收端边接收边播放,4,因特网是非等时的,模拟的多媒体信号经过采样和模数转换变为数字信号，再组装成分组,这些分组的发送速率是,恒定的,（,等时的,）,传统的因特网本身是,非等时的,因此经过因特网的分组变成了,非恒定速率,的分组,t,t,因特网,t,模拟信号,t,采样后的信号,构成分组,恒定速率,非恒定速率,5,接收端需设置适当大小的,缓存,当缓存中的分组数达到一定的数量后再以恒定速率按顺序把分组读出进行还原播放,缓存实际上就是一个先进先出的队列。图中标明的,T,叫做,播放时延,在接收端设置缓存,t,T,缓存（队列）,恒定速率,t,非恒定速率,有可能发生,分组丢失,6,缓存使所有到达的分组都经受了迟延,早到达的分组在缓存中停留的时间较长，而晚到达的分组在缓存中停留的时间则较短,以非恒定速率到达的分组，经过缓存后再以恒定速率读出，就能够在一定程度上消除了时延的抖动,但，付出的代价是：,增加了时延,缓存的影响,分组,发出,1,2,3,4,5,6,t,到达分组数,6,5,4,3,2,1,1,2,3,4,5,6,t,缓存时间,缓存时间,再推迟播放时间,如果网络无时延,推迟播放,分组迟到,网络出现时延,分组,1,的时延,分组,到达,1,2,3 4,5,6,t,实际的网络,7,8,需要解决的问题,在传送,时延敏感,(delay sensitive),的实时数据时，不仅传输时延不能太大，而且,时延抖动,也必须受到限制,对于传送实时数据，很少量分组的丢失对播放效果的影响并不大（因为这是由人来进行主观评价的），因而是可以容忍的。,丢失容忍,(loss tolerant),也是实时数据的另一个重要特点,9,需要解决的问题,由于分组的到达可能不按序，但将分组还原和播放时又应当是按序的,因此在发送多媒体分组时还应当给每一个分组加上,序号,。这表明还应当有相应的协议支持才行,要使接收端能够将节目中本来就存在的正常的短时间停顿（如音乐中停顿几拍）和因某些分组的较大迟延造成的“停顿”区分开来,这就需要增加一个,时间戳,(timestamp),，以便告诉接收端应当在什么时间播放哪个分组,10,是否改造现有的因特网？,1,、大量使用光缆和高速路由器，网络的时延和时延抖动就可以足够小，在因特网上传送实时数据就不会有问题,2,、把因特网改造为能够对端到端的带宽实现,预留,(reservation),，把使用无连接协议的因特网转变为面向连接的网络,3,、部分改动因特网的协议栈所付出的代价较小，而这也能够使多媒体信息在因特网上的传输质量得到改进,11,目前因特网提供的音频,/,视频服务大体上可分为三种类型,流式,(streaming),存储音频,/,视频,边下载边播放,流式实况音频,/,视频,边录制边发送,交互式音频,/,视频,实时交互式通信,12,目前因特网提供的音频,/,视频服务大体上可分为三种类型,流式,(streaming),存储音频,/,视频,边下载边播放,在这类应用中，客户机根据需求请求存储在服务器上的被压缩的音频或视频文件,目前数以千计的场点提供流式存数音频和视频，包括,CNN,和,Youtube,等,流式实况音频,/,视频,边录制边发送,交互式音频,/,视频,实时交互式通信,13,目前因特网提供的音频,/,视频服务大体上可分为三种类型,流式,(streaming),存储音频,/,视频,边下载边播放,流式实况音频,/,视频,边录制边发送,这类应用类似于传统的电台广播和电视，只是它通过因特网来传输而已,这些应用允许用户接收从世界任何角落发出的实况无线电广播和电视传输,交互式音频,/,视频,实时交互式通信,14,目前因特网提供的音频,/,视频服务大体上可分为三种类型,流式,(streaming),存储音频,/,视频,边下载边播放,流式实况音频,/,视频,边录制边发送,交互式音频,/,视频,实时交互式通信,这类应用允许人们使用音频,/,视频互相实时通信,因特网上的实时交互音频通常称为因特网电话,(Internet telephony),，因为从用户角度来看，它类似于传统的电路交换电话服务,15,“,边下载边播放”中的“下载”,“,边下载边播放”结束后，在用户的硬盘上没有留下有关播放内容的任何痕迹,流媒体,(streaming media),，即流式音频,/,视频,流媒体特点就是“边下载边播放”,(streaming and playing),16,12.2,流式存储音频,/,视频,传统的下载文件方法,万维网,服务器,客户机,服务器,媒体,播放器,GET:,音频,/,视频文件,RESPONSE,音频,/,视频文件,浏览器,17,传统的浏览器从服务器下载音频,/,视频文件,用户从客户机,(client),的浏览器上用,HTTP,协议向服务器请求下载某个音频,/,视频文件,服务器如有此文件就发送给浏览器。在响应报文中就装有用户所要的音频,/,视频文件。整个下载过程可能会,花费很长的时间,当浏览器,完全收下,这个文件后，就可以传送给自己机器上的媒体播放器进行解压缩，然后播放,18,12.2.1,具有元文件的万维网服务器,元文件,就是一种非常小的文件，它描述或指明其他文件的一些重要信息,万维网,服务器,客户机,服务器,媒体,播放器,元文件,浏览器,GET:,元文件,RESPONSE,GET:,音频,/,视频文件,RESPONSE,19,使用元文件下载音频,/,视频文件,浏览器用户使用,HTTP,的,GET,报文接入到万维网服务器，这个超链接指向一个元文件，这个元文件有实际的音频,/,视频文件的统一资源定位符,URL,万维网服务器把该元文件装入,HTTP,响应报文的主体，发回给浏览器,客户机浏览器调用相关的媒体播放器，把提取出的元文件传送给媒体播放器,媒体播放器使用元文件中的,URL,，向万维网服务器发送,HTTP,请求报文，要求下载音频,/,视频文件,万维网服务器发送,HTTP,响应报文，把该音频,/,视频文件发送给媒体播放器。媒体播放器边下载边解压缩边播放,20,12.2.2,媒体服务器,媒体服务器,也称为,流式服务器,(streaming server),，它支持流式音频和视频的传送,媒体播放器与媒体服务器的关系是客户与服务器的关系,媒体播放器不是向万维网服务器而是向媒体服务器请求音频,/,视频文件,媒体服务器和媒体播放器之间采用另外的协议进行交互,21,使用媒体服务器,万维网,服务器,媒体,播放器,元文件,浏览器,GET:,元文件,RESPONSE,GET:,音频,/,视频文件,RESPONSE,媒体,服务器,客户机,服务器,22,采用媒体服务器下载音频,/,视频文件的步骤,前三个步骤仍然和上一节的一样，区别就是后面两个步骤,媒体播放器使用元文件中的,URL,接入到,媒体服务器,，请求下载浏览器所请求的音频,/,视频文件。下载可以借助于使用,UDP,的任何协议，例如使用实时传输协议,RTP,媒体服务器给出响应，把该音频,/,视频文件发送给媒体播放器。媒体播放器在迟延了若干秒后，以流的形式边下载边解压缩边播放,23,12.2.3,实时流式协议,RTSP,(Real-Time Streaming Protocol),RTSP,协议以客户,/,服务器方式工作，它是一个多媒体播放控制协议，用来使用户在播放从因特网下载的实时数据时能够进行控制，如：暂停,/,继续、后退、前进等,因此,RTSP,又称为“,因特网录像机遥控协议,”,要实现,RTSP,的控制功能，不仅要有协议，而且要有专门的,媒体播放器,(media player),和,媒体服务器,(media server),24,RTSP,简介,RTSP,协议是由,RealNetworks(,音频,/,视频流领域的业界领袖之一,),和,Netcape,共同提出的,RTSP,协议是一个流媒体协议，用于视频点播、视频会议、视频监控等领域,知名端口：,554,RTSP,语法是基于文本的，类似,HTTP,协议,RTSP,中的所有操作都是通过服务器和客户端的消息应答来完成的，其消息包括请求,(Request),和响应,(Response),两种,25,RTSP,不能做什么,RTSP,没有定义用于音频和视频的压缩方案,RTSP,没有定义音频和视频在网络传输中是怎样封装在分组中的,流式媒体的封装可以通过,RTP,或专用协议来提供,RTSP,不限制流式媒体如何传输，它可以在,UDP,或,TCP,上传输,RTSP,不限制媒体播放器如何缓冲音频,/,视频,音频,/,视频可能在它一到达客户机就开始播放，也可能在延迟几秒后播放，或者完全下载下来再播放,26,RTSP,特点,RTSP,允许媒体播放器控制媒体流传输,暂停,/,继续、播放重定位、快进和快退等,RTSP,信道在很多方面和,FTP,的控制信道类似,RTSP,本身并不传送数据，而仅仅是使媒体播放器能够控制多媒体流的传送,RTSP,是一个带外协议,(out-of-band protocol),RTSP,报文在带外发送，而媒体流的分组结构没有被,RTSP,定义，它被认为是“带内”的,RTSP,报文和媒体流使用不同的端口号,27,RTSP,消息格式,RTSP,的消息有两大类：,请求消息,回应消息,请求消息：,方法,URI RTSP,版本,CR LF,消息头,CR LF CR LF,消息体,CR LF,28,RTSP,消息格式,说明,方法,即可用的,命令,，如：,OPTIONS,：客户端用于得到服务器提供的可用方法,DESCRIBE,：客户端用于得到会话描述信息,(SDP),SETUP,：客户端提醒服务器建立会话，并确定传输模式,PLAY,：客户端发送播放请求,TEARDOWN,：客户端发起关闭请求,URI,是接受方的地址,，,如,：,rtsp:/192.168.20.136,RTSP,版本一般都是,RTSP/1.0,每行后面的,CR LF,表示回车换行，需要接受端有相应的解析，最后一个消息头需要有两个,CR LF,29,RTSP,消息格式,回应消息：,RTSP,版本 状态码 解释,CR LF,消息头,CR LF CR LF,消息体,CR LF,说明,RTSP,版本一般都是,RTSP/1.0,状态码是一个数值,200,表示成功,解释是与状态码对应的文本解释,万维网,服务器,客户机,服务器,媒体,播放器,元文件,浏览器,媒体,服务器,音频,/,视频流,GET:,元文件,RESPONSE,SETUP,RESPONSE,PLAY,RESPONSE,RESPONSE,TEARDOWN,30,31,使用,RTSP,的媒体服务器的工作过程,浏览器向万维网服务器请求音频,/,视频文件,万维网服务器从浏览器发送携带有元文件的响应,浏览器把收到的元文件传送给媒体播放器,RTSP,客户与媒体服务器的,RTSP,服务器建立连接,RTSP,服务器发送响应,RESPONSE,报文,RTSP,客户发送,PLAY,报文，开始下载音频,/,视频文件,RTSP,服务器发送响应,RESPONSE,报文,RTSP,客户发送,TEARDOWN,报文断开连接,RTSP,服务器发送响应,RESPONSE,报文,32,RTSP,交互示例,C, S,SETUP,rtsp:/115.182.51.79/zuoyou001.mp4/trackID=65537 RTSP/1.0,CSeq: 5,User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25),Transport: RTP/AVP/TCP;unicast;interleaved=2-3,Session: 1837199341906602386,33,RTSP,交互示例,S, C,RTSP/1.0 200 OK,Server: DSS/6.0.3 (,Build/526.3; Platform/FreeBSD; Release/Darwin Streaming Server; State/Development;,),Cseq: 5,Session: 1837199341906602386,Last-Modified: Thu, 17 Jan 2002 11:20:30 GMT,Cache-Control: must-revalidate,Date: Wed, 04 Jan 2012 06:14:53 GMT,Expires: Wed, 04 Jan 2012 06:14:53 GMT,Transport: RTP/AVP/TCP;unicast;interleaved=2-3;ssrc=5B56A405,34,RTSP,交互示例,C, S,PLAY,rtsp:/115.182.51.79/zuoyou001.mp4/ RTSP/1.0,CSeq: 6,User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25),Session: 1837199341906602386,Range: npt=0.000-,35,RTSP,交互示例,S, C,RTSP/1.0 200 OK,Server: DSS/6.0.3 (,Build/526.3; Platform/FreeBSD; Release/Darwin Streaming Server; State/Development;,),Cseq: 6,Session: 1837199341906602386,Range: npt=0.00000-6640.12667,RTP-Info: url=rtsp:/115.182.51.79/zuoyou001.mp4/trackID=65536;seq=55088;rtptime=37707334,url=rtsp:/115.182.51.79/zuoyou001.mp4/trackID=65537;seq=19114;rtptime=550154668,36,RTSP,交互示例,C, S,TEARDOWN,rtsp:/115.182.51.79/zuoyou001.mp4/ RTSP/1.0,CSeq: 7,User-Agent: LibVLC/1.1.11 (LIVE555 Streaming Media v2011.05.25),Session: 1837199341906602386,37,RTSP,交互示例,S, C,RTSP/1.0 200 OK,Server: DSS/6.0.3 (,Build/526.3; Platform/FreeBSD; Release/Darwin Streaming Server; State/Development;,),Cseq: 7,Session: 1837199341906602386,Connection: Close,38,RTSP,与,HTTP,的异同,注意,RTSP,和,HTTP,之间的相似性,RTSP,在语法和操作上与,HTTP/1.1,类似，因此,HTTP,的扩展机制在多数情况下可加入,RTSP,所有的请求和响应报文都是采用,ASCII,文本格式，客户机使用标准化的方法（,SETUP,、,PLAY,、,PAUSE,等），服务器用标准化的应答码来响应,39,RTSP,与,HTTP,的异同,一些区别：,RTSP,中客户端和服务器都可以发出请求,在多数情况下，数据由不同的协议传输,RTSP,服务器一直跟踪每个正在进行的,RTSP,会话中的客户机状态,如服务器记录客户机是位于初始化状态、播放状态还是暂停状态,作为每个,RTSP,请求和响应的一部分，会话号和序号帮助服务器跟踪会话状态,会话号在整个会话中不变，客户机每次发送一个新的报文就增加序号,服务器使用会话号和现在的序号来回显,40,12.3,交互式音频,/,视频,12.3.1 IP,电话概述,狭义的,IP,电话,就是指在,IP,网络上打电话。所谓“,IP,网络”就是“使用,IP,协议的分组交换网”的简称,广义的,IP,电话,则不仅仅是电话通信，而且还可以是在,IP,网络上进行交互式多媒体实时通信（包括话音、图像等），甚至还包括,即时通信,IM (Instant Messaging),IP,电话网关的几种连接方法,分组交换,电路交换,电路交换,因特网,PC,到,PC,公用电话网,IP,电话,网关,因特网,PC,到固定电话机,公用电话网,IP,电话,网关,公用电话网,IP,电话,网关,因特网,固定电话机到固定电话机,41,IP,电话网关是公用电话网与,IP,网络的接口设备,1,、在电话呼叫阶段和呼叫释放阶段，进行电话信令的转换,2,、在通话期间，进行话音编码的转换,42,IP,电话的通话质量,在电路交换电话网中，任何两端之间的通话质量都是有保证的，但,IP,电话则不然,IP,电话的通话质量主要由两个因素决定：,一个是通话双方端到端的,时延,和,时延抖动,另一个是话音分组的,丢失率,但这两个因素是不确定的，是取决于当时网络上的通信量,网络通信量非常大，以致发生拥塞，就会影响,IP,电话的通话质量,一个用户使用,IP,电话的通话质量取决于当时其他的许多用户的行为,43,IP,电话的通话质量,当电路交换电话网的通信量太大时，往往使我们无法拨通电话,但只要拨通电话，那电信公司就能保证让用户满意的通话质量,经验证明，在电话交谈中，端到端的时延不应超过,250ms,，否则交谈者就能感到不自然,陆地公用电话网的时延一般只有,5070ms,经过同步卫星的电话端到端时延就超过,250ms,，因此一般人都不太适应经过卫星传送的过长时延,44,IP,电话的端到端时延,(1),话音信号进行模数转换要经受时延,(2),话音比特流装配成话音分组的时延,(3),话音分组的发送时间，此时间等于话音分组长度与通信线路的数据率之比,(4),话音分组在因特网中的存储转发时延,(5),话音分组在接收端缓存中暂存所引起的时延,(6),话音分组还原成模拟话音信号的时延,(7),话音信号在通信线路上的传播时延,(8),终端设备的硬件和操作系统产生的接入时延,45,话音信号在通信线路上的传播时延一般都很小（卫星通信除外），通常可不予考虑,当采用高速光纤主干网时，第三项的时延也不大,第一、第二和第六项时延取决于话音编码的方法,在保证话音质量的前提下，话音信号的数码率应尽可能低些,ITU-T,已制定出不少话音质量不错的低速率话音编码标准,IP,电话的端到端时延,46,适合,IP,电话的,低速率话音编码标准,(1) G.729,速率为,8 kb/s,的共轭结构代数码激励线性预测声码器,CS-ACELP (Conjugate-Structure Algebraic-Code-Excited Linear Prediction),(2) G.723.1,速率为,5.3/6.3 kb/s,的为多媒体通信用的低速率声码器,47,要减少上述第四和第五项时延较为困难,当网络发生拥塞而产生话音分组丢失时，还必须采用一定的策略（称为“,丢失掩蔽算法,”）对丢失的话音分组进行处理,如，可使用前一个话音分组来填补丢失的话音分组的间隙,IP,电话的端到端时延,48,接收端缓存空间和播放时延的大小对话音分组丢失率和端到端时延也有很大的影响,IP,电话的端到端时延,49,D,分组,丢失率,端到端时延,20 %,10 %,5 %,100 ms,150 ms,400 ms,A,B,C,N,良好,基本,可用,不好,长途电话,质量,接收端播放,时延增大,越接近坐标原点，话音质量就越好,播放时延的最佳值,50,播放时延的最佳值,假定某,IP,电话的通话质量处于图中的,B,点位置,若增大接收端缓存空间，并增大播放时延,则话音分组丢失率将减少，但端到端的时延将增加（如图中的,C,点）,继续增大播放时延,则话音分组丢失率将继续减少，趋向于网络所引起的丢失率（如图中的,D,点）,但,D,点的端到端时延很大，话音质量很不好,51,播放时延的最佳值,反之，若将接收端缓存空间做得很小，并减小播放时延,则端到端时延将减小，趋向于网络所引起的端到端时延（如图中的,A,点）,但话音分组丢失率将大大增加，话音质量也不好,可见，接收端的播放时延有一个最佳值,图中的,N,点，相当于端到端时延和话音分组丢失率都是最小,但实际上并不可能工作在这个点上,52,时延估计,据统计，当通话双方相距,3200km,时，因特网上的时延约为,30100ms,（传播和排队）,而所有各环节的时延总和约为,100262ms,（在两个,IP,电话网关之间）或,170562ms,（在两个,PC,机之间）,KAST98,可见，为减少时延，应尽可能不要直接用,PC,机打,IP,电话,53,线速路由器,提高路由器的转发分组的速率对提高,IP,电话的质量也是很重要的,据统计，一个跨大西洋的,IP,电话一般要经过,20,30,个路由器,若能改用吉比特路由器（又称为,线速路由器,），则每秒可转发,5,百万至,6,千万个分组（即交换速率达,60Gb/s,左右）。这样还可进一步减少由网络造成的时延,54,IP,电话质量得到很大提高,现在很多,IP,电话的话音质量已经优于固定电话的话音质量,一些电信运营商还建造了自己专用的,IP,电话线路，以便保证更好的通话质量,在,IP,电话领域，最值得一提的就是,Skype,IP,电话，它给全世界的广大用户带来了,高品质,并且,廉价,的通话服务,55,关于,Skype,Skype,使用,Global IP Sound,公司开发的互联网低比特率编解码器,iLBC(internet Low Bit rate Codec),，进行话音的编解码和压缩，使其话音质量优于传统的公用电话网（采用电路交换）的话音质量,Skype,支持两种帧长：,20ms,，速率为,15.2kb/s,，一个话音分组块为,304bit,30ms,，速率为,13.33kb/s,，一个话音分组块为,400bit,Skype,的另一特点是对话音分组的丢失进行了特殊处理，因而能容忍高达,30%,的话音分组丢失率，通话的用户一般感受不到话音的断续或延迟，杂音也很小,56,关于,Skype,Skype,采用,P2P,和,全球索引（,Global Index,）,技术提供快速路由选择机制，管理成本大大降低。由于用户路由信息分布式存储于因特网的结点中，因此呼叫连接完成得很快,Skype,采用,端对端加密,方式，保证信息的安全性,Skype,使用,P2P,的技术，用户数据主要存储在,P2P,网络中，因此必须保证存储在公共网络中的数据是可靠和没有被篡改的。,Skype,对公共目录中存储的和用户相关的数据都采用,数字签名,，保证了数据无法被篡改,Skype,的问世给全球信息技术和通信产业带来深远的影响，也给每一位网络使用者带来生活方式的改变,12.3.2 IP,电话所需要的,几种应用协议,57,在,IP,电话的通信中，至少需要两种应用协议：,一种是,信令协议,，它使我们能够在因特网上找到被叫用户,另一种是话音分组的,传送协议,，它使我们用来进行电话通信的话音数据能够以时延敏感属性在因特网中传送,TCP,UDP,信令,提高服务质量,IPv4/IPv6,RTSP,RTCP,RSVP,H.323,SIP,RTP,应,用,层,协,议,传送音频,/,视频,SDP,底层网络,58,12.3.2 IP,电话所需要的,几种应用协议,59,12.3.3,实时传输协议,RTP,(Real-time Transport Protocol),RTP,为实时应用提供端到端的传输，但不提供任何服务质量,(QoS),的保证,多媒体数据块经压缩编码处理后，先送给,RTP,封装成为,RTP,分组，再装入传输层的,UDP,用户数据报，然后再交给,IP,层,RTP,是一个协议框架，只包含了实时应用的一些共同的功能,RTP,自己并不对多媒体数据块做任何处理，而只是向应用层提供一些附加的信息，让应用层知道应当如何进行处理,60,RTP,的层次,从应用开发者的角度看，,RTP,应当是应用层的一部分,在应用的发送端，开发者必须编写用,RTP,封装分组的程序代码，然后把,RTP,分组交给,UDP,插口接口,在接收端，,RTP,分组通过,UDP,插口接口进入应用层后，还要利用开发者编写的程序代码从,RTP,分组中把应用数据块提取出来,61,RTP,也可看成是传输层的一个子层,RTP,封装了多媒体应用的数据块。由于,RTP,向多媒体应用程序提供了服务（如时间戳和序号），因此也可以将,RTP,看成是在,UDP,之上的一个传输层的子层,传输层,应用层,IP,数据链路层,物理层,RTP,UDP,RTP,分组的首部格式,12,字节,序 号,位,0 1 3 8 16 31,有效载荷类型,版本,P,X,M,参与源数,时 间 戳,同 步 源 标 识 符,(SSRC),参 与 源 标 识 符,(CSRC) 0.15,发送,RTP,分组,UDP,用户数据报,IP,数据报,IP,首部,UDP,首部,RTP,首部,RTP,数据部分（应用层数据）,62,63,RTP,首部,版本：占,2,位。当前使用的是版本,2,填充,P,：占,1,位。特殊情况下用于填充,扩展,X,：,X,置,1,表示在此,RTP,首部后面还有扩展首部，这里不做讨论,参与源数：占,4,位。这个字段给出后面的参与源标识符的数目,参与源标识符：这是选项，最多可有,15,个。也是一个,32,位数，用来标志来源于不同地点的,RTP,流,64,RTP,首部,标记,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),等,65,RTP,首部,序号：占,16,位。对每一个发送出的,RTP,分组，其序号加,1,在一次,RTP,会话开始时的初始序号是随机选择的,时间戳：占,32,位。反应了,RTP,分组中的数据的第一个字节的采样时刻,在一次会话开始时时间戳的初始值也是随机选择的,即使是在没有信号发送时，时间戳的数值也要随时间而不断地增加,66,RTP,首部,同步源标识符,SSRC,：占,32,位。是一个数，用于标识,RTP,流的来源,SSRC,与,IP,地址无关，在新的,RTP,流开始时随机产生,两个流被分配相同,SSRC,的概率是很小的，如果发生了，这两个源应选择一个新的,SSRC,值,67,12.3.4,实时传输控制协议,RTCP,(RTP Control Protocol),RTCP,是与,RTP,配合使用的协议,RTCP,协议主要功能是：服务质量的监视与反馈、媒体间的同步，以及多播组中成员的标识,RTCP,分组也使用,UDP,传送，但,RTCP,并不对声音或视频分组进行封装,可将多个,RTCP,分组封装在一个,UDP,数据报中,RTCP,分组周期性地在网上传送，它带有发送端和接收端对服务质量的统计信息报告,(,如已发送的分组数和字节数、分组丢失率、分组到达时间间隔的抖动等,),68,RTCP,使用的五种分组类型,1,、结束分组,BYE,，表示关闭一个数据流,2,、特定应用分组,APP,，使应用程序能够定义新的分组类型,69,RTCP,使用的五种分组类型,3,、接收端报告分组,RR,，用来使接收端周期性地向所有的点用多播方式进行报告,接收端每收到一个,RTP,流（一次会话包含多个,RTP,流）就产生一个接收端报告分组,RR,RR,分组的内容有：,所收到的,RTP,流的,SSRC,；该,RTP,流的分组丢失率（若分组丢失率太高，发送端就应该适当地降低发送分组的速率）；在该,RTP,流中的最后一个,RTP,分组的序号；分组到达时间间隔的抖动等,70,RTCP,使用的五种分组类型,3,、接收端报告分组,RR,，用来使接收端周期性地向所有的点用多播方式进行报告,发送,RR,分组有两个目的：,第一，可以使所有的接收端和发送端了解当前网络的状态,第二，可以使所有发送,RTCP,分组的站点自适应地调整自己发送,RTCP,分组的速率，使得起控制作用的,RTCP,分组不要过多地影响传送应用数据的,RTP,分组在网络中的传输。通常是使,RTCP,分组的通信量不超过网络中数据分组的数据量的,5%,，而接收端的通信量又应小于所有,RTCP,分组的通信量的,75%,71,RTCP,使用的五种分组类型,4,、发送端报告分组,SR,，用来使发送端周期性地向所有接收端用多播方式进行报告,发送端每发送一个,RTP,流就要发送一个发送端报告分组,SR,SR,分组的内容有：,该,RTP,流的,SSRC,；该,RTP,流中最新产生的,RTP,分组的时间戳和绝对时钟时间（或墙上时钟时间,wall clock time,）；该,RTP,流包含的分组数；该,RTP,流包含的字节数。,绝对时钟时间是必要的。因为,RTP,要求每一种媒体使用一个流。例如，要传送视频图像和相应的声音就需要传送两个流。有了绝对时钟时间就可以进行图像和声音的同步。,72,RTCP,使用的五种分组类型,5,、源点描述分组,SDES,，给出会话中参加者的描述,它包括参加者的规范名,CNAME(Canonical NAME),规范名是参加者的电子邮件地址的字符串,73,12.3.5 H.323,现在的,IP,电话有两套信令标准：,一套是,ITU-U,定义的,H.323,协议,一套是,IETF,提出的会话发起协议,SIP,H.323,是,国际电信联盟远程通信标准化组织,(ITU-T),于,1996,年制订的一个名称很长的建议书，,1998,年的第二个版本改用的名称是“基于分组的多媒体通信系统”,请注意：,H.323,不是一个单独的协议，而是一组协议,H.323,包括系统和构件的描述、呼叫模型的描述、呼叫信令过程、控制报文、复用、话音编解码器、视像编解码器以及数据协议等，但不保证服务质量,(QoS),74,H.323,终端使用,H.323,协议进行多媒体通信,分组交换网,（例如，因特网）,H.323,H.323,终端,H.323,终端,75,H.323,标准指明的四种构件,(1) H.323,终端,可以是,PC,机，也可以是运行,H.323,程序的单个设备,(2),网关,网关连接到两种不同的网络，使,H.323,网络可以和非,H.323,网络进行通信,(3),网闸,(gatekeeper),相当于整个,H.323,网络的大脑，所有的呼叫都要通过网闸，因为网闸提供地址转换、授权、带宽管理和计费功能,(4),多点控制单元,MCU(Multipoint Control Unit),支持三个或更多的,H.323,终端的音频或视频会议,76,H.323,网关用来和非,H.323,网络进行连接,因特网,公用电话网,网关,网闸,H.323,终端,多点控制单元,MCU,77,H.323,的协议体系结构,音频,/,视频应用,音频,编解码,视频,编解码,RTCP,H.225.0,登记,信令,H.225.0,呼叫,信令,H.245,控制,信令,RTP,UDP,TCP,IP,信令和控制,数据应用,T.120,数据,H.323,的出发点是以已有的电路交换电话网为基础，增加了,IP,电话的功能（即远距离传输采用,IP,网络）,H.323,的信令也沿用原有电话网的信令模式，因此与原有电话网的连接比较容易,78,12.3.6,会话发起协议,SIP (Session Initiation Protocol),虽然,H.323,系列现在已被大部分生产,IP,电话的厂商采用，但由于,H.323,过于复杂，不便于发展基于,IP,的新业务，因此,IETF,的,MMUSIC,工作组制定了另一套标准，即会话发起协议,SIP,SIP,是一套较为简单且实用的标准，目前已成为因特网的建议标准（,RFC 32613266,）,79,12.3.6,会话发起协议,SIP (Session Initiation Protocol),SIP,协议以因特网为基础，把,IP,电话视为因特网上的新应用,SIP,协议只涉及到,IP,电话的信令和有关服务质量问题，而没有提供像,H.323,那样多的功能,SIP,没有指定使用,RTP,协议，但实际上大家还是选用,RTP,和,RTCP,作为配合使用的协议,80,SIP,系统的构件,SIP,使用文本方式的客户服务器协议,SIP,系统只有两种构件：,用户代理,网络服务器,用户代理包括,用户代理客户,和,用户代理服务器,前者用来发起呼叫,而后者用来接受呼叫,81,SIP,系统的构件,网络服务器分为,代理服务器,和,重定向服务器,代理服务器接受来自主叫用户的呼叫请求，并将其转发给下一跳代理服务器，最后将呼叫请求转发给被叫用户,重定向服务器不接受呼叫，它通过响应告诉客户下一跳代理服务器的地址，由客户按此地址向下一跳代理服务器重新发送呼叫请求,82,SIP,地址十分灵活,可以是电话号码，也可以是电子邮件地址、,IP,地址或其他类型的地址,但一定要使用,SIP,的地址格式，例如：,电话号码,sip:zhangsan8625-87654321,IPv4,地址,s,ip:zhangsan201.12.34.56,电子邮件,地址,sip:zhangsan,83,SIP,协议,和,HTTP,类似，,SIP,是基于报文的协议,SIP,使用了,HTTP,的许多首部、编码规则、差错码以及一些鉴别机制，它比,H.323,具有更好的可扩缩性,SIP,的会话共有三个阶段：,建立会话,通信,终止会话,84,一个简单的,SIP,会话,主叫方,被叫方,OK:,地址,ACK,INVITE:,地址，选项,建立,会话,BYE,终止,会话,电话交谈,通信,t,t,85,SIP,会话的建立和终止,上图中，,SIP,的会话建立和会话终止阶段，都是使用,SIP,协议，而中间的通信阶段，则使用如,RTP,这样的传送实时话音分组的协议,86,SIP,会话的建立和终止,建立会话,主叫方向被叫方发出,INVITE,报文，这个报文中含有双方的地址信息及其他信息（如通话时话音编码方式等）,被叫方如接受呼叫，则发回,OK,响应,而主叫方再发送,ACK,报文作为确认,终止会话,通话完毕时，双方中的任何一方都可以发送,BYE,报文以终止这次会话,87,SIP,用户跟踪,SIP,有一种跟踪用户的机制，可以找出被叫方使用的,PC,机的,IP,地址（如，被叫方使用,DHCP,，因而没有固定的,IP,地址）,为实现跟踪，,SIP,使用,登记,的概念,SIP,定义一些服务器作为,SIP,登记器,(registrar),，每一个,SIP,用户都有一个相关联的,SIP,登记器,用户在任何时候发起,SIP,应用时，都应当给,SIP,登记器发送一个,SIP REGISTER,报文，向登记器报告现在使用的,IP,地址,88,SIP,登记器的用途,跟踪被叫方,主叫方,被叫方,INVITE,查找,回答,电话交谈,t,t,SIP,代理,服务器,SIP,登记器,INVITE,OK,OK,ACK,ACK,BYE,t,t,89,SIP,用户跟踪,主叫方把,INVITE,报文发给,SIP,代理服务器，这个,INVITE,报文中只有被叫方的电子邮件地址而没有其,IP,地址,SIP,代理服务器就向,SIP,登记器发送域名系统,DNS,查询（这个查找报文不是,SIP,的报文），然后从回答报文中找到了被叫方的,IP,地址,代理服务器把得到的被叫方的,IP,地址插入到主叫方的,INVITE,报文中，转发给被叫方,被叫方发送,OK,响应，然后主叫方发送,ACK,报文，完成了会话的建立,90,SIP,用户跟踪,如果被叫没有在这个,SIP,登记器进行过登记，那么这个,SIP,登记器就发回重定向报文，指示,SIP,代理服务器向另一个,SIP,登记器重新进行,DNS,查询，直到找到被叫为止,91,会话描述协议,SDP,(Session Description Protocol),SIP,还有一个配套协议是会话描述协议,SDP,SDP,在电话会议的情况下特别重要，因为电话会议参加者是动态地加入和退出,SDP,详细地指明了媒体编码、协议的端口号以及多播地址,SDP,现在也是因特网建议标准（,RFC 2327,）,92,SIP,与,H.323,对比,SIP,使用了,HTTP,的许多首部、编码规则、差错码以及一些鉴别机制，它比,H.323,具有更好的可扩缩性,由于,SIP,问世较晚，因此它现在比,H.323,占有的市场份额要小,H.323,是关于多媒体会议的完整的、垂直集成的协议族：信令、注册、准入控制、传输和编解码；,SIP,只处理会话的发起和管理，是单一组件,H.323,来源于,ITU(,电话,),，而,SIP,来源于,IETF,，并从,Web,、,DNS,和因特网电子邮件中借鉴了很多概念,H.323,作为伞状标准，大而复杂；,SIP,使用,KISS(Keep It Simple, Stupid),原则：保持简单,93,小结,多媒体信息的特点,需解决的主要问题,时延和时延抖动,丢失容忍,流式存储音频,/,视频,具有元文件的万维网服务器,媒体服务器,实时流式协议,RTSP,94,小结,交互式音频,/,视频,IP,电话所需要的几种应用协议,信令协议,话音分组传输协议,实时传输协议,RTP,实时传输控制协议,RTCP,H.323,会话发起协议,SIP,会话描述协议,SDP,95,作业,1,、端到端时延与时延抖动有什么区别？产生时延抖动的原因是什么？为什么说在传送音频,/,视频时对时延和时延抖动都有较高的要求？,2,、实时流式协议,RTSP,的功能是什么？为什么说它是个带外协议？,3,、在,RTP,分组的首部中为什么要使用序号、时间戳和标记？,4,、,IP,电话的两套信令标准各有何特点？,