RTP是一种提供端对端传输服务的实时传输协议，用来支持在单目标广播和多目标广播网络服务中传输实时数据，而实时数据的传输则由RTCP协议来监视和控制。

RTP定义在RFC

使用RTP协议的应用程序运行在RTP之上，而执行RTP的程序运行在UDP的上层，目的是为了使用UDP的端口号和检查和。如图16-12所示，RTP可以看成是传输层的子层。由多媒体应用程序生成的声音和电视数据块被封装在RTP信息包中，每个RTP信息包被封装在UDP消息段中，然后再封装在IP数据包中。

图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信息包流发送到具有相同多目标广播地址的多目标广播树上。

RTP标题由4个信息包标题域和其他域组成：有效载荷类型(payload type)域，顺序号(sequence number)域，时间戳(timestamp)域和同步源标识符(Synchronization Source Identifier)域等。RTP信息包的标题域的结构如下图所示：

RTP信息包中的有效载荷域(Payload Type Field)的长度为7位，因此RTP可支持128种不同的有效载荷类型。对于声音流，这个域用来指示声音使用的编码类型，例如PCM、自适应增量调制或线性预测编码等等。如果发送端在会话或者广播的中途决定改变编码方法，发送端可通过这个域来通知接收端。表16-01列出了目前RTP所能支持的声音有效载荷类型。

对电视流，有效载荷类型可以用来指示电视编码的类型，例如motion JPEG, MPEG-1，MPEG-2或者H.231等等。发送端也可以在会话或者期间随时改变电视的编码方法。表16-02列出了目前RTP所能支持的某些电视有效载荷类型。

顺序号(Sequence Number Field)域的长度为16位。每发送一个RTP信息包顺序号就加1，接收端可以用它来检查信息包是否有丢失以及按顺序号处理信息包。例如，接收端的应用程序接收到一个RTP信息包流，这个RTP信息包在顺序号86和89之间有一个间隔，接收端就知道信息包87和88已经丢失，并且采取措施来处理丢失的数据。

时间戳(Timestamp)域的长度为32字节。它反映RTP数据信息包中第一个字节的采样时刻(时间)。接收端可以利用这个时间戳来去除由网络引起的信息包的抖动，并且在接收端为播放提供同步功能。

同步源标识符(Synchronization Source Identifier，SSRC)域的长度为32位。它用来标识RTP信息包流的起源，在RTP会话或者期间的每个信息包流都有一个清楚的SSRC。SSRC不是发送端的IP地址，而是在新的信息包流开始时源端随机分配的一个号码。

实时传输控制协议(Real-time Control Protocol，RTCP)也定义在1996年提出的RFC 1889中。多媒体网络应用把RTCP和RTP一起使用，尤其是在多目标广播中更具吸引力。当从一个或者多个发送端向多个接收端广播声音或者电视时，也就是在RTP会话期间，每个参与者周期性地向所有其他参与者发送RTCP控制信息包，如图16-14所示。RTCP用来监视服务质量和传送有关与会者的信息。对于RTP会话或者广播，通常使用单个多目标广播地址，属于这个会话的所有RTP和RTCP信息包都使用这个多目标广播地址，通过使用不同的端口号可把RTP信息包和RTCP信息包区分开来。

图16-14 每个参与者周期性地发送RTCP控制信息包

RTCP的主要功能是为应用程序提供会话质量或者广播性能质量的信息。每个RTCP信息包不封装声音数据或者电视数据，而是封装发送端和/或者接收端的统计报表。这些信息包括发送的信息包数目、丢失的信息包数目和信息包的抖动等情况，这些反馈信息对发送端、接收端或者网络管理员都是很有用的。RTCP规格没有指定应用程序应该使用这个反馈信息做什么，这完全取决于应用程序开发人员。例如，发送端可以根据反馈信息来修改传输速率，接收端可以根据反馈信息判断问题是本地的、区域性的还是全球性的，网络管理员也可以使用RTCP信息包中的信息来评估网络用于多目标广播的性能。

实时流放协议(Real-Time Streaming Protocol，RTSP)是一个刚开始开发的协议，它的设想描述在RFC

播放的数据流被分成许多信息包，信息包的大小很适用于客户机和服务器之间的带宽。当客户机已经接收到足够多的信息包之后，用户软件就可开始播放一个信息包，同时对另一个信息包解压缩和接收第三个信息包。这样用户就不需要把整个媒体文件从服务器上下载之后就可立即播放。广播源可以是现场的数据流也可以是存储的数据流。

RTSP协议想要提供控制多种应用数据传送的功能，提供一种选择传送通道的方法，例如UDP, TCP, IP多目标广播通道，以及提供一种基于RTP协议的递送方法。正在设计的RTSP将工作在RTP的上层，用来控制和传送实时的内容。

RTSP能够与资源保留协议一起使用，用来设置和管理保留带宽的流式会话或者广播。

实时传输协议RTP
1.RTP协议：
    RTP（ Real-time Transport Protocol）协议最初是在70年代为了尝试传输声音文件，把包分成几部分用来传输语音，时间标志和队列号。经过一系列发展，RTP第一版本在1991年8月由美国的一个实验室发布了。到本世纪1996年形成了标准的的版本。很多著名的公司如Netscape ,就宣称“Netscape LiveMedia”是基于RTP协议的。. Microsoft 也宣称他们的“NetMeeting”也是支持RTP协议.
    RTP被定义为传输音频、视频、模拟数据等实时数据的传输协议。最初设计是为了数据传输的多播，但是它也用于单播的。与传统的注重的高可靠的数据传输的运输层协议相比，它更加侧重的数据传输的实时性。此协议提供的服务包括时间载量标识、数据序列、时戳、传输控制等。RTP与辅助控制协议RTCP一起得到数据传输的一些相关的控制信息。

2．RTP协议是如何工作的：
    在前面说明过，威胁多媒体数据传输的一个尖锐的问题就是不可预料数据到达时间。但是流媒体的传输是需要数据的适时的到达用以播放和回放。RTP协议就是提供了时间标签,序列号以及其它的结构用于控制适时数据的流放。
    在流的概念中”时间标签”是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后,就依照时间标签按照正确的速率恢复成原始的适时的数据。不同的媒体格式调时属性是不一样的。但是RTP本身并不负责同步，RTP只是传输层协议，为了简化了运输层处理，提高该层的效率。将部分运输层协议功能（比如流量控制）上移到应用层完成。同步就是属于应用层协议完成的。它没有运输层协议的完整功能，不提供任何机制来保证实时地传输数据，不支持资源预留，也不保证服务质量。RTP报文甚至不包括长度和报文边界的描述。同时RTP协议的数据报文和控制报文的使用相邻的不同端口，这样大大提高了协议的灵活性和处理的简单性。
    RTP协议和UDP二者共同完成运输层协议功能。UDP协议只是传输数据包，是不管数据包传输的时间顺序。RTP的协议数据单元是用UDP分组来承载的。在承载RTP数据包的时候，有时候一帧数据被分割成几个包具有相同的时间标签，则可以知道时间标签并不是必须的。而UDP的多路复用让RTP协议利用支持显式的多点投递，可以满足多媒体会话的需求。
    RTP协议虽然是传输层协议但是它没有作为OSI体系结构中单独的一层来实现。RTP协议通常根据一个具体的应用来提供服务， RTP只提供协议框架，开发者可以根据应用的具体要求对协议进行充分的扩展。目前，RTP的设计和研究主要是用来满足多用户的多媒体会议的需要，另外它也适用于连续数据的存储，交互式分布仿真和一些控制、测量的应用中。基于RTP的实验和商业产品也层出不穷。

实时传输控制协议RTCP协议

1. RTCP协议：
    RTCP（Real-time Transpor、Control Protocol）是设计和RTP一起使用的进行流量控制和拥塞控制的服务控制协议。

2. RTCP协议如何工作：
    当应用程序开始一个RTP会话时将使用两个端口：一个给RTP，一个给RTCP。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。在RTP的会话之间周期的发放一些RTCP包以用来传监听服务质量和交换会话用户信息等功能。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。根据用户间的数据传输反馈信息，可以制定流量控制的策略，而会话用户信息的交互，可以制定会话控制的策略。
    RTCP协议处理机根据需要定义了五种类型的报文——
    RR: receiver report
    SR: sender report
    SDES: source description items.
    BYE: indicates end of participation.
    APP: application specific functions
    它们完成接收、分析、产生和发送控制报文的功能。

实时流协议RTSP协议
1. RTSP协议：
    RTSP（Real Time Streaming Protocol）协议定义了如何有效地通过IP网络传送多媒体数据，是一种客户端到服务器端的多媒体描述协议。
RTSP是一个非常类似于HTTP的应用层协议。每个发布和媒体文件也被定义为RTSP UPL。而媒体文件的发布信息被书写进一个被称为媒体发布文件里，这个文件在后面会说明。在这个文件说明的包括编码器，语言，RTSP ULS，地址，端口号以几其它参数。这个发布文件可以在客户端通过EMAIL形式或者HTTP形式获得。
    RTSP是由RealNetworks和Netscape以及哥伦比亚大学共同提出的。它是从RealNetworks的"RealAudio" 和 Netscape的 "LiveMedia"的实践和经验发展来来的。第一份RTSP协议是由IETF 在1996年8月9日正式提交后作为INTERNET的标准，在此后此协议经过了很多明显的变化。它的应用现在是广泛的，APPLE、IBMNetscape, Apple, IBM, Silicon Graphics, VXtreme, Sun 还有其它公司都宣称它们的在线播放器支持RTSP协议，不过微软一直都坚持不支持此协议，不知道这种局面还会持续多久。

2. RTSP协议的特点：
    RTSP是应用层协议,与RTP、RSVP一起设计来完全流式服务。
RTSP有很大的灵活性，可被用在多种操作系统上,它允许客户端和不同厂商的服务平台交互。
RTSP在体系结构上位于RTP和RTCP之上，它使用RTP完成数据传输。它将流式媒体数据可控制的通过网络传输到客户端。
    RTSP可以保持用户计算机与传输流业务服务器之间的固定连接，用于观看者与单播（Unicast）服务器通信并且还允许双向通信，观看者可以同流媒体服务器通信.
提供类似“VCR”形式的例如暂停、快进、倒转、跳转等操作。操作的资源对象可以是直播流也可以是存储片段。
    RTSP是设还提供了选择传输通道，如使用UDP还是多点UDP或是TCP。

资源预留协议RSVP
1. RSVP协议：
    RSVP (Resorce reSerVation Protocol) 资源预留协议并不是一个路由协议，而是一种IP网络中的信令协议，它与路由协议相结合来实现对网络传输服务质量（QoS）的控制。RSVP是为支持因特网综合业务而提出的。这是解决IP通信中QoS（服务质量）问题的一种技术，用来保证点端到端的传输带宽。

2. RSVP协议是如何工作：
    RSVP使用控制数据报，这些数据报在向特定地址传输时包括了需要由路由器检查（有些时候需要更新）的信息,如果路由器需要决定是不是要检查数据报的内容的时候对上层数据内容进行语法分析。这种分析的代价可不小。现在的情况是，网络终端利用它向网络申请资源，在这种表明“申请” 的信号中，包含着如下的信息：业务的种类？使用者类型？什么时间？需要多大带宽？其他参考信息？网络在接收到上类信息后，会根据实际情况为此次连接分配一个优先代码，用户利用优先代码进行信息传递时，网络不需重新对业务进行分析与判别，从另外一个角度来说，利用RSVP 能从一定程度上减少网络对信息处理的时延，提高网络节点的工作效率，改善信息传输的服务质量（QoS）。实时应用用RSVP是为了在传输路径中保持必要的资源以保证请求能确保到达。
    RSVP是IP路由器为提供更好的服务质量向前迈进的具有深刻意义的一步。传统上IP路由器只负责分组转发，通过路由协议知道邻近路由器的地址。而RSVP则类似于电路交换系统的信令协议一样，为一个数据流通知其所经过的每个节点（IP路由器），与端点协商为此数据流提供质量保证。RSVP协议一出现，立刻获得广泛的认同，基本上被任为较好地解决了资源预留的问题。

    在前面我们讨论了一些实时媒体控制的相近的四个协议。在这里我再概括性的说明一下：
    RTP是实时数据传输协议。它提供时间标志，序列号以及其它能够保证在实时数据传输时处理时间的方法。它是依靠RVSP保证服务质量标准的。

RTP/RTCP流媒体服务器技术研究
1 引言

　　随着互联网的飞速发展,流媒体技术的应用越来越广泛,从网上广播、电影播放到远程教学以及在线的新闻网站等都用到了流媒体技术。但现有公开文献所报道的大多是利用现有的流媒体服务器来搭建一个流媒体服务系统，或者是针对流媒体数据的编码方式所进行的研究。本文对流媒体服务器技术的研究重点在于如何建立一个服务器，并且在实现流媒体传输的两个基本协议RTP/RTCP的基础上构建一个基本的流媒体服务器。

2 流媒体技术简介

2.1 “流”的定义

　　现在网上传输视频、音频主要有下载（Download）和流式传输（Streaming）两种方式。流式传输是连续传送视/音频信号，当流媒体在客户机播放时其余部分在后台继续下载。流式传输有顺序流式传输(Progressive Streaming)和实时流式传输(Realtime Streaming)两种方式。实时流式传输是实时传送，特别适合现场事件，实时流式传输必须匹配连接带宽，这意味着图像质量会因网络速度降低而变差,以减少对传输带宽的需求。“实时”的概念是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系。

　　在Internet中使用流式传输技术的连续时基媒体就称为流媒体，通常也将其视频与音频称为视频流和音频流。实现流式传输一般都需要专用服务器和播放器。

2.2 流媒体系统组件

　　流媒体是由各种不同软件构成的，这些软件在各个不同层面上互相通信，基本的流媒体系统包含以下3个组件：

播放器（Player），用来播放流媒体的软件。

服务器（Server），用来向用户发送流媒体的软件。

编码器（Encode），用来将原始的音频视频转化为流媒体格式的软件。

　　这些组件之间通过特定的协议互相通信，按照特定的格式互相交换文件数据。有些文件中包含了由特定编解码器解码的数据，这种编解码器通过特定算法压缩文件的数据量。

3 流媒体服务器的基本功能和服务方式

3.1 流媒体服务器的主要功能

（1）响应客户的请求，把媒体数据传送给客户。流媒体服务器在流媒体传送期间必须与客户的播放器保持双向通信（这种通信是必需的，因为客户可能随时暂停或快放一个文件）。

（2）响应广播的同时能够及时处理新接收的实时广播数据，并将其编码。

（3）可提供其他额外功能，如：数字权限管理（DRM），插播广告，分割或镜像其他服务器的流，还有组播。

3.2 流媒体服务器的服务方式

（1）单播。在客户端与媒体服务器之间建立一个单独的数据通道，从1台服务器送出的每个数据包只能传送给1个客户机。

（2）组播。在以组播技术构建的网络上，允许路由器一次将数据包复制到多个通道上。

（3）点播与广播。点播连接是客户端与服务器之间的主动的连接，在点播连接中，用户通过选择内容项目来初始化客户端连接，用户可以开始、停止、后退、快进或暂停流。广播指的是用户被动地接收流，在广播过程中，数据包的单独一个拷贝将发送给网络上的所有用户，客户端接收流，但不能控制流。

4 构建流媒体服务器

4.1 RTP/RTCP协议简介

　　实时传输协议RTP（Realtime Transport Protocol）：是针对Internet上多媒体数据流的一个传输协议, 由IETF(Internet工程任务组)作为RFC1889发布。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP或ATM等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。

　　实时传输控制协议RTCP（Realtime Transport Control Protocol）：负责管理传输质量在当前应用进程之间交换控制信息。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。

　　RTCP主要有4个功能:

（1）用反馈信息的方法来提供分配数据的传送质量，这种反馈可以用来进行流量的拥塞控制，也可以用来监视网络和用来诊断网络中的问题；

（2）为RTP源提供一个永久性的CNAME（规范性名字）的传送层标志，因为在发现冲突或者程序更新重启时SSRC(同步源标识)会变，需要一个运作痕迹，在一组相关的会话中接收方也要用CNAME来从一个指定的与会者得到相联系的数据流（如音频和视频）；

（3）根据与会者的数量来调整RTCP包的发送率；

（4）传送会话控制信息，如可在用户接口显示与会者的标识，这是可选功能。

4.2 RTP/RTCP工作过程

　　工作时，RTP协议从上层接收流媒体信息码流（如H.263），装配成RTP数据包发送给下层，下层协议提供RTP和RTCP的分流。如在UDP中，RTP使用一个偶数号端口，则相应的RTCP使用其后的奇数号端口。RTP数据包没有长度限制，它的最大包长只受下层协议的限制。

4.3 服务器的算法

　　服务器软件模型主要有两种，即并发服务器和循环服务器。循环服务器(Iterative Server)是指在一个时刻只处理一个请求的服务器。并发服务器(Concurrent Server)是指在一个时刻可以处理多个请求的服务器。事实上，多数服务器没有用于同时处理多个请求的冗余设备，而是提供一种表面上的并发性，方法是依靠执行多个线程，每个线程处理一个请求，从客户的角度看，服务器就像在并发地与多个客户通信。

　　由于流媒体服务时间的不定性和数据交互实时性的请求，流媒体服务器一般采用并发服务器算法。本文构建了一个基本的流媒体服务器，能够同时响应多个用户的请求，把本地硬盘流媒体文件或实时数据流（H.263格式）发送给用户。在应用中，把客户分为请求实时数据的实时客户和请求文件数据的文件客户两类。主要算法为：

（1）打开设备，分配资源。当设备准备好时，创建一个RTP实时服务线程和一个RTCP实时服务线程。

（2）创建一个UDP套接字并将其绑定到所提供服务的地址之上。

（3）反复调用接收模块，接收来自客户的RTCP报告，根据其类型做出响应。对新实时客户的请求，把客户地址添加到实时服务的客户列表中，对新文件客户的请求，则创建一个新RTP文件服务线程和一个新RTCP文件服务线程；对已经在服务中的客户则根据RTCP报告的内容调整服务。

RTP实时服务线程1：初始化客户列表和RTP首部。

RTP实时服务线程2：从设备读取媒体数据，把数据发送给实时服务列表中的客户。

RTP实时服务线程3：更新RTP首部和统计数据。

RTP实时服务线程4：计算延时，重复第二步。

RTCP实时服务线程1：初始化RTCP首部。

RTCP实时服务线程2：发送发送方报告给实时服务列表中的客户。

RTCP实时服务线程3：计算延时，重复第二步。

RTP文件服务线程1：初始化RTP首部。

RTP文件服务线程2.：从文件读取媒体数据，把数据发送给客户。

RTP文件服务线程3：更新已发送数据的统计信息，为生成发送方报告做准备。

RTP文件服务线程4：计算延时，调整发送速度，正常情况下开始重复第二步。

RTCP文件服务线程1：初始化RTCP首部，发送一个源描述(SDES)报文给客户。

RTCP文件服务线程2：根据已发送数据的统计信息生成发送方报告，发送给客户。

RTCP文件服务线程3：计算延时，正常情况下开始重复第一步。

5 流媒体服务器实现中应注意的问题

5.1 会话和流的两级分用

　　一个RTP会话(Session)包括传给某个指定目的地对(Destination Pair)的所有通信量，发送方可能包括多个。而从同一个同步源发出的RTP分组序列称为流(Stream),一个RTP会话可能包含多个RTP流。一个RTP分组在服务器端发送出去的时候总是要指定属于哪个会话和流，在接收时也需要进行两级分用，即会话分用和流分用。只有当RTP使用同步源标识(SSRC)和分组类型(PTYPE)把同一个流中的分组组合起来，才能够使用序列号(Sequence Number)和时间戳(Timestamp)对分组进行排序和正确回放。

5.2 多线程的管理

　　并发服务器模式要求用多线程来提供服务，所以多线程的管理十分重要。在本文构建的服务器中，不同客户的请求和反馈都由服务器的主线程处理，由于实时数据的独有性，不同实时客户可以共用一个RTP实时服务线程和一个RTCP实时服务线程，这样可以大大减小服务器的负担，而每个文件客户由于请求的文件不同，相应地对速度和开始时间的要求都可能不同，所以需要有自己独有的RTP文件服务线程和RTCP文件服务线程。

　　RTP服务线程负责把实时数据流发送给客户，RTCP服务线程根据RTP线程的统计数据，产生发送方报告给客户。RTP线程和RTCP线程之间通过一段共享内存交互统计数据，对共享内存必须设置互斥体进行保护，防止出现错误读写。在这种方式下，服务器可以根据每个用户的不同请求和具体情况方便地提供不同的服务。

5.3 时间戳的处理

　　时间戳字段是RTP首部中说明数据包时间的同步信息，是数据能以正确的时间顺序恢复的关键。时间戳的值给出了分组中数据的第一个字节的采样时间(Sampling Instant)，要求发送方时间戳的时钟是连续、单调增长的，即使在没有数据输入或发送数据时也是如此。在静默时，发送方不必发送数据，保持时间戳的增长，在接收端，由于接收到的数据分组的序号没有丢失，就知道没有发生数据丢失，而且只要比较前后分组的时间戳的差异，就可以确定输出的时间间隔。

　　RTP规定一次会话的初始时间戳必须随机选择，但协议没有规定时间戳的单位，也没有规定该值的精确解释，而是由负载类型来确定时钟的颗粒，这样各种应用类型可以根据需要选择合适的输出计时精度。

在RTP传输音频数据时，一般选定逻辑时间戳速率与采样速率相同，但是在传输视频数据时，必须使时间戳速率大于每帧的一个滴答。如果数据是在同一时刻采样的，协议标准还允许多个分组具有相同的时间戳值。

5.4 媒体数据发送速度的控制

　　由于RTP协议没有规定RTP分组的长度和发送数据的速度，因而需要根据具体情况调整服务器端发送媒体数据的速度。对来自设备的实时数据可以采取等时间间隔访问设备缓冲区，在有新数据输入时发送数据的方式，时间戳的设置相对容易。对已经录制好的本地硬盘上的媒体文件，以H.263格式的文件为例，由于文件本身不包含帧率信息，所以需要知道录制时的帧率或者设置一个初始值，在发送数据的时候找出发送数据中的帧数目，根据帧率和预置值来计算时延，以适当的速度发送数据并设置时间戳信息。

5.5 多种流同步

　　RTCP的一个关键作用就是能让接收方同步多个RTP流，例如：当音频与视频一起传输的时候，由于编码的不同，RTP使用两个流分别进行传输，这样两个流的时间戳以不同的速率运行，接收方必须同步两个流，以保证声音与影像的一致。为能进行流同步，RTCP要求发送方给每个传送一个唯一的标识数据源的规范名(Canonical Name），尽管由一个数据源发出的不同的流具有不同的同步源标识(SSRC)，但具有相同的规范名，这样接收方就知道哪些流是有关联的。而发送方报告报文所包含的信息可被接收方用于协调两个流中的时间戳值。发送方报告中含有一个以网络时间协议NTP(Network Time Protocol)格式表示的绝对时间值，接着RTCP报告中给出一个RTP时间戳值，产生该值的时钟就是产生RTP分组中的TimeStamp字段的那个时钟。由于发送方发出的所有流和发送方报告都使用同一个绝对时钟，接收方就可以比较来自同一数据源的两个流的绝对时间，从而确定如何将一个流中的时间戳值映射为另一个流中的时间戳值。

6 结论

　　流媒体技术的应用日益广泛，对流媒体技术的研究具有很大的实际意义,本文通过对RTP/RTCP协议的研究，分析流媒体服务器的一般功能和结构，给出构建一个基本的流媒体服务器的实现方案，实验证明可以同时满足多个实时和文件客户的要求,并已经应用于一个远程监控系统中。