《RTP及其应用》doc版.doc

一、实时传输协议RTP与RTCPRTP（Real-timeTransportProtocol）是用于Internet上针对多媒体数据流的一种传输协议。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP通常使用UDP来传送数据，但RTP也可以在TCP或ATM等其他协议之上工作。当应用程序开始一个RTP会话时将使用两个端口：一个给RTP，一个给RTCP。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。通常RTP算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分。实时传输控制协议RTCP。RTCP(Real-timeTransportControlProtocol)和RTP一起提供流量控制和拥塞控制服务。在RTP会话期间，各参与者周期性地传送RTCP包。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。6.2.2 RTP控制协议- RTCP RTCP协议将控制包周期发送给所有连接者，应用与数据包相同的分布机制。低层协议提供数据与控制包的复用，如使用单独的UDP端口号。RTCP执行下列四大功能： 主要是提供数据发布的质量反馈。是作为RTP传输协议的一部分，与其他传输协议的流和阻塞控制有关。反馈对自适应编码控制直接起作用，但IP组播经验表明，从发送者收到反馈对诊断发送错误是致关重要的。给所有参加者发送接收反馈报告允许问题观察者估计那些问题是局部的，还是全局的。诸如IP组播等发布机制使网络服务提供商类团体可能接收反馈信息，充当第三方监控者来诊断网络问题。反馈功能由RTCP发送者和接收者报告执行。 RTCP带有称作规范名字（CNAME）的RTP源持久传输层标识。如发现冲突，或程序重新启动，既然SSRC标识可改变，接收者需要CNAME跟踪参加者。接收者也需要CNAME 与相关RTP连接中给定的几个数据流联系 前两种功能要求所有参加者发送RTCP包，因此，为了RTP扩展到大规模数量，速率必须受到控制。让每个参加者给其它参加者发送控制包，就大独立观察参加者数量。该数量用语计算包发送的速率。 第四个可选功能是传送最小连接控制信息，如参加者辨识。最可能用在松散控制连接，那里参加者自由进入或离开，没有成员控制或参数协调，RTCP充当通往所有参加者的方便通道，但不必支持应用的所有控制通讯要求。高级连接控制协议超出本书范围。 在IP组播场合应用RTP时，前3个功能是必须的，推荐用于所有情形。RTP应用设计人员必须避免使用仅在单播模式下工作的机制，那将导致无法扩展规模。 RTCP 包格式 下面定义几个携带不同控制信息的RTCP包类型： SR： 发送报告，当前活动发送者发送、接收统计。 RR： 接收报告，非活动发送者接收统计。 SDES： 源描述项，包括CNAME。 BYE： 表示结束。 APP： 应用特定函数。 类似于RTP数据包，每个RTCP包以固定部分开始，紧接着的是可变长结构元素，但以一个32位边界结束。包含安排要求和固定部分中长度段，使RTCP包可堆叠。不需要插入任何分隔符将多哥RTCP包连接起来形成一个RTCP组合包，以低层协议用单一包发送出去。由于需要低层协议提供提供整体长度来决定组合包的结尾，在组合包中没有单个RTCP包显式计数。 组合包中每个RTCP包可独立处理，不需要根据包组合顺序。但未了执行协议功能，强加如下约束： 接收统计（在SR或RR中）应该经常发送，只要带宽允许，因此每个周期发送的组合RTCP 包应包含报告包。 新接收者需要接收CNAME，并尽快识别源，开始联系媒介进行同步，因此每个包应该包含SDES CNAME。 出现在组合包前面的是包类型数量，其增长应该受到限制，以提高常数位数量，提高成功确认RTCP包对错误地址RTP数据包或其他无关包的概率。 因此，所有RTCP包至少必须以两个包组合形式发送，推荐格式如下： 加密前缀（Encryption prefix）： 仅当组合包被加密，才加上一个32位随机数用于每个组合包发送。 SR或RR： 组合包中第一个RTCP包必须总为一个报告包，方便头的确认。即使没有数据发送，也没有接收到数据，也要发送一个空RR，那怕组合包中RTCP包为BYE。 附加RR： 如报告统计源数目超过31，在初始报告包后应该有附加RR 包。 SDES： 包含CNAME 项的SDES包必须包含在每个组合RTCP包中。如应用要求，其他源描述项可选，但受到带宽限制。 BYE或APP： 其它RTCP包类型可以任意顺序排列，除了BYE应作为最后一个包发送，包类型出现可不止一次。 建议转换器或混合器从多个源组合单个RTCP包。如组合包整体长度超过网络路径最大传输单元，可分成多个较短组合包用低层协议以单个包形式发送。注意，每个组合包必须以SR或RR包开始。附加RTCP包类型可在Internet Assigned Numbers Authority (IANA)处注册。 RTCP传输间隔 RTP设计成允许应用自动扩展，连接数可从几个到上千个。例如，音频会议中，数据流量是内在限制的，因为同一时刻只有一两个人说话；对组播，给定连接数据率仍是常数，独立于连接数，但控制流量不是内在限制的。如每个参加者以固定速率发送接收报告，控制流量将随参加者数量线性增长，因此，速率必须按比例下降。 一旦确认地址有效，如后来标记成未活动，地址的状态应仍保留，地址应继续计入共享RTCP带宽地址的总数中，时间要保证能扫描典型网络分区，建议为30分钟。注意，这仍大于RTCP报告间隔最大值的五倍。 这个规范定义了除必需的CNAME外的几个源描述项，如NAME（人名）和EMAIL（电子邮件地址）。它也为定义新特定应用RTCP包类型的途径。给附加信息分配控制带宽应引起注意，因为它将降低接收报告和CNAME发送的速率而损害协议的性能。建议分配给单个参加者用于携带附加信息的RTCP带宽不要超过20%。而且并没有有意让所有SDES项包含在每个应用中。 发送者与接收者报告 RTP接收者使用RTCP报告包提供接收质量反馈，报告包根据接收者是否是发送者而采用两种格式中的一种。除包类型代码外，发送者报告与接收者报告间唯一的差别是发送者报告包含一个20个字节发送者信息段。如某地址在发出最后或前一个报告间隔期间发送数据包，就发布SR；否则，就发出RR；SR和RR都可没有或包括多个接收报告块。发布报告不是为列在CSRC列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。既然最大可有31个接收报告块嵌入在SR 或 RR包中， 丢失包累计数差别给出间隔期间丢掉的数量，而所收到扩展的最后一个系列号的差别给出间隔期间希望发送的包数量，两者之比等于经过间隔期间包丢失百分比。如两报告连续，比值应该等于丢失段部分；否则，就不等。每秒包丢失绿可通过NTP时标差除以丢失部分得到。 从发送者信息，第三方监控器可计算载荷平均数据速率与没收到数据间隔的平均包速率，两者比值给出平均载荷大小。如假设包丢失与包大小无关，那么特殊接收者收到的包数量给出此接收者收到的表观流量。 SDES: 源描述RTCP包 SDES 包为三层结构，由头与数据块组成，数据块可以没有，也可有多个，组成项描述块所表明的源。项描述如下： 版本（V）、填充（P）、长度： 如SR包中所描述。 包类型（PT）： 8位，包含常数202，识别RTCP SDES包。 源计数（SC）： 5位，包含在SDES包中的SSRC/CSRC块数量，零值有效，但没有意义。 源描述项内容如下： CNAME: 规范终端标识SDES项 CNAME标识属性如下： 如发生冲突或重启程序，由于随机分配的SSRC标识可能发生变化，需要CNAME项提供从SSRC标识到仍为常量的源标识的绑定。 象SSRC标识，CNAME标识在RTP连接的所有参加者中应是唯一的。 为了提供一套相关RTP连接中某个参加者所采用的跨多媒体工具间的绑定，CNAME应固定为那个参加者。 为方便第三方监控，CNAME应适合程序或人员定位源。 NAME：用户名称SDES项 这是用于描述源的真正的名称，如John Doe, Bit Recycler, Megacorp，可是用户想要的任意形式。对诸如会议应用，这种名称也许是参加者列表显示最适宜的形式，它将是除CNAME外发送最频繁的项目。设置可建立这样的优先级别。NAME值至少在连接期间仍希望保持为常数。它不该成为连接的所有参加者中唯一依赖。 EMAIL：电子邮件地址SDES项 邮件地址格式由RFC822规定，如John.D。连接期间，电子邮件仍希望保持为常数。 PHONE：电话号码SDES项 电话号码应带有加号，代替国际接入代码，如+1 908 555 1212即为美国电话号码。 LOC：用户地理位置SDES项 根据应用，此项具有不同程度的细节。对会议应用，字符串如Murray Hill, New Jersey就足够了。然而，对活动标记系统，字符串如Room 2A244, AT&T BL MH也许就适用。细节留给实施或用户，但格式和内容可用设置指示。在连接期间，除移动主机外，LOC值期望仍保留为常数。 TOOL：应用或工具名称SDES项 是一个字符串，表示产生流的应用的名称与版本，如videotool 1.2。这部分信息对调试很有用，类似于邮件或邮件系统版本SMTP头。TOOL值在连接期间仍保持常数。 NOTE: 通知/状态SDES项 该项的推荐语法如下所述，但这些或其它语法可在设置中显式定义。NOTE 项旨在描述源当前状态的过渡信息，如on the phone, cant talk，或在讲座期间用于传送谈话的题目。它应该只用于携带例外信息，而不应包含在全部参加者中，因为这将降低接收报告和CNAME发送的速度，因此损害协议的性能。特殊情况下，它不应作为用户设置文件的项目，也不是自动产生。 当其为活动时，由于NOTE项对显示很重要，其它非CNAME项（如NAME）传输速率将会降低，结果使NOTE项占用RTCP部分带宽。若过渡信息不活跃，NOTE项继续以同样的速度重复发送几次，但以一个串长为零的字符串通知接收者。然而，如对小倍数的重复或约20-30 RTCP间隔也没有接收到，接收者也应该考虑NOTE项是不活跃的。 PRIV: 专用扩展SDES项 该项用于定义实验或应用特定的SDES扩展，它包括由长字符串对组成的前缀，后跟填充该项其他部分和携带所需信息的字符串值。前缀长度段为8位。前缀字符串是定义PRIV项人员选择的名称，唯一对应应用接收到的其它PRIV项。应用实现者可选择使用应用名称，如有必要，外加附加子类型标识。另外，推荐其它人根据其代表的实体选择名称，然后，在实体内部协调名称的使用。 注意，前缀消耗了总长为255个八进制项的一些空间，因此，前缀应尽可能的短。这个设备和受到约束的RTCP带宽不应过载，其目的不在于满足所有应用的全部控制通讯要求。SDES PRIV前缀没在IANA处注册。如证实某些形式的PRIV项具有通用性， IANA应给它分配一个正式的SDES项类型，这样就不再需要前缀。这简化了应用，并提高了传输的效率。 BYE：断开RTCP包 如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC/CSRC 标识。如混合器关闭，它也应该发出一个BYE包，列出它所处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个8位八进制计数，后跟很多八进制文本，表示离开原因，如：camera malfunction或RTP loop detected。字符串具有同样的编码，如在SDES 中所描述的。如字符串填充包至下32位边界，字符串就不以空结尾；否则，BYE包以空八进制填充。 APP：定义应用的RTCP包 APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。二、RTP主要参数说明：RTP相关-| IP | UDP | RTP | Data |-包含time-stampRTCP包用于质量反馈的传输；RTP会话和RTCP会话总是同时开始；RTP的默认端口号是5004，RTCP是5005；RTP中的payload type用来表示各种不同的编码标准，7bit，35-71及77-95待定，96-127动态，72-76保留；RTP header:Version(V)当前版本为2;Padding(P)当P=1时表示包含一个或多个填充字节以进行32bit对齐；EXtension(X)是否包括头部扩展；CSRC Count(CC)CSRC的个数；Marker(M)用于支持silence suppression，在一个talkspurt的第一个包中设成1；Payload Type(PT)一般来说每个单独的RTP包只包含一种载荷的编码格式，但是也有意外，比如RED profile就包含多种编码格式，此时每种编码的载荷由额外的头部管理，PT值仅仅表示这是一个RED载荷，具体可参考RFC 2198；Sequence Number 一个会话开始时设置为一个随机值，之后每个RTP包中此值依次加1，用于检测包丢失及接收方排序；Timestamp 记录了负载中第一个字节的采样时间,用于计算延迟和抖动；初始值为随机值，根据连续两次RTP包之间进行的采样数递增；Synchronization Soruce(SSRC)表示负责设置序列号和时间戳的实体，通常是RTP包的发送者。标识是随机选择的所以与网络地址无关。另外，如果RTP流来自一个混合器，则SSRC表示此混合器而不是媒体源；Contributing Source(CSRC)用于当RTP流来自一个mixer时表示此mixer后的媒体源。RTP Header Extensions：X域值为1时有效，此时payload的前几个字节做为具有特殊含义的扩展头部，紧跟在CSRC域之后。Mixers合成多路媒体流：鉴于带宽问题mixer将4路64kbps的RTP流合成为一条单独的64kbps的流。调整数据格式：如在一个高速连接的会话中出现一个低速的连接接入者，mixer可能会对其使用低带宽的编码机制；设置时间戳的值。Traslators仅做媒体格式转换之用,不是一个SS(Synchronization Source)。RTCP相关能够在会话参与者之间进行周期性的控制信息交换，主要目的是提供质量相关的反馈。通过使用RTCP和IP多播机制，可以进行第三方的监视和检测。RTCP定义了5种不同类型的RTCP包：1.Sender Report(SR)用来中继发送和接收统计；2.Receiver Report(RR)只接收而不发送媒体流的参与者发送的接收统计；3.Source Description(SDES)包含某一特定会话参与者的一个或多个描述。必须包含一个唯一的canonical name(CNAME)用于标识会话的参与者，它不同于SSRC，因为当主机reset后SSRC的值可能会发生改变。再者，如果在一个给定的会话中，发送者同时发送音频和视频的两路RTP流，则这两种媒体流有不同的SSRC值但是却有相同的CNAME；4.BYE 表示一个会话中的参与中止；5.APP 用于调查特定的媒体类型和应用信息，不过RTCP没有明确APP包的详细内容。事实上，总是两个或多个RTCP包被捆绑成一个混合包发送出去的。所有的RTCP包都必须以一个SR或RR开始，都必须包含至少一个SDES，即使在SDES之间加上一个空的SR或RR。Compound Packet举例:(发送者离开此次会话)H：Header D：Data-| SR H | SR D | SDES H | SDES D | BYE H | BYE D |-RTCP Sender Report(SR)由三部分组成：header,sender information和多个Report Block1.header:RC域，表示含有多少个receiption report blocks，5bit,一个SR之后最多可以跟31个RR blocks。当RR多于31个时只需在最后一个RR后再跟一个SR即可；Payload Type(TP)的值为200；2.Sender info:SSRC of sender 发送者的SSRC;NTP Timestamp 两个字，第一个表示整数部分，第二个表示小数部分，以1900年1月1日00:00时为参照时间，单位是秒，小数部分精确到200皮秒，此版本的网络时间协议2036年到期，在此之间应该会有新的版本，此时间戳信息来自于一个时间服务器，这个服务器通过NTP协议在网络上传播计时信息；RTP Timestamp 同时包含RTP和NTP时间戳是为了使接收方更好的于发送方保持同步；Senders packet count 记录从会话开始到此RTCP包发出这之间所传输的RTP包的总数，只有当发送者的SSRC值改变时此项才重置；Senders octet count 记录从会话开始到此RTCP包发出这之间所传输的载荷字节的总数，只有当发送者的SSRC值改变时此项才重置；3.RR Blocks：(RR用于反馈RTP包的接收情况)SSRC_n 表示与此RR块相关的会话参与者的源标识；Fractioin lost (8bit)表示包的丢失率是多少，即丢失的包的数量除以期望的包的数量，丢失的包的数量可以通过每次检查RTP包头中的Sequence Nmuber统计出来；Cumulative number of packets lost (24bit)从会话开始至今丢失的包的总数；Extended highest sequence number receirved (32bit)低16位表示最近收到的RTP包的序列号，一般情况下高16位全为0，但如果收到的某一个发送源的序列号出现循环，则在它的相应RR段中此高16位值表示已循环的次数；Interarrival jitter 对RTP包到达不一致性的估计；Last SR Timestamp(LSR) 表示所接收到的此RR块对应的SSRC发送的最后一个SR中64-bit NTP时间戳的中间32位，以告知它所发送的SR是否已经被收到；Delay Since Last SR (DLSR)从收到最后一个SR到此RR块被发出经历的时间，精确到1/65536秒。RR包包括header,发送者SSRC以及Report Blocks,基本与SR相同，只是header中的PT值为201。RTCP Source Description Packet (SDES)相关必须存在于每一个RTCP混合包中，由一个header和0个或多个chunk组成，header中的PT值为202，SC的值表示chunk的个数；每个chunk包括一个SSRC或CSRC值，之后是一些SDES项，比如email地址、电话号码、姓名等等，但是有一个项是必需的，即CNAME，它的形式为userhost。RTCP BYE PacketPT值为203，SC表示SSRC或CSRC的数量，在这之后有个length域表示文本字符串的字节数，length域之后是以文本字符储存的离开会话的原因。Application-Defined RTCP Packet略RTP协议RTP协议是在rfc1889中规定的。如上面所说，UDP是不确定的连接，在多媒体信息传输的时候，我们需要知道当前的网络传输状况如何，并对于传输过程进行优化，这样的话，才能充分利用带宽。RTP在包中加入了时间戳信息，利用时间戳，我们可以知道传输的抖动信息以及传输过程的问题。RTP包的定义在rfc1889中进行。RTP包含有不同的净荷，也就是说RTP中包含的数据类型是不确定的，所以在RTP报头中有一个净荷类型的标志来进行标记。对于不确定类型的数据，RTP中预留了一部分动态净荷类型标记，这些标记用于自定义。RTP的报头格式如下： 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+V为版本，当前为2P表示在当前净荷中是否有一到多位的填充信息。CC为CSCR的计数信息，M为标记位，用于静态抑制。PT为上面提到过的净荷类型。序列号是在会话开始的时候设定的一个随机数，用序列号可以知道数据是否被收到。时间戳是一个线性的时钟，用它来对于包的到达状况进行识别。SSRC同步源，负责序列号和时间戳的值，这个标志符由发送方随机选取，这样就不会依赖于网络地址。CSRC有用源，包含一个会话发起者的SSRC值。RTCP协议RTCP共定义了五种不同的RTCP分组：发送方报告（SR），接收方报告（RR），源描述（SDES），BYE, APP.一个会话双方进行RTP分组时使用SR。格式如下： 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|V=2|P| RC | PT=SR=200 | length | header+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| SSRC of sender |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| NTP timestamp, most significant word | sender+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ info| NTP timestamp, least significant word |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| RTP timestamp |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| senders packet count |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| senders octet count |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| SSRC_1 (SSRC of first source) | report+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block| fraction lost | cumulative number of packets lost | 1-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| extended highest sequence number received |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| interarrival jitter |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| last SR (LSR) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| delay since last SR (DLSR) |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| SSRC_2 (SSRC of second source) | report+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block: . : 2+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| profile-specific extensions |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+这个分组格式与RTP包很相似，我们不再继续分析。RTCP接收方报告(RR),格式如下。它由一个会话参与者发出，它接收了RTP分组，但自己还没有发送过RTP包到任何一个其他的参与者。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|V=2|P| RC | PT=RR=201 | length | header+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| SSRC of packet sender |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| SSRC_1 (SSRC of first source) | report+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block| fraction lost | cumulative number of packets lost | 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| extended highest sequence number received |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| interarrival jitter |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| last SR (LSR) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| delay since last SR (DLSR) |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| SSRC_2 (SSRC of second source) | report+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block: . : 2+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| profile-specific extensions |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+RTCP源描述分组(SDES) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|V=2|P| SC | PT=SDES=202 | length | header+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| SSRC/CSRC_1 | chunk+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1| SDES items | . |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| SSRC/CSRC_2 | chunk+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2| SDES items | . |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+SDES提供有关会话参与者的身份认证和会话参与者的其他信息。RTCP的BYE分组， 表示一个或更多的媒体源不再是处于激活的状态。s 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| SC | PT=BYE=203 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC/CSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : . : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | length | reason for leaving . (opt) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+应用定义的RTCP(APP)分组 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| subtype | PT=APP=204 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC/CSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | name (ASCII) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | application-dependent data . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+是对于RTCP的扩展过程。我们利用SR与RR的信息可以计算得到一个回路的时间比如A在T1发报告给B，B在T2时接收到这个报告，B在时间T3发送报告B，A在T4的时候接收到这个报告。这个回路的时间为T4-T3+T2-T1.同样的原理，可以计算抖动以及分组定时等等其他的功能三、用RTP构建流媒体服务器的实现方案 随着互联网的飞速发展,流媒体技术的应用越来越广泛,从网上广播、电影播放到远程教学以及在线的新闻网站等都用到了流媒体技术。但现有公开文献所报道的大多是利用现有的流媒体服务器来搭建一个流媒体服务系统，或者是针对流媒体数据的编码方式所进行的研究。本文对流媒体服务器技术的研究重点在于如何建立一个服务器，并且在实现流媒体传输的两个基本协议RTP/RTCP的基础上构建一个基本的流媒体服务器。2 流媒体技术简介2.1 “流”的定义现在网上传输视频、音频主要有下载（Download）和流式传输（Streaming）两种方式。流式传输是连续传送视/音频信号，当流媒体在客户机播放时其余部分在后台继续下载。流式传输有顺序流式传输(Progressive Streaming)和实时流式传输(Realtime Streaming)两种方式。实时流式传输是实时传送，特别适合现场事件，实时流式传输必须匹配连接带宽，这意味着图像质量会因网络速度降低而变差,以减少对传输带宽的需求。“实时”的概念是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系。 在Internet中使用流式传输技术的连续时基媒体就称为流媒体，通常也将其视频与音频称为视频流和音频流。实现流式传输一般都需要专用服务器和播放器。2.2 流媒体系统组件流媒体是由各种不同软件构成的，这些软件在各个不同层面上互相通信，基本的流媒体系统包含以下3个组件：播放器（Player），用来播放流媒体的软件。服务器（Server），用来向用户发送流媒体的软件。编码器（Encode），用来将原始的音频视频转化为流媒体格式的软件。这些组件之间通过特定的协议互相通信，按照特定的格式互相交换文件数据。有些文件中包含了由特定编解码器解码的数据，这种编解码器通过特定算法压缩文件的数据量。3 流媒体服务器的基本功能和服务方式3.1 流媒体服务器的主要功能（1）响应客户的请求