|
支持流媒体的协议
多媒体应用的一个显著特点是数据量大,并且许多应用对实时性要求比较高。传统的TCP 协议是一个面向连接的协议,它的重传机制和拥塞控制机制都是不适用于实时多媒体传输的。RTP 是一个应用型的传输层协议,它并不提供任何传输可靠性的保证和流量的拥塞控制机制。RTP 位于UDP(User Datagram Protocol) 之上。UDP 虽然没有TCP 那么可靠,并且无法保证实时业务的服务质量,需要RTCP 实时监控数据传输和服务质量。但是,由于UDP 的传输时延低于TCP ,能与音频和视频很好地配合。因此,在实际应用中,RTP/ RTCP/ UDP 用于音频/ 视频媒体,而TCP 用于数据和控制信令的传输。目前,支持流媒体传输的协议主要有实时传输协议RTP( Real-Time Transport Protocol) 、实时传输控制协议RTCP(Real-Time Transport Control Protocol) 和实时流协议RTSP(Real-Time Streaming Protocol) 等。下面分别对这三种协议作简要介绍。流媒体协议栈如图1 所示。 图1 流媒体协议栈  2．实时传输协议RTP（Real-Time Transport Protocol）： RTP是针对Internet上多媒体数据流的一个传输协议, 由IETF(Internet工程任务组)作为RFC1889发布。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP或ATM等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。 2.1 RTP工作机制 威胁多媒体数据传输的一个尖锐的问题就是不可预料数据到达时间。但是流媒体的传输是需要数据的适时的到达用以播放和回放。rtp协议就是提供了时间标签,序列号以及其它的结构用于控制适时数据的流放。在流的概念中”时间标签”是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后,就依照时间标签按照正确的速率恢复成原始的适时的数据。不同的媒体格式调时属性是不一样的。但是rtp本身并不负责同步，rtp只是传输层协议，为了简化运输层处理，提高该层的效率。将部分运输层协议功能（比如流量控制）上移到应用层完成。同步就是属于应用层协议完成的。它没有运输层协议的完整功能，不提供任何机制来保证实时地传输数据，不支持资源预留，也不保证服务质量。rtp报文甚至不包括长度和报文边界的描述。同时rtp协议的数据报文和控制报文的使用相邻的不同端口，这样大大提高了协议的灵活性和处理的简单性。 rtp协议和udp二者共同完成运输层协议功能。udp协议只是传输数据包，不管数据包传输的时间顺序。 rtp的协议数据单元是用udp分组来承载的。在承载rtp数据包的时候，有时候一帧数据被分割成几个包具有相同的时间标签，则可以知道时间标签并不是必须的。而udp的多路复用让rtp协议利用支持显式的多点投递，可以满足多媒体会话的需求。 rtp协议虽然是传输层协议但是它没有作为osi体系结构中单独的一层来实现。rtp协议通常根据一个具体的应用来提供服务，rtp只提供协议框架，开发者可以根据应用的具体要求对协议进行充分的扩展。 2.2 RTP协议的报文结构 RTP头格式如图2所示：  开始12个八进制出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。各段含义如下： ①版本（V） 2位，标识RTP版本。 ②填充标识（P） 1位，如设置填充位，在包尾将包含附加填充字，它不属于有效载荷。填充的最后一个八进制包含应该忽略的八进制计数。某些加密算法需要固定大小的填充字，或为在底层协议数据单元中携带几个RTP包。 ③扩展（X） 1位，如设置扩展位，固定头后跟一个头扩展。 ④CSRC计数（CC） 4位，CSRC计数包括紧接在固定头后CSRC标识符个数。 ⑤标记（M） 1位，标记解释由设置定义，目的在于允许重要事件在包流中标记出来。设置可定义其他标示位，或通过改变位数量来指定没有标记位。 ⑥载荷类型（PT） 7位，记录后面资料使用哪种 Codec ， receiver 端找出相应的 decoder 解碼出來。 常用 types：
⑦系列号 16位，系列号随每个RTP数据包而增加1，由接收者用来探测包损失。系列号初值是随机的，使对加密的文本攻击更加困难。 ⑧时标 32位，时标反映RTP数据包中第一个八进制数的采样时刻，采样时刻必须从单调、线性增加的时钟导出，以允许同步与抖动计算。时标可以让receiver端知道在正确的时间将资料播放出来。  由上图可知，如果只有系列号，并不能完整按照顺序的将data播放出来，因为如果data中间有一段是没有资料的，只有系列号的话会造成错误，需搭配上让它知道在哪个时间将data正确播放出来，如此我们才能播放出正确无误的信息。 ⑨SSRC 32位，SSRC段标识同步源。此标识不是随机选择的，目的在于使同一RTP包连接中没有两个同步源有相同的SSRC标识。尽管多个源选择同一个标识的概率很低，所有RTP实现都必须探测并解决冲突。如源改变源传输地址，也必须选择一个新SSRC标识以避免插入成环行源。 ⑩CSRC列表 0到15项，每项32位。CSRC列表表示包内的对载荷起作用的源。标识数量由CC段给出。如超出15个作用源，也仅标识15个。CSRC标识由混合器插入，采用作用源的SSRC标识。 见http://zhangjunhd.blog.51cto.com/113473/25481/ RTP是一种提供端对端传输服务的实时传输协议，用来支持在单目标广播和多目标广播网络服务中传输实时数据，而实时数据的传输则由RTCP协议来监视和控制。 RTP定义在RFC 使用RTP协议的应用程序运行在RTP之上，而执行RTP的程序运行在UDP的上层，目的是为了使用UDP的端口号 和检查和。如图16-12所示，RTP可以看成是传输层的子层。由多媒体应用程序生成的声音和电视数据块被封装在RTP信息包中，每个RTP信息包被封装 在UDP消息段中，然后再封装在IP数据包中。 1889中。 信息包的结构包含广泛用于多媒体的若干个域，包括声音点播(audio-on-demand)、影视点播(video on demand)、因特网电话(Internet telephony)和电视会议(videoconferencing)。RTP的规格没有对声音和电视的压缩格式制定标准，它可以被用来传输普通格式的 文件。例如，WAV或者GSM(Global System for Mobile communications)格式的声音、MPEG-1和MPEG-2的电视，也可以用来传输专有格式存储的声音和电视文件。
图16-12 RTP是传输层上的协议 从应用开发人员的角度来看，可把RTP执行程序看成是应用程序的一部分，因为开发人员必需把RTP集成到应用程序 中。在发送端，开发人员必需把执行RTP协议的程序写入到创建RTP信息包的应用程序中，然后应用程序把RTP信息包发送到UDP的套接接口 (socket interface)，如图16-13所示；同样，在接收端，RTP信息包通过UDP套接接口输入到应用程序，因此开发人员必需把执行RTP协议的程序写 入到从RTP信息包中抽出媒体数据的应用程序。
图16-13 RTP和UDP之间的接口 现以用RTP传输声音为例来说明它的工作过程。假设音源的声音是64 kb/s的PCM编码声音，并假设应用程序取20毫秒的编码数据为一个数据块(chunk)，即在一个数据块中有160个字节的声音数据。应用程序需要为 这块声音数据添加RTP标题生成RTP信息包，这个标题包括声音数据的类型、顺序号和时间戳。然后RTP信息包被送到UDP套接接口，在那里再被封装在 UDP信息包中。在接收端，应用程序从套接接口处接收RTP信息包，并从RTP信息包中抽出声音数据块，然后使用RTP信息包的标题域中的信息正确地译码 和播放声音。 如果应用程序不使用专有的方案来提供有效载荷类型(payload type)、顺序号或者时间戳，而是使用标准的RTP协议，应用程序就更容易与其他的网络应用程序配合运行，这是大家都希望的事情。例如，如果有两个不同 的公司都在开发因特网电话软件，他们都把RTP合并到他们的产品中，这样就有希望：使用不同公司电话软件的用户之间能够进行通信。 这里需要强调的是，RTP本身不提供任何机制来确保把数据及时递送到接收端或者确保其他的服务质量，它也不担保在递送过程中不丢失信息包或者防止信息包的次序不被打乱。的确，RTP的封装只是在系统端才能看到，中间的路由器并不区分那个IP数据报是运载RTP信息包的。 RTP允许给每个媒体源分配一个单独的RTP信息包流，例如，摄像机或者麦克风。例如，有两个团体参与的电视会议， 这就可能打开4个信息包流：两台摄像机传送电视流和两个麦克风传送声音流。然而，许多流行的编码技术，包括MPEG-1和MPEG-2在编码过程中都把声 音和电视图像捆绑在一起以形成单一的数据流，一个方向就生成一个RTP信息包流。 RTP信息包没有被限制只可应用于单目标广播，它们也可以在一对多(one-to-many)的多目标广播树或者在 多对多(many-to-many)的多目标广播树上传送。例如，多对多的多目标广播，在这种应用场合下，所有发送端通常都把他们的RTP信息包流发送到 具有相同多目标广播地址的多目标广播树上。 16.6.2 RTP信息包标题域 RTP标题由4个信息包标题域和其他域组成：有效载荷类型(payload type)域，顺序号(sequence number)域，时间戳(timestamp)域和同步源标识符(Synchronization Source Identifier)域等。RTP信息包的标题域的结构如下图所示：
1. 有效载荷类型 RTP信息包中的有效载荷域(Payload Type Field)的长度为7位，因此RTP可支持128种不同的有效载荷类型。对于声音流，这个域用来指示声音使用的编码类型，例如PCM、自适应增量调制或 线性预测编码等等。如果发送端在会话或者广播的中途决定改变编码方法，发送端可通过这个域来通知接收端。表16-01列出了目前RTP所能支持的声音有效 载荷类型。 表16-01 目前RTP所能支持的声音有效载荷类型
对电视流，有效载荷类型可以用来指示电视编码的类型，例如motion JPEG, MPEG-1，MPEG-2或者H.231等等。发送端也可以在会话或者期间随时改变电视的编码方法。表16-02列出了目前RTP所能支持的某些电视有效载荷类型。 表16-02 目前RTP所能支持的声音有效载荷类型
顺序号(Sequence Number Field)域的长度为16位。每发送一个RTP信息包顺序号就加1，接收端可以用它来检查信息包是否有丢失以及按顺序号处理信息包。例如，接收端的应用 程序接收到一个RTP信息包流，这个RTP信息包在顺序号86和89之间有一个间隔，接收端就知道信息包87和88已经丢失，并且采取措施来处理丢失的数 据。 3. 时间戳 时间戳(Timestamp)域的长度为32字节。它反映RTP数据信息包中第一个字节的采样时刻(时间)。接收端可以利用这个时间戳来去除由网络引起的信息包的抖动，并且在接收端为播放提供同步功能。 4. 同步源标识符 同步源标识符(Synchronization Source Identifier，SSRC)域的长度为32位。它用来标识RTP信息包流的起源，在RTP会话或者期间的每个信息包流都有一个清楚的SSRC。 SSRC不是发送端的IP地址，而是在新的信息包流开始时源端随机分配的一个号码。 16.6.3 实时传输控制协议 实时传输控制协议(Real-time Control Protocol，RTCP) 也定义在1996年提出的RFC 1889中。多媒体网络应用把RTCP和RTP一起使用，尤其是在多目标广播中更具吸引力。当从一个或者多个发送端向多个接收端广播声音或者电视时，也就 是在RTP会话期间，每个参与者周期性地向所有其他参与者发送RTCP控制信息包，如图16-14所示。RTCP用来监视服务质量和传送有关与会者的信 息。对于RTP会话或者广播，通常使用单个多目标广播地址，属于这个会话的所有RTP和RTCP信息包都使用这个多目标广播地址，通过使用不同的端口号可 把RTP信息包和RTCP信息包区分开来。 RTCP的主要功能是为应用程序提供会话质量或者广播性能质量的信息。每个RTCP信息包不封装声音数据或者电视数 据，而是封装发送端和/或者接收端的统计报表。这些信息包括发送的信息包数目、丢失的信息包数目和信息包的抖动等情况，这些反馈信息对发送端、接收端或者 网络管理员都是很有用的。RTCP规格没有指定应用程序应该使用这个反馈信息做什么，这完全取决于应用程序开发人员。例如，发送端可以根据反馈信息来修改 传输速率，接收端可以根据反馈信息判断问题是本地的、区域性的还是全球性的，网络管理员也可以使用RTCP信息包中的信息来评估网络用于多目标广播的性 能。 16.6.4 实时流放协议 实时流放协议(Real-Time Streaming Protocol，RTSP)是一个刚开始开发的协议，它的设想描述在RFC 播放的数据流被分成许多信息包，信息包的大小很适用于客户机和服务器之间的带宽。当客户机已经接收到足够多的信息包 之后，用户软件就可开始播放一个信息包，同时对另一个信息包解压缩和接收第三个信息包。这样用户就不需要把整个媒体文件从服务器上下载之后就可立即播放。 广播源可以是现场的数据流也可以是存储的数据流。 RTSP协议想要提供控制多种应用数据传送的功能，提供一种选择传送通道的方法，例如UDP, TCP, IP多目标广播通道，以及提供一种基于RTP协议的递送方法。正在设计的RTSP将工作在RTP的上层，用来控制和传送实时的内容。 RTSP能够与资源保留协议一起使用，用来设置和管理保留带宽的流式会话或者广播。 2326文件中。RTSP是应用级的实时流放协议，它主要目标是为单目标广播和多目标广播上的流式多媒体应用提供牢靠的播放性能，以及支持不同厂家提供的客户机和服务机之间的协同工作能力。 |
|
|
