Internet多媒体协议

Internet多媒体协议MultimediaprotocolsfortheInternet前言最近几年，通过因特网发送和接收音频和视频的网络应用呈现出爆炸性增长的趋势。几乎每天都发布新的多媒体网络应用（也称连续媒体应用），例如视频流、IP电话、因特网无线电、电信会议、交互游戏、虚拟世界、远程教育和很多其它类型。这些应用的服务需求明显不同于那些弹性的应用（如电子邮件、Web、远程登录、文件共享）。特别是，许多多媒体应用对端到端的时延和时延抖动高度敏感，但是可以容忍偶然的数据丢失。显然传统的Internet协议不能对这些应用给以足够的支持，为此，就需要相关的Internet多媒体协议。下面将对Internet多媒体常见应用及协议给出相应的介绍。一、多媒体网络应用因特网带来了各种各样激励人心的多媒体应用。下面简要介绍几种比较常见的多媒体应用：流式存储音视频、流式实况音视频、实时交互音视频。1、流式存储音视频在这类应用中，客户机根据需求请求存储在服务器上的被压缩的音频或视频文件。这类应用有3个关键的区分特征：（1）存储媒体。（2）流。（3）连续播放。•存储媒体。多媒体的内容已经预先录制，并存储在服务器上，因此一个用户可以暂停、倒退、快进或者检索多媒体的内容。从一个客户机提出这种请求到该动作在客户机上表现出来，这期间可接受的响应时间应为1到10s。•流。在流式存储间音视频应用中，客户机通常从服务器接收文件几秒后，就开始播放音视频。这意味着当该客户机在从文件的一个位置开始播放音视频的同时，还从服务器中接收文件的后续部分。这个技术被称为流（Streaming），它避免了在开始播放之前必须下载整个文件（这会引起一个潜在的长时延）。有很多流式多媒体产品。包括RealNetworks公司的RealPlayer、苹果公司的QuickTime和微软的WindowsMedia。•连续播放。一旦多媒体内容开始播放，它应该根据初始记录的时序进行。这就对传输时延提出了严格的限制。为了在客户机播放，必须从服务器中及时接收数据。尽管存储音视频的多媒体应用有连续播放的要求，然而它们的端到端时延限制比那些实况的，交互的应用要宽松。2、流式实况音频和视频•这类应用类似于传统的电台广播和电视，只是它通过因特网来传输。这些应用允许用户接收来自世界任何角落的实况广播和电视传输。•因为流式的实况音视频不是已存储的数据，客户机不能实现快进。但是通过接收数据的本地存储，在某些应用程序中实现诸如实况多媒体转播的暂停和回退等其它交互捷足操作是可能的。像实况广播式的应用经常有很多接收同样咅视频的节目的客户机。通过使用IP多播技术能够有效地完成向多个接收方分发实况音视频。尽管定时限制没有实时交互应用那样严格。但是它和流式存储多媒体一样要求连续播放。从用户请求、播放一个实况传输到播放开始可以容忍的时延最多为几十秒。3、实时交互音频和视频•这类应用允许人们使用音视频互相实时通信。在因特网上的实时交互音频通常称为因特网电话（Internetphone），因为从用户的角度看，它类似于传统的电话交换电话业务。因特网电话能够潜在地以低费用提供PBX（用户交换机）、本地和长途电话业务。它也能推动传统电话交换网络难以支持的新业务的发展，它包括Web电话集成、集团实时通信、目录服务、呼叫过滤等。现在有很多可用的网络电话产品。例如，Skype(一种网络电话)。通过实时的交互式视频，也称视频会议，个人通信不仅可以听见也可以看见。现在也有许多因特网上可以用的实时交互视频产品，包括微软的NetMeeting。从一个用户说话或者移动到这个动作在接收主机上呈现（playback）的时延应该小于几百毫秒。对于语音，小于150ms的时延不会被听者觉察到，150到400ms时，即时不会使对话变得完全无法理解，也会对语音对话造成破坏。4、音频和视频压缩多媒体数据量是巨大的，在音频的视频能够通过计算机传输之前，它必须被数字化和压缩。音频压缩:常见的有PCMuLaw,PCMALaw、GSM（13kbps）、G729(8kbps)、MP3。视频压缩：H.26x、MPEG-x、还有苹果公司的QickTime和RealNetworks的编码器。二、Internet多媒体协议下面介绍以下几种协议：RTSPRTP/RTCPSDPSIPH.323RSVP重点介绍RTSP、RTP/RTCP、SIP协议1、RTSP（RealTimeStreamingProtocol）协议许多因特网用户希望控制连续媒体的播放，包括暂停播放、将播放重新定位在未来或者过去的时间点、快进可视播放、快退可视播放等等。为了允许用户控制播放，媒体播放器和服务器需要一个协议来交换播放控制信息。RTSP就是这样一个协议。RTSP协议由IETFstandard－RFC2326定义。RTSP简介RTSP控制的流可能用到RTP，但RTSP操作并不依赖用于传输连续媒体的传输机制。RTSP在语法和操作上与HTTP/1.1类似，因此HTTP的扩展机制在多数情况下可加入RTSP。RTSP允许媒体播放器控制媒体流的传输。控制动作包括暂停/继续、播放重定位、快进和快退。RTSP是一个带外协议（Out-of-bandprotocol）。特别是，RTSP报文在带外发送，而媒体流的分组结构没有被RTSP定义，它被认为是“带内”的。RTSP报文和媒体流使用不同的端口号，前者使用端口号544。RTSP规范允许RTSP报文通过TCP或者UDP发送。RTSP的层次图webserverWHTTPGETpresentationdescriptionSETUPPLAYRTPaudio/videoRTCPTEARDOWNclientCmediaserversA&V客户机与服务器之间使用RTSP进行交互：元文件例子：titleTwister/titlesessiongrouplanguage=enlipsyncswitchtracktype=audioe=PCMU/8000/1src=rtsp://audio.example.com/twister/audio.en/lofitracktype=audioe=DVI4/16000/2pt=90DVI4/8000/1src=rtsp://audio.example.com/twister/audio.en/hifi/switchtracktype=video/jpegsrc=rtsp://video.example.com/twister/video/group/session元文件为SMIL(同步多媒体集成语言)语法。SMIL是遵从XML的语言。实际中的RTSP报文C:SETUPrtsp://audio.example.com/twister/audioRTSP/1.0Transport:rtp/udp;compression;port=3056;mode=PLAYS:RTSP/1.02001OKSession4231C:PLAYrtsp://audio.example.com/twister/audio.en/lofiRTSP/1.0Session:4231Range:npt=0-C:PAUSErtsp://audio.example.com/twister/audio.en/lofiRTSP/1.0Session:4231Range:npt=37C:TEARDOWNrtsp://audio.example.com/twister/audio.en/lofiRTSP/1.0Session:4231S:2003OK2.1RTP（Real-timeTransportProtocol）数据传输协议RTP提供端对端网络传输功能，适合通过多播和点播传送实时数据，如视频、音频和仿真数据。RTP没有涉及资源预订和质量保证（QoS）等实时服务，RTCP扩充数据传输以允许监控数据传送，提供最小的控制和识别功能。RTP与RTCP设计成独立于传输层和网络层。RTP最新版由RFC3550定义RTP头部格式字段定义•version(V):2bitsRTP版本号。•padding(P):1bit置1时表明末尾有非数据的填充字段。所有填充字段的最后一个字节为填充字段长度。填充字段常被用于需加密的场合。•extension(X):1bit此位若置1，则在标准的头部字段后还有扩展的字段。•CSRCcount(CC):4bitsCSRC列表的项数•marker(M):1bit由配置文件定义，用于特定的应用程序。•payloadtype(PT):7bits负载数据类型编号，具体格式定义在PAYLOADFORMATSPECIFICATION文件中。•sequencenumber:16bits每发送一个RTP包，该项加1，其初始数值随机产生，以防止别人破译加密。•timestamp:32bits该项用于时间同步计算和抖动控制，其精度必须足以满足上述两项要求。时钟频率与负载类型有关，2者同时定义在PAYLOADFORMATSPECIFICATION文件中。其初始值随机。•SSRC:32bits同步化源标识符，即此RTP包的发出者。因为一个RTP会话中不能有2个相同的SSRC，所以当发送者传输地址改变时此值需重新生成，以防止形成循环。•CSRClist:0to15items,32bitseach字段头中CSRCCOUNT项给出了该项中ITEM的数量。当包通过MIXER时由MIXER将原来包中的SSRC标识符作为CSRC插入，而将MIXER自己的SSRC作为新的SSRC项。捕获的RTP包例子：00000004617D1DF0000D619DCA270800\4500..a}....a..'..E.001000327A2C000080113CD8C0A80102C0A8.2z,...........00200164\138A1F40001EE9C4\8000C9E16D54.d...@........mT00303D8ED3878D1A31323334353637383930=.....1234567890说明：前十四个字节：MAC址址头部。接下来20个字节：IP头部接下来8个字节：UDP头部余下的是RTP数据。前12个字节是RTP头部最后的是数据”1234567890”共10个字节整个数据包长度是64个字节。00000004617D1DF0000D619DCA270800\4500..a}....a..'..E.001000327A2D000080113CD7C0A80102C0A8.2z-...........00200164\138A1F40001EE9B9\8000C9E26D54.d...@........mT00303D98D3878D1A31323334353637383930=.....1234567890•RTP标准实际定义一对协议，RTP和实时传输控制协议（Real-timeTransportProtocol,RTCP）。前者被用来交换多媒体数据，后者被用来定期发送一个特定的数据流相关的控制信息。当运行在UDP之上时，RTP数据流和相应的RTCP控制流使用相邻的传输层端口。RTP数据使用偶数的端口号而RTCP控制信息使用下一个更高编号（奇数）的端口号。•因为RTP被设计成支持广泛多样的应用，它提供一个灵活的机制，使之不用重复修改RTP协议本身就用来开发新的应用。对每一类应用（如音频），RTP定义一个配置文件（profile）和一个或多个格式（format）。配置文件提供一组信息，确保对那个应用类的RTP头部字段有共同的理解，当考查头部时将十分清楚。格式说明将如何理解头部接下来的数据。RTP设计体现出的体系结构原理，称为应用层框架（ApplicationLevelFraming,ALF）。RTP将很多协议细节放在一个详尽说明某一应用的配置文件和格式文档中。如：February4,2005RFC3984(RTPPayloadForma