RTP实时传输协议,实时传输协议RTP的功能

('RTP实时传输协议(来自:小龙文档网:rtp-实时传输协议)篇一：RTPRTCP实时传输协议实现课程设计RTP-RTCP实时传输协议实现课程设计RTP-RTCP实时传输协议实现一、设计目的和意义了解实时传输协议RTP和实时传输控制协议RTCP的基本原理；学习使用RTP数据报发送实时数据，并接收重组；学习实时数据传输控制基本方法；了解媒体内同步和媒体间同步的基本概念。二、设计原理1、基本概念RTP全名是Real-timeTransportProtocol（实时传输协议）。RTCP全名是Real-timeTransportControlProtocol，即实时传输控制协议。RTP定义在RFC1889中，是一种提供端对端传输服务的实时传输协议，用来支持网络服务中传输实时数据。RTCP用来监视服务质量和传送有关与会者的信息，主要功能是为应用程序提供会话质量或者广播性能质量的信息。多媒体网络通常把RTCP和RTP一起使用。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP的典型应用建立在UDP上，但也可以在TCP或ATM等其他协议之上工作。RTP为Internet上端到端的实时传输提供时间信息和流同步，但并不保证服务质量，服务质量由RTCP来提供。RTCP负责管理传输质量在当前应用进程之间交换控制信息。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。2、RTP工作机制威胁多媒体数据传输的一个尖锐的问题就是不可预料数据到达时间。但是流媒体的传输是需要数据的适时的到达用以播放和回放。RTP协议就是提供了时间标签,序列号以及其它的结构””用于控制适时数据的流放。在流的概念中时间标签是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后,就依照时间标签按照正确的速率恢复成原始的适时的数据。不同的媒体格式调时属性是不一样的。但是RTP本身并不负责同步，RTP只是传输层协议，为了简化运输层处理，提高该层的效率。将部分运输层协议功能（比如流量控制）上移到应用层完成。同步就是属于应用层协议完成的。它没有运输层协议的完整功能，不提供任何机制来保证实时地传输数据，不支持资源预留，也不保证服务质量。RTP报文甚至不包括长度和报文边界的描述。同时RTP协议的数据报文和控制报文的使用相邻的不同端口，这样大大提高了协议的灵活性和处理的简单性。RTP协议和UDP二者共同完成运输层协议功能。UDP协议只是传输数据包，不管数据包传输的时间顺序。RTP的协议数据单元是用UDP分组来承载的。在承载RTP数据包的时候，有时候一帧数据被分割成几个包具有相同的时间标签，则可以知道时间标签并不是必须的。而UDP的多路复用让RTP协议利用支持显式的多点投递，可以满足多媒体会话的需求。RTP协议虽然是传输层协议但是它没有作为OSI体系结构中单独的一层来实现。RTP协议通常根据一个具体的应用来提供服务，RTP只提供协议框架，开发者可以根据应用的具体要求对协议进行充分的扩展。3、RTCP工作机制当应用程序开始一个RTP会话时将使用两个端口：一个给RTP，一个给RTCP。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。在RTP的会话之间周期的发放一些RTCP包以用来传监听服务质量和交换会话用户信息等功能。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。根据用户间的数据传输反馈信息，可以制定流量控制的策略，而会话用户信息的交互，可以制定会话控制的策略。RTCP主要有4个功能:用反馈信息的方法来提供分配数据的传送质量，这种反馈可以用来进行流量的拥塞控制，也可以用来监视网络和用来诊断网络中的问题；为RTP源提供一个永久性的CNAME（规范性名字）的传送层标志，因为在发现冲突或者程序更新重启时SSRC(同步源标识)会变，需要一个运作痕迹，在一组相关的会话中接收方也要用CNAME来从一个指定的与会者得到相联系的数据流（如音频和视频）；根据与会者的数量来调整RTCP包的发送率；传送会话控制信息，如可在用户接口显示与会者的标识，这是可选功能。4、RTP的协议层次RTP（实时传输协议），顾名思义它是用来提供实时传输的，因而可以看成是传输层的一个子层。RTP被划分在传输层，它建立在UDP上。同UDP协议一样，为了实现其实时传输功能，RTP也有固定的封装形式。RTP用来为端到端的实时传输提供时间信息和流同步，但并不保证服务质量。服务质量由RTCP来提供。不少人也把RTP归为应用层的一部分，这是从应用开发者的角度来说的。操作系统中的TCP/IP等协议栈所提供的是我们最常用的服务，而RTP的实现还是要靠开发者自己。因此从开发的角度来说，RTP的实现和应用层协议的实现没不同，所以可将RTP看成应用层协议。5、RTP的会话过程当应用程序建立一个RTP会话时，应用程序将确定一对目的传输地址。目的传输地址由一个网络地址和一对端口组成，有两个端口：一个给RTP包，一个给RTCP包，使得RTP/RTCP数据能够正确发送。RTP数据发向偶数的UDP端口，而对应的控制信号RTCP数据发向相邻的奇数UDP端口（偶数的UDP端口＋1），这样就构成一个UDP端口对。RTP的发送过程如下，接收过程则相反。1)RTP协议从上层接收流媒体信息码流（如H.263），封装成RTP数据包；RTCP从上层接收控制信息，封装成RTCP控制包。2)RTP将RTP数据包发往UDP端口对中偶数端口；RTCP将RTCP控制包发往UDP端口对中的接收端口。6、RTP的封装一个协议的封装是为了满足协议的功能需求的。从前面提出的功能需求，可以推测出RTP封装中应该有同步源和时戳等字段，但更为完整的封装是什么样子呢？请看图1。VPXCCMPT序列号时戳同步信源(SSRC)标识符特约信源(CSRC)标识符图1RTP的头部格式版本号（V）：2比特，用来标志使用的RTP版本。填充位（P）：1比特，如果该位置位，则该RTP包的尾部就包含附加的填充字节。扩展位（X）：1比特，如果该位置位的话，RTP固定头部后面就跟有一个扩展头部。CSRC计数器（CC）：4比特，含有固定头部后面跟着的CSRC的数目。标记位（M）：1比特,该位的解释由配置文档（Profile）来承担.载荷类型（PT）：7比特，标识了RTP载荷的类型。序列号（SN）：16比特，发送方在每发送完一个RTP包后就将该域的值增加1，接收方可以由该域检测包的丢失及恢复包序列。序列号的初始值是随机的。时间戳：32比特，记录了该包中数据的第一个字节的采样时刻。在一次会话开始时，时间戳初始化成一个初始值。即使在没有信号发送时，时间戳的数值也要随时间而不断地增加（时间在流逝嘛）。时间戳是去除抖动和实现同步不可缺少的。同步源标识符(SSRC)：32比特，同步源就是指RTP包流的来源。在同一个RTP会话中不能有两个相同的SSRC值。该标识符是随机选取的RFC1889推荐了MD5随机算法。贡献源列表（CSRCList）：0～15项，每项32比特，用来标志对一个RTP混合器产生的新包有贡献的所有RTP包的源。由混合器将这些有贡献的SSRC标识符插入表中。SSRC标识符都被列出来，以便接收端能正确指出交谈双方的身份。7、RTCP的封装RTCP的主要功能是：服务质量的监视与反馈、媒体间的同步，以及多播组中成员的标识。在RTP会话期间，各参与者周期性地传送RTCP包。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，各参与者可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。RTCP也是用UDP来传送的，但RTCP封装的仅仅是一些控制信息，因而分组很短，所以可以将多个RTCP分组封装在一个UDP包中。RTCP有如下五种分组。表1RTCP的5种分组类型类型缩写表示用途200SR（SenderReport）发送端报告201RR(ReceiverReport)接收端报告202SDES(SourceDescriptionItems)源点描述203BYE结束传输204特定应用8、RTP协议传输数据流的收发程序流程图发送接收获得接收端的IP地址和端口号获得用户指定的端口号创建RTP会话创建RTP会话指定RTP数据接收端设置接收模式设置RTP会话默认参数接受RTP数据发送流媒体数据检索RTP数据源获取RTP数据报删除RTP数据报图3RTP协议传输数据流的收发程序流程图三、详细设计步骤1、环境搭建通过RTP协议传输数据流的收发程序，进行实时流媒体数据传输，需要使用JRTPLIB。JRTPLIB是一个用C++语言实现的RTP库，目前已经可以运行在Windows、Linux、FreeBSD、Solaris、Unix和VxWorks等多种操作系统上。先要将JRTPLIB库在windows系统下进行编译，之后编译的RTP协议传输数据流的收发源程序，就可运行了。2、初始化在使用JRTPLIB进行实时流媒体数据传输之前，首先应该生成RTPSession类的一个实例来表示此次RTP会话，然后调用Create()方法来对其进行初始化操作。RTPSession类的Create()方法只有一个参数，用来指明此次RTP会话所采用的端口号。3、数据发送当RTP会话成功建立起来之后，接下来就可以开始进行流媒体数据的实时传输了。首先需要设置好数据发送的目标地址，RTP协议允许同一会话存在多个目标地址，这可以通过调用RTPSession类的AddDestination()、DeleteDestination()和ClearDestinations()方法来完成。目标地址全部指定之后，接着就可以调用RTPSession类的SendPacket()方法，向所有的目标地址发送流媒体数据。SendPacket()最典型的用法是类似于下面的语句，其中第一个参数是要被发送的数据，而第二个参数则指明将要发送数据的长度，再往后依次是RTP负载类型、标识和时戳增量。例如：sess.SendPacket(buffer,5,0,false,10);对于同一个RTP会话来讲，负载类型、标识和时戳增量通常来讲都是相同的，JRTPLIB允许将它们设置为会话的默认参数，这是通过调用RTPSession类的SetDefaultPayloadType()、SetDefaultMark()等方法来完成的。为RTP会话设置这些默认参数的好处是可以简化数据的发送。例如，如果为RTP会话设置了默认参数：sess.SetDefaultPayloadType(0);sess.SetDefaultMark(false);sess.SetDefaultTimeStampIncrement(10);之后在进行数据发送时只需指明要发送的数据及其长度就可以了。例如：sess.SendPacket(buffer,5);4、数据接收对于流媒体数据的接收端，首先需要调用PollData()方法来接收发送过来的RTP或者RTCP数据报。由于同一个RTP会话中允许有多个参与者（源），因此既可以通过调用GotoFirstSource()和GotoNextSource()方法来遍历所有的源，也可以通过调用GotoFisstSourceWithDat()和GotoNextSourceWithData()方法来遍历那些携带有数据的源。在从RTP会话中检测出有效的数据源之后，接下去就可以调用RTPSession类的GetNextPacket()方法从中抽取RTP数据报，当接收到的RTP数据报处理完之后，要及时释放。下面的代码示范了该如何对接收到的RTP数据报进行处理：do{sess.BeginDataAccess();if(sess.GotoFirstSourceWithData()){do{RTPPacketpack;uint8_tdata;size_tlength;if((out("/mnt/hgfs/download/temp1.YUV",O_WRONLYO_CREATO_END))<0){perror("openout");篇二：实时传输(RTP)实时传输1、RTP的包头M标志位：标志的解释由具体协议规定。它用来允许在比特流中标记重要的事件，如帧边界。由于一个视频采样压缩之后仍然有可能相当巨大，可能超出预先约定规定的RTP数据报大小，这个时候就需要拆分数据报了。但是由于这些数据报都属于同一个整个视频采样，因此这些数据报的时间戳应该是一致的。此外，Mark标志用来作为区分这些拆分数据报和普通数据报的分界线。只有当受到Mark标志的多个数据报都到达了才能构成一个完整的数据帧提交解码器。SSRC：同步源标识。序列号：每发送一个RTP数据包，序列号加1，接收端可以据此检测丢包和重建包序列。CSRC：只有当混频器加入时才有此项。可不考虑。设置恰当的时戳单元：这是RTP会话初始化过程所要进行的另外一项重要工作，这是通过调用RTPSession类的SetTimestampUnit()方法来实现的，该方法同样也只有一个参数，表示的是以秒为单元的时戳单元。例如，当使用RTP会话传输8000Hz采样的音频数据时，由于时戳每秒钟将递增8000，所以时戳单元相应地应该被设置成1/8000，可以用以下代码来实现Sessionparams.SetOwnTimestampUnit(1.0/8000)。30帧/秒的视频SetOwnTimestampUnit(1.0/30)；如果RTP包是周期性产生的，那么将使用由采样时钟决定的名义上的采样时刻，而不是读取系统时间。例如，对一个固定速率的音频，采样时钟将在每个周期内增加1。如果一个音频从输入设备中读取含有160个采样周期的块，那么对每个块，时间戳的值增加160。也就是时间戳增量如上8000Hz的音频，如果每个包含有20ms的时间（就是160个采样），则需要session.SetDefaultTimestampIncrement(160)。另外不同媒体流的RTP时间戳可能以不同的速率增长。而且会有独立的随机偏移量。因此，虽然这些时间戳足以重构一个单独的流的时间，但直接比较不同的媒体流的时间戳不能进行同步。对于每一个媒体，我们把与采样时刻相关联的RTP时间戳与来自于参考时钟上的时间戳（NTP）相关联。因此参考时钟的时间戳就了数据的采样时间。（即：RTP时间戳可用来实现不同媒体流的同步，NTP时间戳解决了RTP时间戳有随机偏移量的问题。）参考时钟用于同步所有媒体的共同时间。这一时间戳对（RTP时间戳和NTP时间戳），用于判断RTP时间戳和NTP时间戳的对应关系，以进行媒体流的同步。它们不是在每一个数据包中都被发送，而在发送速率更低的RTCP的SR（发送者报告）中。RTP中时间戳的作用：?调整语序时间戳字段是RTP首部中说明数据包时间的同步信息，是数据能以正确的时间顺序恢复的关键。时间戳的值给出了分组中数据的第一个字节的采样时间(SamplingInstant)，要求发送方时间戳的时钟是连续、单调增长的，即使在没有数据输入或发送数据时也是如此。在静默时，发送方不必发送数据，保持时间戳的增长，在接收端，由于接收到的数据分组的序号没有丢失，就知道没有发生数据丢失，而且只要比较前后分组的时间戳的差异，就可以确定输出的时间间隔。RTP规定一次会话的初始时间戳必须随机选择，但协议没有规定时间戳的单位，也没有规定该值的精确解释，而是由负载类型来确定时钟的颗粒，这样各种应用类型可以根据需要选择合适的输出计时精度。在RTP传输音频数据时，一般选定逻辑时间戳速率与采样速率相同，但是在传输视频数据时，必须使时间戳速率大于每帧的一个滴答。如果数据是在同一时刻采样的，协议标准还允许多个分组具有相同的时间戳值。?控制媒体数据发送速度由于RTP协议没有规定RTP分组的长度和发送数据的速度，因而需要根据具体情况调整服务器端发送媒体数据的速度。对来自设备的实时数据可以采取等时间间隔访问设备缓冲区，在有新数据输入时发送数据的方式，时间戳的设置相对容易。对已经录制好的本地硬盘上的媒体文件，以H.263格式的文件为例，由于文件本身不包含帧率信息，所以需要知道录制时的帧率或者设置一个初始值，在发送数据的时候找出发送数据中的帧数目，根据帧率和预置值来计算时延，以适当的速度发送数据并设置时间戳信息。?调整多种流同步RTCP的一个关键作用就是能让接收方同步多个RTP流，例如：当音频与视频一起传输的时候，由于编码的不同，RTP使用两个流分别进行传输，这样两个流的时间戳以不同的速率运行，接收方必须同步两个流，以保证声音与影像的一致。为能进行流同步，RTCP要求发送方给每个传送一个唯一的标识数据源的规范名(CanonicalName），尽管由一个数据源发出的不同的流具有不同的同步源标识(SSRC)，但具有相同的规范名，这样接收方就知道哪些流是有关联的。而发送方报告报文所包含的信息可被接收方用于协调两个流中的时间戳值。发送方报告中含有一个以网络时间协议NTP(NetworkTimeProtocol)格式表示的绝对时间值，接着RTCP报告中给出一个RTP时间戳值，产生该值的时钟就是产生RTP分组中的TimeStamp字段的那个时钟。由于发送方发出的所有流和发送方报告都使用同一个绝对时钟，接收方就可以比较来自同一数据源的两个流的绝对时间，从而确定如何将一个流中的时间戳值映射为另一个流中的时间戳值。RTP时戳设置为内容的采样时戳。必须使用90kHz时钟频率。如果NAL单元没有他自己的时间属性(即,parametersetandSEINALunits),RTP时戳设置成访问单元主编码图像的RTP时戳。负载格式:对于负载格式规范文件，定义了特定类型的负载，比如用H.264压缩的视频文件如何用RTP包来传送。需要参考RFC3984协议（RTPpayloadFormatforH.264Video）在这个文件中，下列选项可能会被重新定义：?RTPdataheader?Payloadtypes?RTPdataheaderadditions?RTPdataheaderextensions?RTCPpackettypes?RTCPreportinterval?SR/RRextension?SDESuse?Security?String-to-keymapping?Underlyingprotocol?Transportmapping?Encapsulation可以通过RTPPacket类和RTCPPacket类进行这些修改。为了通过RTP进行H.264视频传输，需要把H.264视频数据根据规范封装成数据包。根据RTP封装规范，我们采用简单的打包方案，即将每个NALU（包括同时作为载荷头标的NALU头）单独封装成一个RTP包。发送端按照RTP数据包的格式放入数据，并且配置RTP包头的负载类型、序列号、时间戳等参数。形成一个完整的RTP数据包。通过网络发送给接收端。实现端到端的视频流传输。接收端收到RTP包以后，取出包里的NAL单元送给解码器进行解码播放。RFC3984中的规范：单个NAL单元包单个NAL单元包:荷载中只包含一个NAL单元。NAL头类型域等于原始NAL单元类型,即在范围1到23之间。分片单元:用于分片单个NAL单元到多个RTP包。现存两个版本FU-A，FU-B,用NAL单元类型28，29标识。其中NAL单元字节头（包头）格式：篇三：RTP实事传送协议RTP●实时传送协议（Real-timeTransportProtocol或简写RTP）是一个网络传输协议，它是由IETF的多媒体传输工作小组1996年在RFC1889中公布的。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议，但后来被用在很多单播应用中。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通（PushtoTalk）系统（配合H.323或SIP），使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是建立在用户数据报协议上的。它作为因特网标准在RFC3550（该文档的旧版本是RFC1889）有详细说明。RFC3551（STD65，旧版本是RFC1890）详细描述了使用最小控制的音频和视频会议。RTP本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。RTP并不保证传送或防止无序传送，也不确定底层网络的可靠性。RTP实行有序传送，RTP中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。RTP由两个紧密链接部分组成：RTP―传送具有实时属性的数据；RTP控制协议（RTCP―）监控服务质量并传送正在进行的会话参与者的相关信息。RTCP“第二方面的功能对于松散受”控会话是足够的，也就是说，在没有明确的成员控制和组织的情况下，它并不非得用来支持一个应用程序的所有控制通信请求。协议结构1238916bitVPXCSRCCountMPayloadTypeSequencenumberTimestampSSRCCSRC(variable0–15items32bitseach)V―版本。识别RTP版本。P―间隙（Padding）。设置时，数据包包含一个或多个附加间隙位组，其中这部分不属于有效载荷。X―扩展位。设置时，在固定头后面，根据指定格式设置一个扩展头。CSRCCount―包含CSRC标识符（在固定头后）的编号。M―标记。标记由Profile文件定义。允许重要事件如帧边界在数据包流中进行标记。PayloadType―识别RTP有效载荷的格式，并通过应用程序决定其解释。Profile文件规定了从Payload编码到Payload格式的缺省静态映射。另外的PayloadType编码可能通过非RTP方法实现动态定义。SequenceNumber―每发送一个RTP数据包，序列号增加1。接收方可以依次检测数据包的丢失并恢复数据包序列。Timestamp―反映RTP数据包中的第一个八位组的采样时间。采样时间必须通过时钟及时提供线性无变化增量获取，以支持同步和抖动计算。SSRC―同步源。该标识符随机选择，旨在确保在同一个RTP会话中不存在两个同步源具有相同的SSRC标识符。CSRC―贡献源标识符。识别该数据包中的有效载荷的贡献源。可靠传输协议ReliableTransportProtocol-----RTP',)