RTP&RTCP

实时传输协议 RTP
RTP（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配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。
5. RTP数据传输协议
　RTP提供端对端网络传输功能，适合通过组播和点播传送实时数据，如视频、音频和仿真数据。RTP没有涉及资源预订和质量保证等实时服务，RTCP扩充数据传输以允许监控数据传送，提供最小的控制和识别功能。RTP与RTCP设计成独立于传输和网络层。
5.1 RTP固定头
　RTP 头格式如下：
　---------------------------------------------------------------------------------------
　|V=2|P|X| CC |M| PT | 系列号 |
　---------------------------------------------------------------------------------------
　| 时标 |
　
　| 同步源标识(SSRC) |
　---------------------------------------------------------------------------------------
　| 作用标识 (CSRC) |
　| .... |
　---------------------------------------------------------------------------------------
　开始12个八进制出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。
5.2 复用 RTP 连接
　为使协议有效运行，复用点数目应减至最小。RTP中，复用由定义RTP连接的目的传输地址（网络地址与端口号）提供。例如，对音频和视频单独编码的远程会议，每个媒介被携带在单独RTP连接中，具有各自的目的传输地址。目标不在将音频和视频放在单一RTP连接中，而根据SSRC段载荷类型进行多路分解。使用同一SSRC ，而具有不同载荷类型的交叉包将带来几个问题：
　 如一种载荷类型在连接期间切换，没有办法识别新值将替换那一个旧值。
SSRC定义成用于标识单个计时和系列号空间。如媒体时钟速率不同，而要求不同系列号空间以说明那种载荷类型有丢包，交叉复用载荷类型将需要不同计时空间。
　 RTCP发送和接收报告可能仅描述每个SSRC的计时和系列号空间，而不携带载荷类型段。
　 RTP混合器不能将不兼容媒体流合并成一个流。
　在一个RTP连接中携带多个媒介阻止几件事：使用不同网络路径或网络资源分配；接受媒介子集。
对每种媒介使用不同SSRC，但以相同RTP连接发送可避免前三个问题，但不能避免后两个问题。
http://man.chinaunix.net/develop/rfc/RFC2959.txt实时传输协议管理信息库
5.3 对RTP头特定设置profile的修改
　可以认为，现用RTP数据包头对RTP支持的所有应用类共同需要的功能集是完整的。然而，为了维持ALF设计原则，头可通过改变或增加设置来裁剪，并仍允许设置无关监控和记录工具起作用。
* 标记位与载荷类型段携带特定设置信息，但由于很多应用需要它们，或者要容纳它们，就要增加另外32位字，故允许分配在固定头中。包含这些段的八进制可通过设置重新定义以适应不同要求，如采用更多或更少标记位。如有标记位，既然设置无关监控器能观察包丢失模式和标记位间关系，我们就可以定位八进制中最重要的位。
　*其它特殊载荷格式（视频编码）所要求的信息应该携带在包的载荷部分。可出现在头，总是在载荷部分开始处，或在数据模式的保留值中指出。
* 如特殊应用类需要独立载荷格式的附加功能，应用运行的设置应该定义附加固定段跟随在现存固定头SSRC之后。这些应用将能迅速而直接访问附加段，同时，与监控器和记录器无关设置仍能通过仅解释开始12个八进制处理RTP包。如证实附加功能是所有设置共同需要的，新版本RTP应该对固定头作出明确改变。
6. RTP控制协议-- RTCP
　 RTCP协议将控制包周期发送给所有连接者，应用与数据包相同的分发机制。低层协议提供数据与控制包的复用，如UDP分别给两者提供单独的端口。
RTCP执行下列四大功能：
　 1.主要是提供数据分发的质量反馈。是作为RTP传输协议的一部分，与其他传输协议的流控制和阻塞控制有关。反馈对自适应编码控制直接起作用，但IP组播经验表明，从发送者收到反馈对诊断发送错误也是致关重要的。给所有参加者发送接收反馈报告，允许问题观察者估计那些问题是局部的，还是全局的。诸如IP组播等发布机制可能会使一个如网络服务提供商等团体接收反馈信息，充当第三方监控者来诊断网络问题。反馈功能由RTCP发送者和接收者报告执行。
　 2. 对应于一个RTP源，RTCP携带一个称作规范名字（CNAME）的固定的传输层标识。既然SSRC标识可改变，所以如果发现冲突，或程序重新启动，接收者需要用CNAME跟踪每个参加者（即CNAME也会改变）。接收者也需要CNAME 与相关RTP连接中同一个给定的连接者的几个数据流进行联系，比如用来同步音频流和视频流。媒体流的同步也要求发送者把NTP和RTP的时间戳包含到RTCP包中。
　 3.前两种功能要求所有参加者发送RTCP包，因此，为了RTP连接的参加者扩展到大规模数量，速率必须受到控制。通过让每个参加者给其它参加者发送控制包，参加者就能独立的观察到参加者的数量。该数量用来计算每个包发送的速率。
　 4.第四个可选功能是传送最小连接控制信息，如参加者辨识。最可能用在"松散控制"连接，那里参加者可以的自由进入或离开，没有成员控制或参数协调，RTCP充当通往所有参加者的方便通道，但不必支持应用的所有控制通讯要求。高级连接控制协议超出本书范围。
　 在IP组播场合应用RTP时，前3个功能是必须的，推荐用于所有情形。RTP应用设计人员必须避免使用仅在单播模式下工作的机制，那将导致无法扩展规模。
　
6.1 RTCP 包格式
　 下面定义几个携带不同控制信息的RTCP包类型：
　 SR：
　 发送方报告，来自当前活动发送者的发送、接收情况的统计信息。
　 RR：
　 接收方报告，来自非活动的发送者的对接收情况的统计信息。接收方报告与来自活动的发送者的SR相联系，这些发送者可以报告超过31个源（的信息）。
　 SDES：
　 源描述项，包括CNAME。
　 BYE：
　 表示一个参与的结束。
　 APP：
　 特定应用函数。
　 类似于RTP数据包的开头部分，每个RTCP包以固定部分开始，紧接着的是可变长结构元素，但必须以一个32位边界结束。为了使RTCP包可堆叠，需要包含队列要求和固定部分中的一个长度段。不需要插入任何分隔符可以直接将多个RTCP包连接起来，形成一个RTCP组合包，然后以单一包形式在低层协议发送。由于需要低层协议提供整体长度来决定组合包的结尾，所以在组合包中没有单个RTCP包显式计数。
　 组合包中每个RTCP包可独立处理，不需要根据包组合顺序。但末了执行协议功能，强加如下约束：
　 *接收统计（在SR或RR中）应该经常发送，只要带宽允许，因此每个周期发送的组合RTCP 包应包含报告包。
　 * 新接收者需要接收CNAME，并尽快识别源，开始联系媒介进行同步，因此每个包应该包含SDES CNAME。
　 * 出现在组合包前面的是包类型数量，其增长应该受到限制，以提高常数位数量，提高成功验证RTCP包对含错误地址RTP数据包或其他无关包的概率。
　 因此，所有RTCP包必须以至少两个RTCP包组合形式发送，推荐格式如下：
　 加密前缀（Encryption prefix）：
　 仅当组合包被加密，才需要加上一个32位随机数用于每个组合包发送。
　 SR或RR：
　 组合包中第一个RTCP包必须（如附录A2中）总为一个报告包，方便头的确认。即使没有数据发送，也没有接收到数据，也要发送一个空RR，那怕组合包中RTCP包为BYE。
　 附加RR：
　 如果报告统计的源的数目超过31，那么在初始报告包后应该有附加的RR 包。
　
　 SDES：
　 包含CNAME 项的SDES包必须包含在每个组合RTCP包中。如果特定的应用程序要求的话，其他源描述项可选，但受到带宽限制。
　 BYE或APP：
　 其它RTCP包类型可以任意顺序排列，除了携带特定的SSRC/CSRC的BYE应作为最后一个包发送，包类型出现可不止一次。
为了每个参加者的带宽能够被正确的估计，一个独立的RTP参加者在每个报告间隔应该只发送一个组合RTCP，除了在9.1中说的对每个本分加密后的组合RTCP包。如果太多的源把所有必要的RR包都装进一个组合包中，且没有超过网络中的最大传输单元，那么装到一个MTU中的子集应该在每个间隔中都被包含进来。这些子集应该通过多个时间间隔循环地被选择，这样所有的源都会被报告到。

为了分摊包中过大部分， 建议转换器或混合器从多个源组合单个RTCP包，不管合不合适。如组合包整体长度超过网络路径最大传输单元，可分成多个较短组合包用低层协议以单个包形式发送。这不会削弱RTCP带宽的估计能力。注意，每个组合包必须以SR或RR包开始。
一个执行程序应该忽略掉携带未知类型的来到的RTCP包。而附加RTCP包类型可在Internet Assigned Numbers Authority (IANA)处注册。

if encrypted: random 32-bit integer
|
|[--------- packet --------][---------- packet ----------][-packet-]
|
| receiver chunk chunk
V reports item item item item
--------------------------------------------------------------------
R[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why]
--------------------------------------------------------------------
| |
| compound packet ----------------------->|
| UDP packet ------------------------->|

#: SSRC/CSRC identifier

Figure 1: Example of an RTCP compound packet
　
　 6.2 RTCP传输间隔
　 RTP设计成允许应用程序自动按量决定连接数，范围可从几个到上千个。例如，音频会议中，数据流量是内在限制的，因为同一时刻只有一两个人说话；对组播，给定连接数据率仍是常数，独立于连接数，但控制流量不是内在限制的。如果每个参加者以固定速率发送接收报告，那么控制流量将随参加者数量线性增长，因此，速率必须按比例下降，通过动态的计算RTCP包传输的时间间隔来完成。
对每个会话来说，数据流量受到一个叫做连接带宽的集合的限制，在参加者之间被分块。这个带宽由网络保留并受网络的限制。如果没有保留值，那么会有其他基于环境的限制。这些限制建立合理的最大值给这个连接使用，同时成为连接的带宽。这个连接的带宽的选择基于一些开销或是这个连接对应的可以获得的一个预先知道的网络带宽。它有时可以独立于多媒体编码，但是编码选项可能受到这个连接带宽的限制。这个连接带宽经常是发送者期望的名义上的并发时的带宽。对于分层编码，每一层是一个拥有自己连接带宽参数的独立RTP连接。
当这个连接发起一个多媒体应用程序的时候，这个连接参数希望被被一个连接管理应用程序使用。但是多媒体应用程序可能要为连接选择的编码设置一个默认的基于单个发送者的数据带宽。这个应用程序也可能给这个带宽强加机遇多播范围的规则或是其他标准。所有的参加者需要使用同样的连接带宽值来计算相同的RTCP时间间隔。
控制流还是数据流的带宽的计算都要包含低层的传输层和网络层协议（如UDP、IP），那是正是源保留值需要知道的东西。这个应用程序也期望知道哪个协议在被使用。连路层的头不包含在计算中，因为这个包在传输时用不同的连路层头来进行封装。

　 一旦确认地址有效，如后来标记成未活动，地址的状态应仍保留，地址应继续计入共享RTCP带宽地址的总数中，时间要保证能扫描典型网络分区，建议为30分钟。注意，这仍大于RTCP报告间隔最大值的五倍。
　 这个规范定义了除必需的CNAME外的几个源描述项，如NAME（人名）和EMAIL（电子邮件地址）。它也为定义新的特定应用程序的RTCP包类型的途径。给附加信息分配控制带宽应引起注意，因为它将降低接收报告和CNAME发送的速率而损害协议的性能。建议分配给单个参加者用于携带附加信息的RTCP带宽不要超过20%。而且并没有有意让所有SDES项包含在每个应用中。
6.2.1获得连接成员个数
用一个表中的SSRC和CSRC来区分，是否有新的连接到来；在包的时间间隔中计算有没新的到达，或者是有哪个变成非活动的了

6.3RTCP包的发送和接收规则
允许在多播和多点点播环境中进行操作的的一个执行程序必须满足6.2部分的要求。
执行这些规则，参加者要通过一些状态来：
tp：一个包的最后时间
tn：一个包的下个调节传输时间
tc，pmember:已经在的参加者数目，member：估计
rtcp_bw:带宽
we_sent:前面的二个包的报告到时为真
avg_rtcp_size:所有组合包的平均长度。
Initial:还没发出包的标志位
很多规则指定都是为了统计时间间隔。
6.3.1 计算RTCP传输的时间间隔
要用一个组长度.T有以下几点决定：
1．小等于25%的成员参加连接时，T取决与这些参加者是不是发送方。
是发送方，we_send =ture,avg_trcp_size=Constant 发送者数目, 被rtcp_bw=0.25除
不是， false 0.75
the 25% fraction becomes S/(S+R) and the 75% fraction becomes R/(S+R).

2．一个连接还没发送包（initial=true）时，Tmin=2。5s 否则=5s
3. 确定值Td设置为最大
4．估计时间0.5，1.5倍的Td
5．T除以1.21828来补偿带宽转换时的算法来的值
时间间隔随机分配，时间25%分配给发送者，75%给接收者

6.3.2 初始化
Tp=0,tc=0, sender=0?,pmember=1, members=1,we_sent=false, rtcp_bw=连接带宽的确定部分 ，initial=true, avg_rtcp_size=第一个包的可能长度，tn=T,

6.3.3 接收一个RTP或者一个非BYE RTCP包
接到含不在成员表格中的SSRC的RTCP或是RTP包的时候，添加到表中，并更新member的数值
不在成员表中的RTP 包时，添加，并更新senders
收到组合包时，avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size

Packet_size 为刚刚收到的组合包的长度

6.3.4接收一个RTCP BYE 包
收到RTCP BYE，先检查成员表格中的SSRC，存在这个包，则从表中移除更新members
在检查发送者表格的SSRC，出现成员，移除，更新senders

同时要考虑其他数值如tn tc
tn = tc + (members/pmembers) * (tn - tc)
tp = tc - (members/pmembers) * (tc - tp).
6.3.5 一个SSRC超时
另外的一些连接超时的时候，这个连接就要检查临时的时间间隔及Tdeteministic,we_send=false.>Mtd=5s为超时
6.3.6 计时器终止（满）
* 获得时间间隔T
* tp + T表RTCP包发了，设置tp=tc,时间间隔也变
tp + T〉tc，没有RTCP包在发，tn=tp+T
l Pmembers=members
有RTCP包在传，initial=false, avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size

6.3.7 传一个 BYE包
6.3.8更新 we_sent
是否发RTP包
6.3.9 源描述字的带宽分配
SDES定义NAME，EMAIL等非强制性的



6. 4 发送者与接收者报告
　 RTP接收者使用RTCP报告包提供接收质量反馈，报告包根据接收者是否也是一个发送者而采用两种格式中的一种。除包类型代码外，发送者 报告与接收者报告间唯一的差别是发送者报告包含一个20个字节发送者信息段。如果某地址（源）在发出最后或前一个报告的时间间隔中发送数据包，就发布SR；否则，就发出RR。SR和RR都可以没有或包括多个接收报告块。对于同步源中的每个源都一样。自从最后一个报告后，这个接收者都是接收RTP数据包发布报告不是为列在CSRC列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。既然最大可有31个接收报告块嵌入在SR 或 RR包中，丢失包累计数差别给出间隔期间丢掉的数量，而所收到扩展的最后一个系列号的差别给出间隔期间希望发送的包数量，两者之比等于经过间隔期间包丢失百分比。如两报告连续，比值应该等于丢失段部分；否则，就不等。每秒包丢失率可通过NTP时标差除以丢失部分得到。
　 从发送者信息，第三方监控器可计算载荷平均数据速率与没收到数据间隔的平均包速率，两者比值给出平均载荷大小。如假设包丢失与包大小无关，那么特殊接收者收到的包数量给出此接收者收到的表观流量。
　
　 6. 5 SDES: 源描述RTCP包
　 SDES 包为三层结构，由头与数据块组成，数据块可以没有，也可有多个，组成项描述块所表明的源。项描述如下：
　 版本（V）、填充（P）、长度：
　 如SR包中所描述。
　 包类型（PT）：
　 8位，包含常数202，识别RTCP SDES包。
　 源计数（SC）：
　 5位，包含在SDES包中的SSRC/CSRC块数量，零值有效，但没有意义。
　 源描述项内容如下：
　 6.5.1CNAME: 规范终端标识SDES项
　 CNAME标识属性如下：
　 如发生冲突或重启程序，由于随机分配的SSRC标识可能发生变化，需要CNAME项提供从SSRC标识到仍为常量的源标识的绑定。
　 象SSRC标识，CNAME标识在RTP连接的所有参加者中应是唯一的。
　 为了提供一套相关RTP连接中某个参加者所采用的跨多媒体工具间的绑定，CNAME应固定为那个参加者。
　 为方便第三方监控，CNAME应适合程序或人员定位源。
　 6.5.2NAME：用户名称SDES项
　 这是用于描述源的真正的名称，如"John Doe, Bit Recycler, Megacorp"，可是用户想要的任意形式。对诸如会议应用，这种名称也许是参加者列表显示最适宜的形式，它将是除CNAME外发送最频繁的项目。设置可建立这样的优先级别。NAME值至少在连接期间仍希望保持为常数。它不该成为连接的所有参加者中唯一依赖。
　 6.5.3EMAIL：电子邮件地址SDES项
　 邮件地址格式由RFC822规定，如"[e-mail]"。连接期间，电子邮件仍希望保持为常数。
　 6.5.4PHONE：电话号码SDES项
　 电话号码应带有加号，代替国际接入代码，如"[phone]"即为美国电话号码。
　
　 6.5.5LOC：用户地理位置SDES项
　 根据应用，此项具有不同程度的细节。对会议应用，字符串如"Murray Hill, New Jersey"就足够了。然而，对活动标记系统，字符串如"Room 2A244, AT&T BL MH"也许就适用。细节留给实施或用户，但格式和内容可用设置指示。在连接期间，除移动主机外，LOC值期望仍保留为常数。
　 6.5.6TOOL：应用或工具名称SDES项
　 是一个字符串，表示产生流的应用的名称与版本，如"videotool 1.2"。这部分信息对调试很有用，类似于邮件或邮件系统版本SMTP头。TOOL值在连接期间仍保持常数。
　 6.5.7NOTE: 通知/状态SDES项
　 该项的推荐语法如下所述，但这些或其它语法可在设置中显式定义。NOTE 项旨在描述源当前状态的过渡信息，如"on the phone, can't talk"，或在讲座期间用于传送谈话的题目。它应该只用于携带例外信息，而不应包含在全部参加者中，因为这将降低接收报告和CNAME发送的速度，因此损害协议的性能。特殊情况下，它不应作为用户设置文件的项目，也不是自动产生。
　 当其为活动时，由于NOTE项对显示很重要，其它非CNAME项（如NAME）传输速率将会降低，结果使NOTE项占用RTCP部分带宽。若过渡信息不活跃，NOTE项继续以同样的速度重复发送几次，但以一个串长为零的字符串通知接收者。然而，如对小倍数的重复或约20-30 RTCP间隔也没有接收到，接收者也应该考虑NOTE项是不活跃的。
　6.5.8 PRIV: 专用扩展SDES项
　 该项用于定义实验或应用特定的SDES扩展，它包括由长字符串对组成的前缀，后跟填充该项其他部分和携带所需信息的字符串值。前缀长度段为8位。前缀字符串是定义PRIV项人员选择的名称，唯一对应应用接收到的其它PRIV项。应用实现者可选择使用应用名称，如有必要，外加附加子类型标识。另外，推荐其它人根据其代表的实体选择名称，然后，在实体内部协调名称的使用。
　 注意，前缀消耗了总长为255个八进制项的一些空间，因此，前缀应尽可能的短。这个设备和受到约束的RTCP带宽不应过载，其目的不在于满足所有应用的全部控制通讯要求。SDES PRIV前缀没在IANA处注册。如证实某些形式的PRIV项具有通用性， IANA应给它分配一个正式的SDES项类型，这样就不再需要前缀。这简化了应用，并提高了传输的效率。
　 6. 6 BYE：断开RTCP包
　 如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC/CSRC 标识。如果混合器关闭，它也应该发出一个BYE包，列出它所处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个8位八进制计数，后跟很多八进制文本，表示离开原因，如："camera malfunction"或"RTP loop detected"。字符串具有同样的编码，如在SDES 中所描述的。如字符串填充包至下32位边界，字符串就不以空结尾；否则，BYE包以空八进制填充。
　 6. 7 APP：定义应用的RTCP包
　 APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。
6.3 RTSP协议
　 实时流协议（RTSP）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频，的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。
　 6.3.1 简介
　 6.3.1.1 目的
　 实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交叉是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可靠传输连接以发出RTSP 请求。此外，可使用无连接传输协议，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。实时流协议在语法和操作上与HTTP/1.1类似，因此HTTP的扩展机制大都可加入RTSP。协议支持的操作如下：
　 从媒体服务器上检索媒体：
　 用户可通过HTTP或其它方法提交一个演示描述。如演示是组播，演示式就包含用于连续媒体的的组播地址和端口。如演示仅通过单播发送给用户，用户为了安全应提供目的地址。
　 媒体服务器邀请进入会议：
　 媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。
　 将媒体加到现成讲座中：
　 如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。如HTTP/1.1中类似，RTSP请求可由代理、通道与缓存处理。
　
　 6.3.1.2 协议特点
　 RTSP 特性如下：
　 可扩展性：
　 新方法和参数很容易加入RTSP。
　 易解析：
　 RTSP可由标准 HTTP或MIME解吸器解析。
　 安全：
　 RTSP使用网页安全机制。
　 独立于传输：
　 RTSP可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，可使用可靠流协议。
　 多服务器支持：
　 每个流可放在不同服务器上，用户端自动同不同服务器建立几个并发控制连接，媒体同步在传输层执行。
　 记录设备控制：
　 协议可控制记录和回放设备。
　 流控与会议开始分离：
　 仅要求会议初始化协议提供，或可用来创建唯一会议标识号。特殊情况下， SIP或H.323
　 可用来邀请服务器入会。
　 适合专业应用：
　 通过SMPTE 时标，RTSP支持帧级精度，允许远程数字编辑
　 演示描述中立：
　 协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包含一个RTSP URI。
　 代理与防火墙友好：
　 协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个"缺口"。
　 HTTP友好：
　 此处，RTSP明智的采用HTTP观念，使现在结构都可重用。结构包括Internet 内容选择平台（PICS）。由于在大多数情况下控制连续媒体需要服务器状态， RTSP不仅仅向HTTP 添加方法。
　 适当的服务器控制：
　 如用户启动一个流，他必须也可以停止一个流。
　 传输协调；
　 实际处理连续媒体流前，用户 可协调传输方法。
　 性能协调：
　 如基本特征无效，必须有一些清理机制让用户决定那种方法没生效。这允许用户提出适合的用户界面。
　 6.3.1.3扩展RTSP
　 由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同请求集。RTSP 可以如下三种方式扩展，这里以改变大小排序：
　 以新参数扩展。如用户需要拒绝通知，而方法扩展不支持，相应标记就加入要求的段中。
　 加入新方法。如信息接收者不理解请求，返回501错误代码（还未实现），发送者不应再次尝试这种方法。用户可使用OPTIONS方法查询服务器支持的方法。服务器使用公共响应头列出支持的方法。
　 定义新版本协议，允许改变所有部分。（除了协议版本号位置）
　 6.3.1.4操作模式
　 每个演示和媒体流可用RTSP URL识别。演示组成的整个演示与媒体属性由演示描述文件定义。使用HTTP或其它途径用户可获得这个文件，它没有必要保存在媒体服务器上。
　 为了说明，假设演示描述描述了多个演示，其中每个演示维持了一个公共时间轴。为简化说明，且不失一般性，假定演示描述的确包含这样一个演示。演示可包含多个媒体流。除媒体参数外，网络目标地址和端口也需要决定。下面区分几种操作模式：
　 单播：
　 以用户选择的端口号将媒体发送到RTSP请求源。
　 组播，服务器选择地址：
　 媒体服务器选择组播地址和端口，这是现场直播或准点播常用的方式。
　 组播，用户选择地址：
　 如服务器加入正在进行的组播会议，组播地址、端口和密匙由会议描述给出。
　 6.3.1.5 RTSP状态
　 RTSP控制通过单独协议发送的流，与控制通道无关。例如，RTSP控制可通过TCP连接，而数据流通过UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在连接生命期，单个媒体流可通过不同TCP连接顺序发出请求来控制。所以，服务器需要维持能联系流与RTSP请求的连接状态。RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用：
　 SETUP：
　 让服务器给流分配资源，启动RTSP连接。
　 PLAY与RECORD：
　 启动SETUP 分配流的数据传输。
　 PAUSE：
　 临时停止流，而不释放服务器资源。
　 TEARDOWN：
　 释放流的资源，RTSP连接停止。
　 标识状态的RTSP方法使用连接头段识别RTSP连接，为响应SETUP请求，服务器连
　 接产生连接标识。
　
　 6.3.1.6 与其他协议关系
　 RTSP在功能上与HTTP有重叠，与HTTP相互作用体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如，演示描述可通过HTTP和RTSP检索，这降低了浏览器的往返传递，也允许独立RTSP 服务器与用户不全依靠HTTP。
　 但是，RTSP与HTTP 的本质差别在于数据发送以不同协议进行。HTTP是不对称协议，用户发出请求，服务器作出响应。RTSP中，媒体用户和服务器都可发出请求，且其请求都是无状态的；在请求确认后很长时间内，仍可设置参数，控制媒体流。重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有价值的。
　 当大多数实时媒体使用RTP作为传输协议时，RTSP没有绑定到RTP。RTSP假设存在演示描述格式可表示包含几个媒体流的演示的静态与临时属性。
　
　 6.3.2 协议参数
　
　 6.3.3 RTSP 信息
　 RTSP是基于文本的协议，采用ISO 10646 字符集，使用UTF-8编码方案。行以CRLF中断，但接收者本身可将CR和LF解释成行终止符。基于文本的协议使以自描述方式增加可选参数更容易。由于参数的数量和命令的频率出现较低，处理效率没引起注意。如仔细研究，文本协议很容易以脚本语言（如：Tcl、Visual Basic与Perl）实现研究原型。
　 10646字符集避免敏感字符集切换，但对应用来说不可见。RTCP也采用这种编码方案。带有重要意义位的ISO 8859-1字符表示如100001x 10xxxxxx.。RTSP信息可通过任何低层传输协议携带。
　 请求包括方法、方法作用于其上的对象和进一步描述方法的参数。方法也可设计为在服务器端只需要少量或不需要状态维护。当信息体包含在信息中，信息体长度有如下因素决定：
　 不管实体头段是否出现在信息中，不包括信息体的的响应信息总以头段后第一和空行结束。
　 如出现内容长度头段，其值以字节计，表示信息体长度。如未出现头段，其值为零。
　 服务器关闭连接。
　 注意：RTSP目前并不支持HTTP/1.1"块"传输编码，需要有内容长度头。假如返回适度演示描述长度，即使动态产生，使块传输编码没有必要，服务器也应该能决定其长度。如有实体，即使必须有内容长度，且长度没显式给出，规则可确保行为合理。
　 从用户到服务器端的请求信息在第一行内包括源采用的方法、源标识和所用协议版本。RTSP定义了附加状态代码，而没有定义任何HTTP代码。
　 6.3.4 实体
　 如不受请求方法或响应状态编码限制，请求和响应信息可传输实体，实体由实体头文件和试题体组成，有些响应仅包括实体头。在此，根据谁发送实体、谁接收实体，发送者和接收者可分别指用户和服务器。
　 实体头定义实体体可选元信息，如没有实体体，指请求标识的资源。扩展头机制允许定义附加实体头段，而不用改变协议，但这些段不能假定接收者能识别。不可识别头段应被接收者忽略，而让代理转发。
　 6.3.5 连接
　 RTSP请求可以几种不同方式传送：
　 1、持久传输连接，用于多个请求/响应传输。
　 2、每个请求/响应传输一个连接。
　 3、无连接模式。
　 传输连接类型由RTSP URI来定义。对 "rtsp" 方案，需要持续连接；而"rtspu"方案，调用RTSP 请求发送，而不用建立连接。
　 不象HTTP，RTSP允许媒体服务器给媒体用户发送请求。然而，这仅在持久连接时才支持，否则媒体服务器没有可靠途径到达用户，这也是请求通过防火墙从媒体服务器传到用户的唯一途径。
　 6.3.6 方法定义
　 方法记号表示资源上执行的方法，它区分大小写。新方法可在将来定义，但不能以$开头。
　 某些防火墙设计与其他环境可能要求服务器插入RTSP方法和流数据。由于插入将使客户端和服务器操作复杂，并强加附加开销，除非有必要，应避免这样做。插入二进制数据仅在RTSP通过TCP传输时才可使用。流数据（如RTP包）用一个ASCII美圆符号封装，后跟一个一字节通道标识，其后是封装二进制数据的长度，两字节整数。流数据紧跟其后，没有CRLF，但包括高层协议头。每个$块包含一个高层协议数据单元。
　 当传输选择为RTP，RTCP信息也被服务器通过TCP连接插入。缺省情况下，RTCP包在比RTP通道高的第一个可用通道上发送。客户端可能在另一通道显式请求RTCP包 ，这可通过指定传输头插入参数中的两个通道来做到。当两个或更多流交叉时，为取得同步，需要RTCP。而且，这为当网络设置需要通过TCP控制连接透过RTP/RTCP提供了一条方便的途径，可能时，在UDP上进行传输。
　 6.3.7 流水线操作
　 支持持久连接或无连接的客户端可能给其请求排队。服务器必须以收到请求的同样顺序发出响应。如果请求不是发送给组播组，接收者就确认请求，如没有确认信息，发送者可在超过一个来回时间（RTT）后重发同一信息。
　 RTT在TCP中估计，初始值为500 ms。应用缓存最后所测量的RTT，作为将来连接的初始值。如使用一个可靠传输协议传输RTSP，请求不允许重发，RTSP应用反过来依赖低层传输提供可靠性。如两个低层可靠传输（如TCP 和RTSP）应用重发请求，有可能每个包损失导致两次重传。由于传输栈在第一次尝试到达接收着者前不会发送应用层重传，接收者也不能充分利用应用层重传。如包损失由阻塞引起，不同层的重发将使阻塞进一步恶化。时标头用来避免重发模糊性问题，避免对圆锥算法的依赖。每个请求在CSeq头中携带一个系列号，每发送一个不同请求，它就加一。如由于没有确认而重发请求，请求必须携带初始系列号。
　 实现RTSP的系统必须支持通过TCP传输RTSP ，并支持UDP。对UDP和TCP，RTSP服务器的缺省端口都是554。许多目的一致的RTSP包被打包成单个低层PDU或TCP流。RTSP数据可与RTP和RTCP包交叉。不象HTTP，RTSP信息必须包含一个内容长度头，无论信息何时包含负载。否则，RTSP包以空行结束，后跟最后一个信息头。


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协议的研究，分析流媒体服务器的一般功能和结构，给出构建一个基本的流媒体服务器的实现方案，实验证明可以同时满足多个实时和文件客户的要求,并已经应用于一个远程监控系统中。
Application
(Layer 7)
This layer supports
application
and
[/url]
end-user processes. Communication partners are identified, quality of service is identified, user
[url=http://www.webopedia.com/quick_ref/authentication.html]authentication
and privacy are considered, and any constraints on data
syntax
are identified. Everything at this layer is application-specific. This layer provides application services for file transfers,
e-mail
, and other
network

software
services.
Telnet
and
FTP
are applications that exist entirely in the application level.
Tiered application architectures
are part of this layer.
Presentation
(Layer 6)
This layer provides independence from differences in data representation (e.g.,
encryption
) by translating from application to network format, and vice versa. The presentation layer works to transform data into the form that the application layer can accept. This layer formats and encrypts data to be sent across a network, providing freedom from compatibility problems. It is sometimes called the syntax layer.
Session
(Layer 5)
This layer establishes, manages and terminates connections between applications. The session layer sets up, coordinates, and terminates conversations, exchanges, and dialogues between the applications at each end. It deals with session and connection coordination.
Transport
(Layer 4)
This layer provides
transparent
transfer of data between end systems, or hosts, and is responsible for end-to-end error recovery and
flow control
. It ensures complete data transfer.
Network
(Layer 3)
This layer provides
switching
and
routing
technologies, creating logical paths, known as
virtual circuits
, for transmitting data from
node
to node. Routing and forwarding are functions of this layer, as well as addressing,
internetworking
, error handling, congestion control and
packet
sequencing.
Data Link
(Layer 2)
At this layer, data packets are encoded and decoded into
bits
. It furnishes transmission protocol knowledge and management and handles errors in the physical layer, flow control and frame synchronization. The data link layer is divided into two sublayers: The
Media Access Control
(MAC) layer and the Logical Link Control (LLC) layer. The MAC sublayer controls how a computer on the network gains access to the data and permission to transmit it. The LLC layer controls frame synchronization, flow control and error checking.
Physical
(Layer 1)
This layer conveys the
bit
stream - electrical impulse, light or radio signal -- through the network at the electrical and mechanical level. It provides the
hardware
means of sending and receiving data on a carrier, including defining cables,
cards
and physical aspects.
Fast Ethernet
,
RS232
, and
ATM
are protocols with physical layer components.