基于SIP的移动多媒体通信系统 ——基于RTP的媒体数据的网络传输-毕业论文

本科毕业论文(科研训练、毕业设计)题 目：基于SIP的移动多媒体通信系统基于RTP的媒体数据的网络传输姓 名：学 院：软件学院系：软件工程专 业：软件工程年 级：学 号：指导教师（校内）： 职称： 指导教师（校外）： 职称： 年 月I基于SIP的移动多媒体通信系统基于RTP的媒体数据的网络传输摘要 SIP（Session Initiation Protocol，会话初始化协议）是由IETF提出的IP电话信令协议。SIP用于发起会话，它能控制多个参与者参加的多媒体会话的建立和终结，并能动态调整和修改会话属性。RTP（Real-time Transport Protocol，实时传输协议）是由IETF开发的用于音频、视频等多媒体数据实时传输的协议，可以在面向连接或无连接的下层协议上工作，通常和UDP协议一起使用。随着网络的迅速发展，传统的TCP/ IP 协议在流媒体(音频流、视频流) 的实时传输上受到了很大的挑战，因为该协议在网络上提供的是非实时的数据传输服务，并且其重传机制与拥塞控制机制也给实时传输带来较大困难。而UDP虽然具有实时性，但UDP缺乏丢包汇报机制，所以UDP也不适合于流媒体的实时传输。为了解决该问题，支持多媒体实时传输的RTP协议被提出来了。本文首先对本次毕设项目动中通系统进行了介绍，并对该系统的架构进行了说明，之后，简要说明了系统中所选用的三个技术的概念，从而引入并介绍RTP协议。本文第二章介绍了RTP协议的概念、组成（RTP/RTCP）以及该协议在网络结构层中的位置。接着，本文介绍了RTP协议适合于实时流媒体传输的特性以及在整个实时流媒体传输过程中RTCP协议的各种功能。之后，本文从理论上详细地介绍了RTP报文和5种不同类型的RTCP报文（SR、RR、SDES、BYE和APP）的格式以及各报文中各个模块的大小与功能。接着，为了将理论与实际联系起来，在程序上方便地实现RTP/RTCP协议，本文引入了一个用C+编写实现的高度封装的面向对象的RTP库JRTPLIB。首先，本文对JRTPLIB进行了简单的介绍，接着，本文介绍了JRTPLIB在Microsoft Visual Studio 2005 C+环境下的使用配置，再接下来，本文根据JRTPLIB的使用流程，对JRTPLIB中常用到的重要的几个函数作出了详细的解释。最后，本文提出了JRTPLIB在本次毕设中的实际运用，并根据实际情况将了RTP模块划分为四个功能模块，同时，对这四个功能模块划分的设计与实现进行了详细研究。关键词 RTP/RTCP协议 网络实时传输 JRTPLIBSatellite Communication in Motion System based on SIPNetwork Transmission of Media Data based on RTPAbstract SIP（Session Initiation Protocol） is an IP-Telephony signal protocol proposed by IETF. SIP is applied to initiate a session, it can set up or terminate a multimedia session attended by multi actors, and it can also amend the properties of session dynamically.RTP (Real-time Transport Protocol) is applied to transport the multimedia data, like the video or the audio, in real time. And it is proposed by IETF, too. The RTP can run on the connection-oriented or connectionless-oriented under-layer protocol, and usually, the RTP and the UDP are used together.Because of the rapid network development, the traditional TCP/IP protocol is faced with great challenge in the real time stream transmission. Because TCP/IP protocol supports no-real time data transmission and its policy of re-sending and congestion control has brought much difficulty to the real-time transmission. And about the UDP protocol, it does possess real-time property, but it lacks of control of reporting while losing packets, so it does not suit the real time stream transmission. To solve this problem, RTP protocol, which supports real time transmission, is brought forward.First of all, paper introduces the system named DongZhongTong(DZT) and the framework of the system. And then the three techniques refer to the system are introduced briefly. And, at the same time, the RTP protocol is imported.And then, paper introduces the concept of the RTP, the form of the RTP (RTP/RTCP) and the station of the protocol in internet structure in chapter 2 of this paper. And then, this paper introduces the characteristic of the RTP protocol which suits to the real time stream transmission and all kinds of functions that the RTCP protocol will make, during the whole real time stream transmission. After that, the paper abstractly introduces the formats of the RTP packet and 5 different kinds of RTCP packets (SR, RR, SDES, BYE and APP) in detail, as well as the length and the function of every module in each packet. To integrate theory with practice, and implement the RTP/RTCP protocol conveniently in program, the paper introduce an object oriented RTP library JRTPLIB, which implements with C+ and is extremely wrapped. First, the paper introduces the JRTPLIB simply, and then, the paper shows the configuration of JRTPLIB in Microsoft Visual Studio 2005 C+, and after that, according to the process of make use of JRTPLIB, the paper introduces some functions which are important and in common used. At last, the paper provides an example which makes use of JRTPLIB (the codes are in the addendum), and shows more about the using of JRTPLIB.At last, this paper shows the practical applications of JRTPLIB in the DZT system, and partitions the RTP module into four function modules according to the real situation. At the same time, the paper make a detailedly research on designing and implement the four modules partitioned from the RTP module.Keywords RTP/RTCP protocol network real-time transmission JRTPLIBXI目 录第一章引言81.1系统简介81.2系统架构81.3系统技术简介91.3.1SIP协议简介91.3.2DirectShow简介101.3.3RTP简介10第二章RTP协议简介112.1RTP协议的概念112.2RTP协议的组成112.3RTP协议的特性122.4RTCP 协议可以完成的功能122.5RTP与RTCP报文的格式132.5.1RTP报文格式132.5.2RTCP报文格式17第三章JRTPLIB介绍与使用253.1JRTPLIB介绍253.2JRTPLIB环境配置253.3JRTPLIB的使用263.3.1程序的初始化263.3.2关于RTPSession的初始化与设置273.3.3数据的发送283.3.4数据的接收293.3.5RTP出错检测30第四章移动多媒体通信系统RTP模块设计324.1系统模块之间的关系324.2RTP模块中的接口函数的功能324.2.1初始化模块334.2.2发送信息模块334.2.3接收信息模块354.2.4退出模块374.3小结37总结38致谢39参考文献40附 录41ContentsChapter 1 Introduction81.1System introduction81.2System construction81.3Introduce the techniques used in the system91.3.1Introduction of SIP protocol 91.3.2Introduction of DirectShow 101.3.3Introduction of RTP protocol10Charpter 2 Introduction of RTP protocol112.1Conception of the RTP protocol112.2The form of the RTP protocol112.3Characteristic of the RTP protocol122.4Functions of RTCP protocol122.5Formats of the RTP/RTCP packets132.5.1Formats of the RTP packet132.5.2Formats of the RTCP packets17Chapter 3 Introduction of JRTPLIB253.1Introduction of JRTPLIB253.2Configuration of JRTPLIB253.3How to use JRTPLIB263.3.1Initializtion of program263.3.2Initializtion and settings of RTPSession273.3.3Sending packets283.3.4Receiving packets293.3.5Error detected30Charpter 4 RTP model designing in satellite communication in motion System324.1Connection of partitions in the system324.2Functions of interface in RTP partition324.2.1Partition of initialization334.2.2Partition of sending message334.2.3Partition of receiving message354.2.4Partition of exit374.3Summary37Summary38Acknowledgement39References40Supplement41 基于SIP的移动多媒体通信系统基于RTP的媒体数据的网络传输第一章 引言1.1 系统简介本次毕设所做的系统叫动中通系统。动中通系统是一种将电话、视频监控、对讲机、音频广播、会议和文本信息等功能集成到一种比手机稍大的移动平台上的系统。这种系统可以实现一机多用，减轻户外工作人员的装备负担，减少经费开支，提供更加强大、安全、可靠的通信方式。同时提供可运行在普通个人电脑上的控制台，为管理人员提供丰富的扩展功能。1.2 系统架构本系统的架构如图1-1图1-1 系统架构图在本系统中，各种管理和调度功能组成软件的内核部分，相当于操作系统的内核。业务构建在内核之上，承担具体的业务逻辑，相当于运行在操作系统上的各种应用程序。业务所描述的逻辑最终需要通过多种技术的配合实现出来。复杂多变的技术通过技术抽象层向内核提供固定不变的访问接口。1.3 系统技术简介本系统涉及的技术主要有控制、媒体和传输三部分，当前选择的技术依次为SIP，DirectShow和RTP。1.3.1 SIP协议简介SIP（Session Initiation Protocol，会话初始化协议）是由IETF（Interne工程任务组）提出的IP电话信令协议1。它的主要目的是为了解决IP网中的信令控制，以及同SoftSwitch 的通信，从而构成下一代的增值业务平台，对电信，银行，金融等行业提供更好的增值业务。正如其名字所隐含的，SIP用于发起会话，它能控制多个参与者参加的多媒体会话的建立和终结，并能动态调整和修改会话属性，如会话带宽要求、传输的媒体类型（语音、视频和数据等）、媒体的编解码格式、对组播和单播的支持等。SIP在设计上充分考虑了对其他协议的扩展适应性。它支持许多种地址描述和寻址，包括：用户名主机地址、被叫号码PSTN网关地址和如Tel样普通电话号码的描述等。这样，SIP主叫按照被叫地址，就可以识别出被叫是否在传统电话网上，然后通过一个与传统电话网相连的网关向被叫发起并建立呼叫。SIP的最强大之处就是用户定位功能。SIP本身含有向注册服务器注册的功能，也可以利用其他定位服务器如DNS、LDAP等提供的定位服务器来增强其定位功能。SIP中有客户机和服务器之分。客户机是指为了向服务器发送请求而与服务器建立连接的应用程序。用户代理（User Agent）和代理（Proxy）中含有客户机。服务器是用于向客户机发来 的请求提供服务并回送应答的应用程序。共有4类基本服务器： 用户代理服务器：当接到SIP请求时联系用户，并代表用户返回响应。 代理服务器：代表其他客户机发起请求，既充当服务器又充当客户机的媒介程序。它在转发请求之前可能改写原请求消息中的内容。 重走向服务器：接收SIP请求，把请求中的原地址映射成零个或多个新地址，返回给客户机。 注册服务器：接收客户机的注册请求，完成用户地址的注册。用户终端程序往往需要包括用户代理客户机和用户代理服务器。代理服务器、重定向服务器 和注册服务器可以看作是公众性的网络服务器。在SIP中还经常提到定位服务器的概念，但是定位服务器不属于SIP服务器。SIP服务器请求定位服务的方式也不在SIP的讨论范围之内。SIP独立于低层协议，一般使用UDP等无连接的协议，而采用自己的应用层可靠性机制来保证消息的可靠传输。1.3.2 DirectShow简介DirectShow是微软公司在ActiveMovie和Video for Windows的基础上推出的新一代基于COM的流媒体处理的开发包，与DirectX开发包一起发布。DirectShow为多媒体流的捕捉和回放提供了强有力的支持。运用DirectShow，我们可以很方便地从支持WDM驱动模型的采集卡上捕获数据，并且进行相应的后期处理乃至存储到文件中。它广泛地支持各种媒体格式，包括Asf、Mpeg、Avi、Dv、Mp3、Wave等等，使得多媒体数据的回放变得轻而易举。另外，DirectShow还集成了DirectX其它部分（比如DirectDraw、DirectSound）的技术，直接支持DVD的播放，视频的非线性编辑，以及与数字摄像机的数据交换2。1.3.3 RTP简介RTP协议（Real-time Transport Protocol或简写RTP），即实时传输协议，是一个网络传输协议，它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的。在本次系统中，本人主要负责模块就是基于RTP协议的网络实时传输，本论文将会在接下来的篇章中，详细介绍RTP协议概念与RTP协议的实际运用第二章 RTP协议简介2.1 RTP协议的概念随着网络的迅速发展，人们对多媒体的需求也越来越大。 其中，流媒体（音频、视频流） 的实时传输在网络传输中所占的比例越来越大。传统的TCP/ IP 协议注重传输的可靠性而不是实时性，依靠反馈重发进行差错通知和恢复，这就不适合多媒体数据传输了，原因如下:1. TCP 是面向连接的协议，连接的本身就会造成一定的时延；2. 重传机制增加了时延；3. TCP 协议中没有提供时间戳及编解码等多媒体传输接收方所需的信息。为此IETF的AVT工作组提出了实时传输协议RTP (Real-time Transport Protocol)，专用于实时多媒体数据的传输3。RTP是由IETF开发的用于音频、视频等多媒体数据实时传输的协议，可以在面向连接或无连接的下层协议上工作，通常和UDP协议一起使用。RTP协议主要实现一种端到端的多媒体流同步控制机制，既不需要事先建立连接，也不需要中间节点的参与，为其保留资源。在网络带宽充足的情况下，RTP具有一定的带宽调控能力，保证端到端的多媒体流同步。在网络带宽不足时，RTP的带宽调控能力将受到一定的限制。2.2 RTP协议的组成RTP协议包括RTP和RTCP两个关系十分密切的子协议: RTP用于实时数据的端到端传输， RTCP用于服务质量监控和网络状况诊断4。RTP协议一般运行在UDP之上，其上层为应用层，主要有音频、视频和数据等，如图2-1所示。RTP从应用层接收多媒体信息码流(如H. 263视频) ，组装成RTP数据包，然后发送给下层的UDP。图2-1 RTP/RTCP在TCP/IP模型中的位置2.3 RTP协议的特性相对于传统的传输层协议，RTP 协议具有以下特性：（1） 简单性：RTP 本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，RTP 报文甚至不包括长度和报文边界描述，它依靠下层服务完成这些任务。另外，RTP 协议将部分运输层协议功能（如流量控制）上移到应用层完成，简化了运输层处理，提高了该层效率。（2） 支持多播：RTP 协议一般运行在UDP 协议上，二者共同完成运输层协议的功能。RTP 协议利用UDP 的多路复用技术支持显式的多播。（3） 数据流和控制流的分离：RTP 协议的数据报文和控制报文使用相邻不同端口，这样大大提高了协议的灵活性和处理的简单性。（4） 可扩展性：通常RTP 算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分。开发者可以根据应用的具体要求对协议进行充分的扩展3。2.4 RTCP 协议可以完成的功能（1） QoS（Quality of Service）监测和拥塞控制：发送音频/ 视频数据的应用会产生一个SR 包，包中含有所发送的数据和字节数统计的信息，接收者可根据此信息估计出实际的数据率，会话成员向所有活动的音频视频源发送RR 包，包中含有所接收的最高包序号、丢失包数、包间隔抖动测量值以及计算源目之间RTT (Round Trip Time) 所需的时戳。（2） 媒体间同步：RTCP 的SR 包中含有实际时间和相应的RTP 时戳，可用于不同的媒体间同步。（3） 识别信息：RTP 数据包只能通过随机产生的32 位识别符来标识源，不能满足诸如会议这样的复杂应用的需求，而RTCP 的SEDS 包中有足够的文本信息，如正规的名字、用户名、E-mail 地址、电话号码、应用及警示信息等，可以满足复杂应用的需要。（4） 会议大小估计和控制信息量的调节：参与会话的每个成员周期性地发送RTCP 包，每个站点可据此估计或计算出参与会话的人数，以便及时调节实时控制的信息量，使得控制信息量和媒体业务量达到平衡。控制信息量一般为媒体业务量的5%左右3。2.5 RTP与RTCP报文的格式相对应于RTP协议所定义的两个子协议，RTP定义了两种报文RTP报文和RTCP报文。RTP报文用于传送媒体数据（如音频和视频），它由RTP报头和数据两部报文成，RTP数据部分称为有效载荷(payload)；RTCP报文用于传送控制信息，以实现协议控制功能。RTP报文和RTCP报文将作为下层协议的数据单元进行传输。如果使用UDP，则RTP报文和RTCP报文分别使用两个相邻的UDP端口，RTP报文使用低端口，RTCP报文使用高端口。如果使用其它的下层协议，RTP报文和RTCP报文可以合并，放在一个数据单元中一起传送，控制信息在前，媒体数据在后。通常，RTP是由应用程序实现的。2.5.1 RTP报文格式RTP报文由报头和数据两部报文成，数据部分为数字化的语音数据，它通过采样语音信号、量化采样信号，并对量化后的采样数据进行编码得到。RTP首部如图2-25所示。经过编码的数字化语音数据加上RTP报头后，发送给UDP层。图2-2 RTP报文格式其中，版本字段（version， V）：RTP协议的版本号，占2位，当前协议版本号为2。填充位（padding， P）：填充标志，占1位，如果P=1，则在该报文的尾部将填充一个或多个额外的八位组，它们不是有效载荷的一部分。由于数据长度必须是4字节的倍数，因此，有可能需要在数据末端包含若干个填充字节，以此满足数据长度必须是4字节倍数的要求。如果数据末端包含填充字节，填充位P置1，数据中的最后一个字节给出填充字节数。当然，在接收端，填充字节被忽略，不对其作任何处理。扩展位（extension， X）：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头。RTP报头的扩展报头格式如图2-3所示图2-3 RTP首部扩展RTP首部扩展：RTP首部的设计目标是为了满足绝大多数媒体信息流的一般要求，但不会是所有媒体信息所有要求。一些特殊的载荷格式可能要求一些额外的信息，这些信息可以作为载荷自身的一部分。例如可以指定载荷的前n个字节为特殊用途的字节，用于提供这种载荷格式所需要的额外信息。当然，也可以用RTP首部扩展来提供特定载荷格式要求提供的额外信息。通过将RTP首部的X位置1，来指明RTP首部扩展的存在，RTP首部扩展位于特约信源标识符列表和实际载荷数据之间，RTP只要求在首部扩展的规定位置给出首部扩展长度，以便在处理过程中能够 找到RTP报文的载荷区域。RTP并示对首部扩展的长度及包含的信息类型作出规定。CC(CSRC count)：CSRC计数器，占4位，给出RTP首部中CSRC 标识符的个数（015）。信标位（marker， M）: 该位的解释取决于携带的数据类型，RTP（RFC 1889）并没有规定该位的用途，但音频/视频描述文件（RFC 1890）规定，如果某个应用在静音阶段不发送报文，那么静音阶段后发送的第一个报文必须置位该信标位。负载类型（payload type，PT）: 也称为有效载荷类型或净荷类型，占7位，用于说明RTP报文中有效载荷的类型，通常情况下，单个RTP报文所包含的有效载荷只能用一种数据格式对多媒体数据进行编码。几种语音和视频编码及对应的有效载荷类型见表2-1。表 2-1 几种语音和视频编码及对应的有效载荷类型有效载荷类型编码名称媒体类型时钟频率（Hz）0PCMU语音800011016语音80002G726-32语音80003GSM语音80004G723语音80005DVI4语音80006DVI4语音160007LPC语音80008PCMA语音80009G722语音800010L16语音44100(双通路)11L16语音4410012QCEIP语音800014MPA语音9000015G728语音800016DVI4语音1102517DVI4语音22050有效载荷类型编码名称媒体类型时钟频率（Hz）18GF29语音800025CelB视频9000026JPEG视频9000028Nv视频9000031H.261视频9000032MPV视频9000033MP2T语音/视频9000034H.263视频90000序列号(sequence number， SN)：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。因此，在会话存在期间，顺序发送一串RTP报文的序号应该是递增的，接收者可能通过序列号来检测报文丢失情况，重新排序报文，恢复数据。时戳(timestamp)：占32位，用来指明载荷中第一个采样数据的采样时间，每一个采样数据的采样时间通过一个单调且线性递增的时钟获得。这样接收端应用程序能够以同步方式播放该RTP报文，并根据时间戳来计算时延抖动。为了能够更好地支持同步播放，时钟的精确度和分辨率必须适当。时钟频率取决于载荷数据的编码格式，RTP描述文件给出了几种编码格式的时钟频率，如编码名称为PCMU的语音编码格式所对应的时钟为8000Hz。相邻两个RTP报文的时间戳差值，取决于前一个RTP报文载荷中包含的采样数据数目。例如，如果前一个RTP报文载荷中包含了10个采样数据，当前RTP报文的时间戳值必须为11，一旦假定采样频率为8000Hz，两个相邻RTP报文的时间戳差值10可以换算成：100.125ms=1.25ms时间差。如果在静音阶段不传输RTP报文，静音阶段结束后传送的第一个RTP报文的时间戳值和前一个RTP报文的时间戳值之差，不仅要反映出前一个RTP报文载荷中包含的采样数据数目，而且还要反映出静音阶段的时间长度。同步信源标识符(synchronization source identifier， SSRC)：占32位，用于标识同步源，同步源是一个负责发送RTP报文并在RTP报文中设置序号和时间戳的实体，同步源标识符字段是一个惟一标识该实体的32位长度的随机数。当RTP报文来自混合器时，同步源标识符字段给出的是混合器的标识符，而不是信息源的标识符。标识符必须是会话中全局惟一的。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。特约信源标识符(contributing source identifiers， CSRC)列表：每个CSRC标识符占32位，特约信源标识符列表最多允许有16个提供源标识符。当RTP报文来自混合器时，同步信源标识符字段给出标识混合器的标识符，而用特约信源标识符列表给出进入混合器的各个信号的信号源标识符。2.5.2 RTCP报文格式RFC1889在定义实时传输协议（RTP）的同时，也定义了RTP的伴侣RTP控制协议（RTCP）。RTCP通过周期性交换会话两端的控制信息，为会话两端实体提供质量反馈信息，这种反馈信息可以用于检测并纠正实时传输中存在的问题。通过RTCP和IP组播这些信息，可以让第三方监测会话质量和网络中发生的问题。RTCP定义了下列5种不同类型的RTCP报文5：发送者报告（SR）：会话参与者用它转发有关传输和接收的统计信息。接收者报告（RR）：只接收媒体数据流的会话参与者用它发送有关接收的统计信息。源描述（SDES）：包含一个或多个和某个特定会话参与者相关的描述信息，通常情况下，SDES必须包含用于标识会话参与者的规范名字（CNAME），这个名字有别于同步源描述符，同步源描述符每当主机复位时，将重新设定，而且在某个特定会话内，如果某个实体生成多个RTP数据流，这些RTP数据流可以有不同 的同步源描述符。但规范名字是不变的，而且同一实体生成的多个RTP数据流具有相同的规范名字（CNAME）。因些，在接收端，规范名字可以用于关联这些RTP数据流，以此支持多个RTP数据流的同步播放。在特定会话内，规范名字（CNAME）必须是惟一的。在SDES报文内，也可能存在其他信息，如会话参与者具有的正规名字、E-mail或电话号码等。BYE：表明会话参与者退出某个会话。APP：应用相关功能，RTCP通过APP传送有关特定媒体或应用的信息，但对APP报文的内容不作规定。虽然这些RTCP报文类型是单独定义的，但它们并不是逐个传输的。实际上，常常是两个或多个RTCP报文被组合成单个复合报文后一并传输。之所以这样做是基于这样一个事实：为了得到更好的媒体数据流和发送源联系起来，也必须尽早接收各个媒体数据流发送源的标识信息（如CNAME）。由此可见，在每一次RTCP报文发送的过程中，SR/RR和CDES报文似乎是必不可少的。因此，RTCP规定，每个RTCP复合报文必须包含SR或RR和CDES报文，而且以报告报文（SR或RR）作为复合报文的开始。根据规定，当某个媒体数据流发送源需要发送SDES报文时，它必须一起发送一个报告报文，即使没有相关信息需要报告，也须如此。这种情况下，复合报文可以包含一个空RR报文。如图2-4所示5为一个复合报文的实例。发送该复合报文的会话参与者，已经表明将退出该会话，复合报文末端的BYE报文就用于表明这一点。图2-4 RTCP复合报文 RTCP发送者（SR）报文只有发送并接收RTP报文的会话参与者才使用发送者报告，发送者报告的格式如图2-5所示5，它由三个不同的区域构成：首部信息、发送者信息和若干接收者报告块。作为可选区域，发送者还允许包含一个用于描述的扩展区域。图2-5 RTCP发送者报告格式1. 首部信息首部信息中的各字段的含义如下：（1） V：2位长度，给出当前版本号，RTCP和RTP一样，当前版本号为2。（2） P：填充位，用于指明报文末端是否有填充字节。如果P位置1，表明报文末端存在填充字节，而且由报文末端的最后一个字节给出填充字节数量。（3） RC：5位长度，给出报文所密集的接收者报告块的数量。由于RC的长度只有5位，因此单个发送者报告中最多包含31个接收者报告块。在一个大型会议中，某个会话参与者可能需要向其他会话参与者发送多于31的接收者报告块，这种情况下，RTCP复合报文结构就非常有用了。在RTCP复合报文中，SR报文之后可以紧随一个RR报文。（4） RT：8位长度，给出载荷类型，SR报文的载荷类型固定为200.（5） 长度：16位长度，以字节为单位，给出SR报文的总长。2. 发送者信息发送者信息包含标识发送者的同步源标识符（SSRC），一些时间信息及有关发送者发送的报文数和字节数等统计信息，它主要由下述字段构成：（1） 发送者SSRC：32位长度，给出发送同步源标识符（SSRC）。（2） NTP时间戳：64位长度，网络时间协议（NTP）的时间戳，给出以1900年1月1日0点0分0秒为时间原点的时间值。高32位以秒为单位给出当前时间和时间原点的差值，低32位表示秒的小数部分。因此，NTP时间戳的精确度约为2001012秒。由于只用32位表示当前时间和时间原点的差值，而32位至多只能表示232秒。如果将232秒折算成年的话，大约等于136年，因此，当1900+1362036年时，NTP时间戳已无法再表示当时时间和时间原点之间的差值了。（3） RTP时间戳：RTP时间戳和RTP报文中的时间戳一样，通过单独线性递增的时钟计数器获得，基本递增单位取决于载荷格式。在同一报告中同时NTP时间戳和RTP时间戳是为了使报告的发送者和接收者能够更好地同步。（4） 发送者报文计数器：给出发送者从会话开始到报告发送时，已经发送的RTP报文的数量。发送者报文计数器从会话开始不断累计发送者发送的RTP报文，只有当发送者SSRC改变时，才对发送者报文计数器清零。（5） 发送者字节计数器：给出发送者从会话开始到报告发送时，已经发送的字节数。发送者字节计数器从会话开始不断累计发送者发送的字节数，一旦发送者SSRC改变，则对发送者字节计数器进行清零。3. 接收者报告块接收者报告块用于向其他会话参与者报告接收它们发送的RTP报文的情况。接收者报告块包括下述字段：（1） SSRC_n：32位长度，接收者报告块中数据所关联的会话参与者的同步源标识符（SSRC）。（2） 报文丢失率：8位长度，给出从前一个报告发送后到当前这一段时间内RTP报文的丢失率。RTP报文丢失率通过这一段时间内检测到的丢失的RTP报文数，除以这一段时间内应该接收的RTP报文数。应该接收的RTP报文数和丢失的RTP报文数均可通过RTP报文的序号求得。（3） 丢失报文总数：24位长度，自RTP会话开始以来，累计丢失的RTP报文数。（4） 扩展的最高序号：32位长度。低16位指明接收到的最后一个RTP报文的序号，高16位指明序号循环次数。16位RTP报文序号的范围为065535，当序号为65535的RTP报文接收后，下一个接收的RTP报文的序号重新为0。发生这种情况意味着序号循环了一次。（5） 间隔抖动：32位长度，给出RTP报文到达间隔变化的一个估计值。（6） 最新的发送者报告时间戳（LSR）：32位长度，接收到的来自SSRC_n所指定源终端的最后一个发送者报告中64位NTP时间戳的中间32位（高32位的低16位+低32位的高16位），SSRC_n所指定的源终端用该时间戳确定自己发送的发送者报告（SR）是否已经被正确接收。（7） SR最新间隔（DLSR）：32位长度，以1/65535秒为单位给出接收SSRC_n所指定源终端的最后一个发送者报告到该接收者报告块发送时的时间间隔。每一个接收者报告块中的数据都只和SSRC_n所指定的源终端相关联，因此，所有统计数据都针对由SSRC_n所指定的源终端发送的RTP报文。RTCP本身并不对用于描述的扩展区域的内容进行定义，如果某种特定的媒体数据类（或载荷格式）使用了用于描述的扩展区域，必须由它对扩展区域的使用方式进行定义。 RTCP接收者（RR）报文RTCP接收者报告（RR）由只接收RTP报文的会话参与者发送。接收者报告的格式如图2-6所示5，它基本上和RTCP发送者报告（SR）相同。但由于发送接收者报告的会话参与者没有将RTP报文发送给其他会话参与者，因此，接收者报告中，没有列出有关发送者关于已发送的RTP报文的一些统计信息。接收者报告的载荷类型固定为201.图2-6 RTCP接收者报告（RR）格式 RTCP源终端描述（SDES）报文RTCP源终端描述报告（SDES）提供用于标识特定会话参与者的标识信息及其他相关信息，每一个RTCP复合报文中都必须包含SDES报文。SDES报文的格式如图2-7所示。图2-7 SDES报文格式SDES报文由两部报文成：报文首部和零个或多个信息块。报文首部中的载荷类型（PT）字段的值固定为202，表明是SDES报文，而源终端计数器（SC）给出SDES报文中信息块的数量，由于SC的长度只有5位，因此，SDES报文包含的信息块数量不能直超过31。每一个信息块由一个同步源标识符（SSRC）组成，也可由提供源标识符（CSRC）及一系列与同步源标识符或提供源标识符所指定的源终端相关联的标识信息组成，这一组标识信息称作SDES项，它通常包括E-mail地址、电话号码及姓名等。SDES报文中如果存在信息块，该信息块就必须包含CNAME SDES项。在指定会话中，会话参与者的CNAME是不变的，而且是惟一的。虽然在通常情况下，会话参与者的SSRC也是不变而且惟一的，但如果在会话过程中发生两个会话参与者取了相同的SSRC值或者源终端因为复位而重新对SSRC取值，会话参与者的SSRC将发生变化。为了确保CNAME的惟一性，CNAME采用用户名域名格式，如图2-8所示5。图2-8 作为CNAME的SDES项 BYE报文BYE报文用于指明有一个或多个源终端将退出会话，报文中还可以包含用于说明退出原因的文本信息。BYE报文的格式如图2-9所示5。源终端计数器（SC）用于指出报文中所包含的源终端描述符（SSRC或CSRC）的数量；载荷类型（PT）字段值固定为203，指明是BYE报文。在SSRC或CSRC列表之后，作为可选项，允许提供文本信息，给出退出会话的原因。如果存在这样的文本信息区域，区域的第一个字节（8位）作为长度给出文本信息区域的字节数。文本信息以字符串形式表示。图2-9 BYE报文格式 应用相关功能（APP）报文通过分析各种RTP和RTCP报文可以发现：RTP和RTCP报文通过扩展，允许存在和应用相关的数据，这就为用户增加特定应用所特别需要的功能提供了灵活性。为保持这一灵活性，RTCP控制报文中包含了应用相关功能（APP）报文，如图2-10所示5。图2-10 APP报文格式这种类型的报文主要用于提供非标准化的、和特定应用相关的数据。为了便于接收者理解并处理报文中所包含的非标准化数据，应该对这些数据附带一些标识性信息。报文首部中载荷类型字段只能标明报文是应用相关功能报文，无法进一步标识报文中包含的数据类型。因此，在报文首部中增加了子类型字段用于标识报文中所包含的数据类型。名字字段是一串标明应用创建者的ASCII码，也可用于说明应用相关数据的含义。第三章 JRTPLIB介绍与使用3.1 JRTPLIB介绍JRTPLIB是一个用C+编写实现的面向对象的RTP库，目前已经可以运行在Windows、Linux、FreeBSD、Solaris和Unix等多种操作系统上。它的主要目的是帮助编程人员简单地实现RTP协议并使用其进行数据的实时网络传输。JRTPLIB是一个高度封装后的RTP库，编程人员使用JRTPLIB时，无需考虑一些繁琐的细节，如SSRC域的冲突，RTCP数据报的发送和接收，等等，这些都会由JRTPLIB来自动完成，只要Poll()或者SendPacket()方法被成功调用（这两个方法都会在下面的介绍JRTPLIB方法时介绍到），JRTPLIB就能够自动对到达的RTCP数据报进行处理，并且还会在需要的时候发送RTCP数据报，从而保证整个RTP会话过程的正确性。编程人员只需提供网络传输时所要发送的有效载荷数据，JRTPLIB会自动给编程人员引入并创建RTP和RTCP数据报。3.2 JRTPLIB环境配置首先，从官方网站：http:/research.edm.uhasselt.be/jori/jrtplib/jrtplib.html上下载jrtplib包和jthread包, 其中jthread包是和线程相关函数的实现。JRTPLIB是一个开放源代码的程序包，目前还在不断更新中，本次毕设