| 计算机网络8 互联网上的音视频服务 | 您所在的位置：网站首页 › ip电话的特点 › 计算机网络8 互联网上的音视频服务 |
计算机网络8 互联网上的音视频服务
|
概述
技术的进步，使得许多用户开始利用互联网传送音频、视频数据 这种音频、视频常称为多媒体信息 多媒体信息的两个特点如下： 多媒体信息的信息量很大：传输需要的码率高，因此必须采用各种信息压缩技术传输多媒体数据（边传输边播放）时，对时延和时延抖动有较高的要求传统模拟的多媒体信号要经过数字化，才能在互联网上传送 传输多媒体信号的分组，发送间隔都是恒定的，这样的分组是等时的（isochronous），等时分组进入互联网的速率也是恒定的 传统的互联网本身是非等时的，因为每一个分组都是独立传送，到达接收端时，先后次序可能不同，因此变成非等时的
目前互联网提供的音频、视频服务大体上可分为三种类型： 流式（streaming）存储：这种类型是把已压缩的音视频文件，存储在服务器上，用户通过互联网访问，实现下载播放。流失存储的特点是边下载边播放流式实况：流式实况是一对多的通信，特点是音视频节目没有实现录好存放在服务器中，而是边录制边发送，接收时要求能连续播放交互式：用户使用互联网和其他人进行实时交互式通信，例如互联网电话、互联网电视会议流媒体（streaming media）：就是流式音频、视频，主要特点就是边下载边播放 流式存储音视频使用传统浏览器从服务器下载音视频文件的步骤
对传统浏览器下载文件进行改进的第一种方法，是使用元文件 元文件，是一种非常小的文件，它描述或指明其它文件的一些重要信息，例如音视频文件的路径、大小、格式等，使用元文件下载音视频步骤如下
为了更好提供流式音视频服务，现在流行做法是使用两个分开的服务器，一个普通的万维网服务器和一个流媒体服务器，工作原理如下：
采用媒体服务器后，媒体播放器直接向媒体服务器请求下载音视频文件，其中前3个步骤和之前的一样，区别在后面两个步骤 步骤4：媒体播放器使用元文件提供的URL，接入媒体服务器，请求下载文件步骤5：媒体服务器给出响应，把文件发送给媒体播放器，媒体播放器延迟后解码播放传输音视频数据，可以使用TCP，也可以使用UDP，但是使用UDP会有以下缺点： 发送端按照正常播放速度发送流媒体数据帧，但是接收端的播放器很难做到始终按规定的速率播放很多单位的防火墙阻止外部UDP分组的进入，因此使用UDP传输多媒体文件会被拦截如果用户希望能控制媒体播放，如暂停、快进，还需要使用额外的协议，增加了成本和复杂性因此对流式音视频的播放，都采用了TCP来传送，主要步骤如下：
如果用户暂停播放，那么图中的缓存会快被填满，这时服务器就停止传送数据 如果是实况转播，那么首选还是UDP协议，因为对实时性的要求比较高，允许少部分分组丢失 实时流式协议RTSPRTSP（real-time streaming protocol）：是IETF的MMUSIC工作组开发的协议，是互联网建议标准，RTSP是为了给流式过程增加更多功能而设计的，它本身并不传送数据，而仅仅使媒体播放器能够控制多媒体流的传送，因此RTSP又称为带外协议（out-of-band protocol） RTSP协议以客户服务器方式工作，它是一个应用层的多媒体播放控制协议，用来使用户在播放从互联网下载的实时数据时能够进行控制，因此又称为互联网录像机遥控协议 RTSP的语法和操作与HTTP相似，但是RTSP是有状态的协议，RTSP的控制分组既可以在TCP传输，也可以在UDP传输，RTSP没有定义音视频的压缩方案，也没有规定如何封装在分组中，也不规定应该如何缓存 下面是使用RTSP的媒体服务器工作过程
此后，音视频文件被下载，所用的应用层协议可以是RTP也可以是其它专用协议，运行在UDP协议之上。在播放过程中，播放器可以随时暂停（PAUSE）和播放（PLAY），也可以快进快退 用户不想继续观看时，播放器RTSP客户端发送TEARDOWN报文断开连接媒体服务器的RTSP服务器发送响应报文RESPONSE 交互式音视频此处只介绍交互式音频，即IP电话 IP电话概述 狭义和广义的IP电话狭义的IP电话，就是指在IP网络（使用IP协议的分组交换网）上打电话。这个网络一般是指互联网 广义的IP电话，不仅是电话通信，还能在IP网络上进行交互式多媒体实时通信 在70年代ARPANET就开始研究分组话音通信，但是发展的不快，因为以下原因 缺少廉价的高质量、低速率的话音信号编解码软件和芯片计算机网络的传输速率和路由器的处理速率很慢，传输时延很大没有保证实时通信服务质量QoS的网络协议计算机的网络的规模较小，而通信网只有在具有一定规模后才能产生经济效益 IP电话网关IP电话网关（IP telephone gateway），它是公用电话网与IP网络的接口设备。其作用是 在电话呼叫阶段和释放阶段，进行信令转换在通话期间进行话音编码的转换有了这种IP电话网关，可以实现PC–PC，PC–固话，固话–固话之间互相打IP电话（经过IP网络），下图是不同用户之间打IP电话
在电路交换电话网中，任何两端的通话质量是有保证的，IP电话则不然 IP电话的通话质量主要由两个因素决定： 通话双方端到端的时延和时延抖动话音分组的丢失率这两个因素都是不确定的，取决于当时网络上的通信量，若网络出现了拥塞，那么时延和分组丢失率都会很高，因此IP电话的通话质量取决于其它用户的行为 IP电话端到端时延是由以下几个因素造成的： 话音信号进行模数转换时产生时延模数转换后，要积累到一定量才能装配成一个话音分组，也会产生时延每个话音分组发送完毕需要时间话音分组在互联网中经过路由器存储转发时产生时延话音分组到达接收端在缓存中暂存引起时延将话音分组还原成模拟信号产生时延话音信号在通信线路上的传播时延终端设备的硬件和操作系统产生的接入时延目前适合IP电话的编码标准有 G.729：话音速率为8kbit/s的共轭结构代数码激励线性预测CS-ACELP声码器G.723.1：话音速率为5.3/6.3kbit/s的线性预测编码LPC声码器
当网络发送拥塞而产生话音分组丢失时，必须采用一定的策略对丢失的话音分组进行处理 接收端缓存空间和播放时延的大小对话音分组丢失率和端到端时延也有很大影响
在IP电话的通信中，我们至少需要两种应用协议 信令协议：使我们能够在互联网上找到被叫用户话音分组的传送协议：使我们用来进行电话通信的话音数据能够以时延敏感属性在互联网上传送为了在互联网中提供实时交互式的音视频服务，需要新的多媒体结构
实时运输协议RTP（real-time transport protocol）为实时应用提供端到端的运输，但不提供任何服务质量的保证 需要发送的多媒体数据块经过压缩编码，经过RTP封装成RTP分组，然后装入运输层的UDP数据报，再交给IP层 实际上RTP只是一个协议框架，只包含一些实时应用的共同功能，并不对多媒体数据块做任何处理，而只是向应用层提供一些附加信息 RTP还有两点值得注意，RTP分组只包含RTP数据，而控制是由另一个配套使用的RTCP协议提供的，其次RTP端口号选择1025-65535之间的偶数，并且同一会话中RTCP则使用下一个奇数的UDP端口号。一般情况下5004和5005作为RTP和RTCP的默认端口号 下面对RTP分组的首部进行介绍
在RTP分组的首部中，前12个字节是必须的，后面部分是可选的 有效载荷类型：占7位，这个字段指出后面的RTP数据属于何种格式的应用（编码类型）序号：占16位，RTP会话开始时初始序号是随机的，每一个发送出的RTP分组，序号加1。序号使接收端能够发现丢失的分组，同时也能将失序的分组重新排序时间戳：占32位，时间戳反映了RTP分组中数据的第一个字节采样时刻，会话开始时时间戳也是随机的，即使在没有信号发送时，时间戳的数值也要随时间不断地增加，接收端使用时间戳可以准确知道什么时间还原哪一个数据块，从而消除抖动，时间戳还用于音视频同步同步源标识符：占32位，同步源标识符SSRC是一个数，用来标志RTP流的来源，与IP地址无关，在新的RTP流开始时随机产生参与源标识符：这是选项，最多可有15个，参与源标识符CSRC也是一个32位数，用来标志来源于不同地点的RTP流，在多播环境中，可以用中间的一个站把把多个流混合成一个流，在目的站在根据CSRC的不同将不同的RTP流分开参与源数：占4位，这个字段给出后面的参与源标识符的数目版本：占2位，当前使用版本2填充P：占1位，在某些特殊情况下需要对应用数据块进行加密，这往往要求每一个数据块有确定的长度，如果不满足则要进行填充，P=1时表示RTP分组有若干填充字节，数据部分的最后一个字节用来表示所填充的字节数扩展X：占1位，X=1表示此RTP首部后面还有扩展首部标记M：占1位，M=1表示这个RTP分组有特殊意义 实时运输控制协议RTCPRTCP是与RTP配合使用的协议，主要功能是：服务质量的监视与反馈、媒体间的同步、多播组成员的标志 RTCP使用UDP传送，一个UDP数据报中可以有多个RTCP分组，RTCP分组带有发送端和接收端对服务质量的统计信息报告
RTCP使用五种分组类型 BYE：结束分组，关闭一个数据流APP：特定应用分组，使应用程序能够定义新的分组类型RR：接收端报告分组，用来使接收端周期性向所有的点用多播方式进行报告。接收端每收到一个RTP流，就产生一个RR，发送RR分组有两个目的 可以使所有的接收端和发送端了解当前网络状态可以使所有发送RTCP分组的站点自适应调整自己发送RTCP分组的速率 SR：发送端报告分组，用来使发送端周期性地向所有接收端用多播方式进行报告，发送端每发送一个RTP流，就产生一个SRSDES：源点描述分组给出会话中参与者的描述，包含参与者的规范名 H.323协议现在IP电话有两套信令标准，一是H.323协议，二是会话发起协议SIP H.323是互联网的端系统之间进行实时语音和视频会议的标准，H.323不是一个单独的协议而是一组协议，包括系统和构件的描述、呼叫模型的描述、呼叫信令过程、控制报文、复用、话音编解码器、视像编解码器，以及数据协议等
H.323标准指明了四种构件，使用这些构件连网就可以进行点对点或一对多点的多媒体通信 H.323终端：可以是一个PC，也可以是运行H.323程序的单个设备网关：网关连接到两种不同的网络，使得H.323网络可以和非H.323网络进行通信，仅在一个H.323网络上通信的两个终端当然就不需要使用网关网守（gatekeeper）：相当于整个H.323网络的大脑，所有的呼叫都要通过网守，它提供地址转换、授权、带宽管理、计费功能，网守还可以帮助H.323终端找到距离公用电话网上被叫用户的最近网关多点控制单元MCU：MCU支持三个或更多的H.323终端的音视频会议，MCU管理会议资源、确定使用的音频或视频编解码器网关、网守、MCU是逻辑上分开的构件，但他们可以在一个物理设备中，H.323网关可以使得互联网能够和公用电话网进行连接
H.323包括以下一些组成部分
由于H.323过于复杂，不便于发展基于IP的新业务，因此制定了会话发起协议SIP SIP使用文本方式的客户服务器协议，SIP系统只有两种构件 用户代理（user agent） 用户代理客户UAC：用于发起呼叫用户代理服务器UAS：用于接收呼叫网络服务器（network server） 代理服务器：接收来自主叫用户的呼叫请求，并将其转发给被叫用户或者下一跳的代理服务器重定向服务器：不接受呼叫，它通过响应告诉客户下一跳代理服务区的地址SIP的地址十分灵活，可以是电话号码，也可以是电子邮件、IP地址或者其它类型，但是要求是SIP地址格式 电话号码：sip:zhangsan@021-1234678IP地址：sip:[email protected]电子邮件：sip:[email protected]SIP是基于报文的协议，与HTTP类似，SIP会话共有三个阶段：建立会话、通信、终止会话
主叫方先向被叫方发出INVITE报文：这个报文含有双方的地址等信息，如果被叫接收，则OK回应，主叫再发送ACK确认。通话完毕后，任何一方都可以发送BYE报文终止会话 SIP有一种跟踪用户的机制，可以找出被叫方使用的IP地址，为了实现跟踪，使用了登记的概念 SIP定义一些服务器为SIP登记器，每一个SIP用户都有一个相关联的SIP登记器，用户在任何时候发起SIP应用时，都应该给SIP登记器发送一个SIP REGISTER报文，登记使用的IP地址，SIP登记器和SIP代理服务器一般运行在同一台主机
SIP还有一个配套协议是会话描述协议SDP，SDP在电话会议的情况下特别重要，因为电话会议是动态加入和退出，SDP详细说明了媒体编码、协议的端口号以及多播地址 改进“尽最大努力交付”的服务 使互联网提供服务质量改变互联网平等对待所有分组的思想，使得对时延有严格要求的实时音视频分组，能够从网络得到更好的服务器质量QoS 服务器质量QoS：是服务性能的总效果，此效果决定了一个用户对服务的满意程度 下面通过4个例子说明应从哪些方面入手使得互联网具有一定的服务质量
调度和管制是使互联网能够提供服务质量的重要措施 调度机制调度，就是排队的规则，如果不采用调度机制，则所有队列先进先出，队列满时后到达的将被丢弃，先进先出的最大缺点是不能区分时间敏感分组和一般数据分组 在先进先出的基础上增加按优先级排队，就能使得优先级高的分组优先得到服务
分组到达是按序号从小到大，到达路由器后由分类器进行优先级分类，然后进入相应的队列 优先级排队会带来一个缺点，那就是高优先级队列中总有分组时，低优先级队列的分组长期得不到服务 公平排队FQ（fair queuing）可以解决这一问题，公平排队是对每种类别的分组流设置一个队列，然后轮流使每一个队列一次只能发送一个分组。公平排队的缺点是，长分组得到的服务时间长，段分组比较吃亏，而且公平排队并没有区分分组的优先级 为了使得高优先级队列中的分组有更多的机会得到服务，可增加队列权重的概念，这就是加权公平排队WFQ
加权公平排队中，分组到达后首先进行分类，然后送交与其类别对应的队列，三个队列按顺序依次把队首的分组发送到链路，根据优先级不同，每个队列分配到的服务时间也不同 管制机制对于一个数据流，我们可以根据以下三个方面进行管制 平均速率：网络需要控制一个数据流的平均速率，即在一定的时间间隔内通过的分组数
峰值速率：峰值速率限制了数据流在非常短的时间间隔内的流量 突发长度：网络也限制在非常短的时间间隔内连续注入到网络中的分组数 要在网络中对进入网络的分组流按照以上三个指标进行管制，可使用非常著名的漏桶管制器
漏桶是一种抽象机制，在漏桶中可以装入多个权标（token）。分组进入网络前，先进入一个队列中等待权标，只有取走权标，才准许进入网络 漏桶机制与加权公平排队相结合把漏桶机制和加权公平排队结合起来，可以控制队列中的最大时延 现在假定有N个分组流进入一个路由器，复用后从一条链路输出，每一个分组流使用漏桶机制进行管制
IntServ可对单个应用会话提供服务质量的保证，主要特点如下 资源预留：一个路由器需要知道给不断出现的会话已经预留了多少资源呼叫建立：一个需要服务质量保证的会话，必须首先在源点到终点路径上的每一个路由器预留足够的资源，以保证其端到端的服务质量的要求。因此在一个会话开始前，必须有一个呼叫建立过程，它需要在其分组传输路径上的每一个路由器都参加IntServ定义了两类服务： 有保证的服务：可以保证一个分组在通过路由器时的排队时延有一个严格的上限受控负载的服务：可以使应用程序得到比尽最大努力更可靠的服务IntServ共有以下四个组成部分 资源预留协议RSVP：它是IntServ的信令协议接纳控制：用来决定是否同意对某一资源的请求分类器：用来把进入路由器的分组进行分类，并根据分类的结果把不同类别的分组放入特定的队列调度器：根据服务质量要求决定分组发送的先后顺序一个会话必须首先声明它所需的服务质量，以便路由器能够确定是否有足够的资源来满足会话需求，简单的例子如下
IntServ/RSVP所基于的概念是端系统中与分组流有关的状态信息，各路由器中的预留信息只存储有限的时间，因而各终点对这些预留信息必须定期更新。RSVP协议不是运输测协议，而是网络层的控制协议，RSVP不携带应用数据
IntServ体系结构分为前台和后台两个部分 前台部分：包括分类器与分组转发、分组的调度器，每一个进入路由器的分组都要通过这两个功能块 后台部分：四个功能块和两个数据块 路由选择协议：负责维持路由选择数据库，由此可以查找出对应于每一个目的地址和每一个流的下一跳地址RSVP协议：为每一个流预留必要的资源，并不断更新通信量控制数据库接纳控制：当一个新的流产生时，RSVP就调用接纳控制功能块，以便确认是否有足够的资源管理代理：用来修改通信控制数据库和管理接纳控制模块功能，包括设置接纳控制策略综合服务IntServ体系结构的主要问题是： 状态信息的数量与流的数量成正比：因此在大型网络中，会产生很大开销体系结构复杂：若要得到有保证的服务，所有路由器都必须装有RSVP、接纳控制、分类器、调度器所定义的服务质量等级数量太少，不够灵活 区分服务DiffServ 区分服务的基本概念由于综合服务IntServ和资源预留协议RSVP都比较复杂，很难在大规模的网络中实现，因此提出了新的策略，即区分服务，要点如下 DiffServ力图不改变网络的基础结构，但在路由器中增加区分服务的功能 将IP协议中原有8位IPV4服务类型字段和IPV6的通信量类字段重新定义为区分服务DS，路由器根据DS字段的值来处理分组的转发利用DS字段的不同数值，可以提供不同等级的服务质量。目前只使用前6位，即区分服务码点DSCP，后面两位不用，记为CU
在使用DS字段之前，互联网ISP要和用户商定一个服务等级协定SLA，在SLA中指明了被支持的服务类别和每一类别所容许的通信量 网络被划分为许多DS域：一个DS域在一个管理实体的控制下实现同样的区分服务策略，DiffServ将所有的复杂性放在DS域的边界结点中，而使DS域内部路由器工作尽可能简单
DiffServ定义了在转发分组时体现服务水平的每跳行为PHB。行为就是指在转发分组时路由器对分组是怎样处理的。每跳强调只涉及到本路由器转发的这一跳行为 目前已经定义了两种PHB 迅速转发PHB：用来构造通过DS域的一个低丢失率、低延时、低时延抖动、确保带宽的端到端服务确保转发PHB：当发送网络拥塞时，对于每一个等级的AF，路由器就首先把丢弃优先级最高的分组丢弃 |
【本文地址】