搜索
IPTV---网络部分-流媒体传输和控制协议IPTV流媒体传输与控制协议•流媒体传输和控制协议概述–流媒体基础网络协议•TCP、UDP(传输层)•IP协议(互联网层)–流媒体传输协议•RTP、RTCP，RTP为实时传输协议，通过UDP协议传输。RTCP为实时传输控制协议，可以通过TCP协议传输，也可以通过UDP协议传输，但与RTP采用不同的端口号，加以分离•RTSP，RTSP为实时流协议，也可以说是话路控制协议，支持如像VCR那样的操作控制，如暂停、快进、快退等。RTSP也通过UDP来传输•RSVP，RSVP协议为资源预留协议，属传输层范围的协议，对沿路由的路由器提出控制带宽(预留)的要求，以保证某些信号带宽稳定的需求IPTV流媒体传输与控制协议•流媒体的网络传输特征–旧的互联网的特点，数据量小，实时性低，带宽低，可靠性差–新的多媒体业务流需求必须适应多媒体业务流传输IPTV流媒体传输与控制协议•流媒体的网络传输特征–高带宽和高压缩率•即使是传输压缩数据，对带宽的要求还是很大的，MPEG-1的带宽要求是1.5Mbps，MPEG-2则为1.5-40Mbps；为了在更窄的频带上传输实时高清信息，则要求采用更高的视频压缩编码技术，如MPEG一4或ASF等压缩方案，H264至少要8Mbps•多媒体数据流对带宽的需求还表现出单向的特性，这是因为多媒体应用多为非对称的结构，即往往是从发送方传送大量的数据流给接收方，而反向的传输量则很小IPTV流媒体传输与控制协议•流媒体的网络传输特征–低传输延迟•对交互的分布式多媒体应用而言，比带宽更加难以处理的是传输延迟问题。传输延迟的一个表现形式是端到端延迟(end—to—enddelay)•多媒体视频会议的实践和ITU的建议将交互式视频应用的端到端延迟限制在150ms以内•传输延迟的另一个表现形式是传输抖动(jitter)。抖动是传输中各个分组的不同传送时间和错序造成的IPTV流媒体传输与控制协议•流媒体的网络传输特征–低传输延迟•根据150ms的传输延迟限制，整个传输分为4部分–源端点的压缩和打包延时。由于视频源必须处理每秒25-30帧的视频，那么实时压缩解压缩的处理能力必须达到30-40ms以内。这是网络延时中较小的一部分。–终端排队和等时延时。数据包排队进入终端以后，进入回放缓冲区，直到调度出缓冲区，这段延时也是40ms左右–终端的解包和解压缩延时。从回放缓冲区调度出来的数据包经过解包和解压缩，这段耗时与压缩和打包延时相同，为30-40ms–传输的端到端延时。经过其他阶段的延时，传输的端到端延时被限制在40ms以内IPTV流媒体传输与控制协议•流媒体的网络传输特征–低传输延迟•端到端延时包括线路延时和网络中路由器、网关等逻辑部分的处理与存储转发的延时。前者无法减少。解决端到端延迟的核心环节是如何降低路由器等器件的处理与存储转发延时•分组交换在网络中间的每个节点上都进行差错检验，如果出现差错，则进行重传，因此端到端延时较大•帧中继只做差错检验，如果出现差错，则丢弃信包，而数据重传等恢复工作交给端点完成，这样在一般情况下，端到端延时较小•ATM差错检验工作都交给端点去完成，交换节点的惟一工作就是传送信包，因此端到端延时最小IPTV流媒体传输与控制协议•流媒体的网络传输特征–支持组播模式•分布式多媒体应用系统要求网络支持多播的通信模式，这尤其体现在多点视频会议系统中•由于单播与广播的局限性，在实践中产生组播的概念•多播设置了一个多播组，源节点仅将数据同时传送至多播组中的节点，数据的拷贝和发送都由网络动态完成，最大限度地保证数据占用尽可能少的带宽资源，这正是符合分布式多媒体多点传输要求IPTV流媒体传输与控制协议•流媒体的网络传输特征–可靠性•传统的网络传输目标是提供可靠的端到端的通信•通信系统采用校验(如CRC校验)及序列编号的方法，进行差错检验；采用反向应答、信包重传的握手协议进行差错恢复•系统有必要把差错检验和差错恢复工作交给上层完成，下层网络只需为上层提供反映物理传输特性的服务IPTV流媒体传输与控制协议•流媒体的网络传输特征–通道同步•视频流、音频流及其他数据流从不同的传输通路，经由不同的路由到达终端节点时，有必要采取一定的机制实现异种数据流之间的同步问题，这称为通道同步问题•不同通道的同步问题可以通过设置时间戳与开辟回放缓冲区来解决，这属于端到端的协调任务IPTV流媒体传输与控制协议•多媒体网络的服务质量(QoS)问题–多媒体与网络要解决的核心问题–提高服务质量，涉及到网络的底层物理传输模式、网络协议堆栈的内容与结构、网络应用系统的相关控制等多方面的内容，单纯从一个方面是不能够解决这个问题IPTV流媒体传输与控制协议•RTP／RTCP协议族概述–功能描述•UDP和TCP能够对来自不同应用程序的数据流进行复用，并提供校验•如果在接收的包中检测到有一个以上的误码，TCP／UDP层就丢掉这个包，这样上一层(例如RTP)将不会收到这个损坏的包•TCP重传所引入的延迟对于具有严格延迟要求的流应用来说是不可接受的，因此一般用UDP作为视频流传输协议IPTV流媒体传输与控制协议•RTP／RTCP协议族概述–功能描述•由于UDP不能保证包的传输，所以接收端必须依靠上一层协议(即RTP)来检测包的丢失。RTP是一个因特网标准协议，用于提供端对端的传输功能，以便支持实时应用•RTCP是为了向RTP话路的参与者提供QoS反馈IPTV流媒体传输与控制协议•RTP／RTCP协议族概述–功能描述•RTCP并不保证QoS或可靠性传输，结合RTP提供以下支持媒体流的功能–时间戳：RTP提供时间标记，用于不同媒体流之间的同步–序列编号：由于到达接收端的数据包可能是不按次序的(UDP不按次序传送数据包)，RTP用序列编号对接收到的数据包进行正确的排序–有效载荷类型识别：包含在RTP包中的有效载荷类型由一个称为有效载荷类型识别符的RTP包头域来指示–信源识别：每一个RTP包的信源由一个称为同步信源识别符(SSRC)的RrP包头域来指示IPTV流媒体传输与控制协议•RTP／RTCP协议族概述–功能描述•RTCP提供的服务–QoS反馈：这是RTCP的首要功能–参与者识别：信源可以由RTP包头的SSRC域来识别–控制包定标：为了给发送到若干参与者的RTCP控制包定标–媒体间同步：RTCP发信方报告含有实时指示和相应的RTP时间戳–最少话路控制信息：这项可选功能用于传送话路信息，如参与者的名字IPTV流媒体传输与控制协议•RTP／RTCP协议族概述–RTP对数据传输的封装•数据类型PT(pay)oadtype)•时间戳(TimeStamp)•序列号(SeqNumber)•标志位M(marker)•同步源标识SSRC(synchron1zat1OnS0Urce)IPTV流媒体传输与控制协议•RTP／RTCP协议族概述–RTCP协议概述•RTCP协议将控制包周期性发送给所有连接者，采用与RTP数据包相同的分布机制，低层协议提供数据包与控制包的复用，使用单独的UDP端口号或使用TCP协议来传输•对于RTP会话或者广播，通常使用组播地址，属于这个会话的所有RTP和RTCP信息包都使用这个组播地址，通过使用TCP或不同的端口号，可以把RTP信息包和RTCP信息包区分开来IPTV流媒体传输与控制协议•RTP／RTCP协议族概述–RTCP包格式•RTCP包的类型–SR：发送报告，当前发送者的发送和接收统计–RR：接收报告，非发送者发出的接收统计–SDES：源描述项，包括规范名字项CNAME–BYE：表示结束–APP：特定应用功能•RTCP控制包–每个RTCP控制包包括一个固定包头和可变长的数据部分IPTV流媒体传输与控制协议•RTCP的传输间隔–RTP设计成允许自动扩展状态，连接用户数可以从几个到上千个，而对于组播，不管连接者的数目有多少，数据速率是一个定数–RTCP控制信号流量是应该受控的。如每个参加者都以固定速率发送接收报告，则控制信号流量将随参加者数目而线性增长，因此速率必须根据参加者数目按比例下降，而不是采用固定速率IPTV流媒体传输与控制协议•RTSP协议功能–RTSP的一个主要功能是支持类拟VCR的控制操作，如停止、暂停／重新开始、快进和快退–RTSP还可以提供选择传输通道(例如，UDP、组播UDP或TCP)的方法以及基于RTP的传输机制–建立和控制在媒体服务器和客户机之间的连续的音频／视频媒体流IPTV流媒体传输与控制协议•RTSP协议–RTSP交互原理•RTSP为流音频和视频提供的服务与HTTP(超文本传输协议)为文本和图形所提供的服务相同•RTSP中，每一个演示和媒体流都被一个RTSPURL(通用资源定位器)所识别•RTSP用于从媒体服务器启动和直接传送流媒体数据IPTV流媒体传输与控制协议•RTSP协议的特点–可扩展性–易解析–安全–独立于传输–多服务器支持IPTV流媒体传输与控制协议•RTSP协议的特点–记录设备控制–流控与会议开始分离–适合专业应用–演示描述便捷–代理与防火墙友好–HTTP友好IPTV流媒体传输与控制协议•RTSP协议的特点–方便的服务器控制–传输协调–性能协调–操作模式多样化•单播：以用户选择的端口号将媒体发送到RTSP请求源•组播，服务器选择地址：媒体服务器选择组播地址和端口，这是现场直播或准点播常用的方式•组播，用户选择地址：如服务器加入正在进行的组播会议，组播地址、端口和密匙由会议描述给出IPTV流媒体传输与控制协议•RTSP协议参数–版本–RTSPURL–会话标识–连接标识–SMPTE时标–正常播放时间–绝对时间–可选标签IPTV流媒体传输与控制协议•RSVP协议–RSVP协议的作用及要求•针对Internet原有传输层协议不能保障QoS和不支持多点传输的缺点，RSVP在业务流传送之前，预约一定的网络资源，建立静态或动态的传输逻辑通路，保障了每一业务流都有足够的“独享”的带宽，克服了由于网络信包过多引起的拥塞、丢失和重传，提高了网络传输的QoS性能IPTV流媒体传输与控制协议•RSVP协议–RSVP的特征•接收方执行资源预留，是由接收方初始化并执行操作的资源预留协议•不同的预留类型，无滤包器的形式、固定滤包器的形式和动态滤包器的形式•维护网络的“实时状态”，在交换节点设置“实时状态”记录当前的系统信息，并将维护预留资源的责任交给终端用户。“实时状态”是指在交换节点中记录的系统信息，RSVP应自动地维护它。•协议过载是指因协议管理信息过多而引起的网络过载现象。RSVP的过载由3个因素决定：RSVP消息(预留消息和路径消息)的数目、RSVP消息的大小和消息发出的频率IPTV流媒体传输与控制协议•RSVP协议–RSVP操作模型•RSVP资源预留处理初始化•RSVP中心服务器查询本地路由器的路由表获得路由信息•主机发送IGMP消息，加入组播行列•沿路由发送RSVP预留资源信息•每个加入资源预留的路由器将收到的数据包传送给包分类器，RSVP包分类器决定每个数据包的路由和QoS类别•然后将数据包传送至包调度器中排队IPTV流媒体传输与控制协议•RSVP协议–RSVP操作模型•RSVP包调度器给每个接口对应的数据链路层媒介分配资源，如果数据链路层媒介自身有QoS的管理能力，则包调度器负责协调数据链路层，以获RSVP所要求的QoS•QoS请求一般由接收主机出发，传送到RSVP服务器，RSVP协议对所有节点(路由器和主机)请求预留资源，沿逆向路径，直至数据源•在每个节点处，RSVP采用一个“进入允许”的程序，以决定是否能提供预留请求所需要的QoSIPTV流媒体传输与控制协议•RSVP协议–RSVP隧道•在整个Internet上同时配置RSVP是不可能的•网络有充足额外容量，也可以提供实时服务。为了支持RSVP网络连接通过不支持RSVP的网络，RSVP采用隧道技术