如何开发一个app，使他自适应各种分辩率?
提示该问答中所提及的号码未经验证，请注意甄别。
展开全部
流媒体技术基础-流媒体传输协议
作者/来源：未知
实时传输协议RTP与RTCP
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配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。
6.2.1 RTP数据传输协议
RTP提供端对端网络传输功能，适合通过组播和点播传送实时数据，如视频、音频和仿真数据。RTP没有涉及资源预订和质量保证等实时服务，RTCP扩充数据传输以允许监控数据传送，提供最小的控制和识别功能。RTP与RTCP设计成独立传输和网络层。
2.1.1 RTP固定头
RTP 头格式如下：
-----------------------------------------------------------------------------------------------
|V=2|P|X| CC |M| PT | 系列号 |
-----------------------------------------------------------------------------------------------
| 时标 |
-----------------------------------------------------------------------------------------------
| 同步源标识(SSRC) |
-----------------------------------------------------------------------------------------------
| 作用标识 (CSRC) |
| .... |
-----------------------------------------------------------------------------------------------
开始12个八进制出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。
2.1.2 复用 RTP 连接
为使协议有效运行，复用点数目应减至最小。RTP中，复用由定义RTP连接的目的传输地址（网络地址与端口号）提供。例如，对音频和视频单独编码的远程会议，每个媒介被携带在单独RTP连接中，具有各自的目的传输地址。目标不在将音频和视频放在单一RTP连接中，而根据SSRC段载荷类型进行多路分解。使用同一SSRC ，而具有不同载荷类型的交叉包将带来几个问题：
如一种载荷类型在连接期间切换，没有办法识别新值将替换那一个旧值。
SSRC定义成用于标识单个计时和系列号空间。如媒体时钟速率不同，而要求不同系列号空间以说明那种载荷类型有丢包，交叉复用载荷类型将需要不同计时空间。
RTCP发送和接收报告可能仅描述每个SSRC的计时和系列号空间，而不携带载荷类型段。
RTP混合器不能将不兼容媒体流合并成一个流。
在一个RTP连接中携带多个媒介阻止几件事：使用不同网络路径或网络资源分配；接受媒介子集。
对每种媒介使用不同SSRC，但以相同RTP连接发送可避免前三个问题，但不能避免后两个问题。
2.1.3 对RTP头特定设置的修改
可以认为，现用RTP数据包头对RTP支持的所有应用类共同需要的功能集是完整的。然而，为维持ALF设计原则，头可通过改变或增加设置来裁剪，并仍允许设置无关监控和记录工具起作用。标记位与载荷类型段携带特定设置信息，但由于很多应用需要它们，否则要容纳它们，就要增加另外32位字，故允许分配在固定头中。包含这些段的八进制可通过设置重新定义以适应不同要求，如采用更多或更少标记位。如有标记位，既然设置无关监控器能观察包丢失模式和标记位间关系，我们就可以定位八进制中最重要的位。
其它特殊载荷格式（视频编码）所要求的信息应该携带在包的载荷部分。可出现在头，总是在载荷部分开始处，或在数据模式的保留值中指出。如特殊应用类需要独立载荷格式的附加功能，应用运行的设置应该定义附加固定段跟随在现存固定头SSRC之后。这些应用将能迅速而直接访问附加段，同时，与监控器和记录器无关设置仍能通过仅解释开始12个八进制处理RTP包。如证实附加功能是所有设置共同需要的，新版本RTP应该对固定头作出明确改变
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应用设计人员必须避免使用仅在单播模式下工作的机制，那将导致无法扩展规模。
6.2.2.1 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)处注册。
6.2.2.2 RTCP传输间隔
RTP设计成允许应用自动扩展，连接数可从几个到上千个。例如，音频会议中，数据流量是内在限制的，因为同一时刻只有一两个人说话；对组播，给定连接数据率仍是常数，独立于连接数，但控制流量不是内在限制的。如每个参加者以固定速率发送接收报告，控制流量将随参加者数量线性增长，因此，速率必须按比例下降。
一旦确认地址有效，如后来标记成未活动，地址的状态应仍保留，地址应继续计入共享RTCP带宽地址的总数中，时间要保证能扫描典型网络分区，建议为30分钟。注意，这仍大于RTCP报告间隔最大值的五倍。
这个规范定义了除必需的CNAME外的几个源描述项，如NAME（人名）和EMAIL（电子邮件地址）。它也为定义新特定应用RTCP包类型的途径。给附加信息分配控制带宽应引起注意，因为它将降低接收报告和CNAME发送的速率而损害协议的性能。建议分配给单个参加者用于携带附加信息的RTCP带宽不要超过20%。而且并没有有意让所有SDES项包含在每个应用中。
6.2.2.3 发送者与接收者报告
RTP接收者使用RTCP报告包提供接收质量反馈，报告包根据接收者是否是发送者而采用两种格式中的一种。除包类型代码外，发送者报告与接收者报告间唯一的差别是发送者报告包含一个20个字节发送者信息段。如某地址在发出最后或前一个报告间隔期间发送数据包，就发布SR；否则，就发出RR；SR和RR都可没有或包括多个接收报告块。发布报告不是为列在CSRC列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。既然最大可有31个接收报告块嵌入在SR 或 RR包中，
丢失包累计数差别给出间隔期间丢掉的数量，而所收到扩展的最后一个系列号的差别给出间隔期间希望发送的包数量，两者之比等于经过间隔期间包丢失百分比。如两报告连续，比值应该等于丢失段部分；否则，就不等。每秒包丢失绿可通过NTP时标差除以丢失部分得到。
从发送者信息，第三方监控器可计算载荷平均数据速率与没收到数据间隔的平均包速率，两者比值给出平均载荷大小。如假设包丢失与包大小无关，那么特殊接收者收到的包数量给出此接收者收到的表观流量。
6.2.2.4 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.Doe@megacorp.com\"。连接期间，电子邮件仍希望保持为常数。
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, can´t 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项类型，这样就不再需要前缀。这简化了应用，并提高了传输的效率。
6.2.2.5 BYE：断开RTCP包
如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC/CSRC 标识。如混合器关闭，它也应该发出一个BYE包，列出它所处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个8位八进制计数，后跟很多八进制文本，表示离开原因，如：\"camera malfunction\"或\"RTP loop detected\"。字符串具有同样的编码，如在SDES 中所描述的。如字符串填充包至下32位边界，字符串就不以空结尾；否则，BYE包以空八进制填充。
6.2.2.6 APP：定义应用的RTCP包
APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。
实时流协议RTSP
实时流协议RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。HTTP与RTSP相比，HTTP传送HTML，而RTP传送的是多媒体数据。HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。
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 方法定义
方法记号表示资源上执行的方法，它区分大小写。新方法可在将来定义，但不能以$开头。
某些防火墙设计与其
作者/来源：未知
实时传输协议RTP与RTCP
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配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。
6.2.1 RTP数据传输协议
RTP提供端对端网络传输功能，适合通过组播和点播传送实时数据，如视频、音频和仿真数据。RTP没有涉及资源预订和质量保证等实时服务，RTCP扩充数据传输以允许监控数据传送，提供最小的控制和识别功能。RTP与RTCP设计成独立传输和网络层。
2.1.1 RTP固定头
RTP 头格式如下：
-----------------------------------------------------------------------------------------------
|V=2|P|X| CC |M| PT | 系列号 |
-----------------------------------------------------------------------------------------------
| 时标 |
-----------------------------------------------------------------------------------------------
| 同步源标识(SSRC) |
-----------------------------------------------------------------------------------------------
| 作用标识 (CSRC) |
| .... |
-----------------------------------------------------------------------------------------------
开始12个八进制出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。
2.1.2 复用 RTP 连接
为使协议有效运行，复用点数目应减至最小。RTP中，复用由定义RTP连接的目的传输地址（网络地址与端口号）提供。例如，对音频和视频单独编码的远程会议，每个媒介被携带在单独RTP连接中，具有各自的目的传输地址。目标不在将音频和视频放在单一RTP连接中，而根据SSRC段载荷类型进行多路分解。使用同一SSRC ，而具有不同载荷类型的交叉包将带来几个问题：
如一种载荷类型在连接期间切换，没有办法识别新值将替换那一个旧值。
SSRC定义成用于标识单个计时和系列号空间。如媒体时钟速率不同，而要求不同系列号空间以说明那种载荷类型有丢包，交叉复用载荷类型将需要不同计时空间。
RTCP发送和接收报告可能仅描述每个SSRC的计时和系列号空间，而不携带载荷类型段。
RTP混合器不能将不兼容媒体流合并成一个流。
在一个RTP连接中携带多个媒介阻止几件事：使用不同网络路径或网络资源分配；接受媒介子集。
对每种媒介使用不同SSRC，但以相同RTP连接发送可避免前三个问题，但不能避免后两个问题。
2.1.3 对RTP头特定设置的修改
可以认为，现用RTP数据包头对RTP支持的所有应用类共同需要的功能集是完整的。然而，为维持ALF设计原则，头可通过改变或增加设置来裁剪，并仍允许设置无关监控和记录工具起作用。标记位与载荷类型段携带特定设置信息，但由于很多应用需要它们，否则要容纳它们，就要增加另外32位字，故允许分配在固定头中。包含这些段的八进制可通过设置重新定义以适应不同要求，如采用更多或更少标记位。如有标记位，既然设置无关监控器能观察包丢失模式和标记位间关系，我们就可以定位八进制中最重要的位。
其它特殊载荷格式（视频编码）所要求的信息应该携带在包的载荷部分。可出现在头，总是在载荷部分开始处，或在数据模式的保留值中指出。如特殊应用类需要独立载荷格式的附加功能，应用运行的设置应该定义附加固定段跟随在现存固定头SSRC之后。这些应用将能迅速而直接访问附加段，同时，与监控器和记录器无关设置仍能通过仅解释开始12个八进制处理RTP包。如证实附加功能是所有设置共同需要的，新版本RTP应该对固定头作出明确改变
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应用设计人员必须避免使用仅在单播模式下工作的机制，那将导致无法扩展规模。
6.2.2.1 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)处注册。
6.2.2.2 RTCP传输间隔
RTP设计成允许应用自动扩展，连接数可从几个到上千个。例如，音频会议中，数据流量是内在限制的，因为同一时刻只有一两个人说话；对组播，给定连接数据率仍是常数，独立于连接数，但控制流量不是内在限制的。如每个参加者以固定速率发送接收报告，控制流量将随参加者数量线性增长，因此，速率必须按比例下降。
一旦确认地址有效，如后来标记成未活动，地址的状态应仍保留，地址应继续计入共享RTCP带宽地址的总数中，时间要保证能扫描典型网络分区，建议为30分钟。注意，这仍大于RTCP报告间隔最大值的五倍。
这个规范定义了除必需的CNAME外的几个源描述项，如NAME（人名）和EMAIL（电子邮件地址）。它也为定义新特定应用RTCP包类型的途径。给附加信息分配控制带宽应引起注意，因为它将降低接收报告和CNAME发送的速率而损害协议的性能。建议分配给单个参加者用于携带附加信息的RTCP带宽不要超过20%。而且并没有有意让所有SDES项包含在每个应用中。
6.2.2.3 发送者与接收者报告
RTP接收者使用RTCP报告包提供接收质量反馈，报告包根据接收者是否是发送者而采用两种格式中的一种。除包类型代码外，发送者报告与接收者报告间唯一的差别是发送者报告包含一个20个字节发送者信息段。如某地址在发出最后或前一个报告间隔期间发送数据包，就发布SR；否则，就发出RR；SR和RR都可没有或包括多个接收报告块。发布报告不是为列在CSRC列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。既然最大可有31个接收报告块嵌入在SR 或 RR包中，
丢失包累计数差别给出间隔期间丢掉的数量，而所收到扩展的最后一个系列号的差别给出间隔期间希望发送的包数量，两者之比等于经过间隔期间包丢失百分比。如两报告连续，比值应该等于丢失段部分；否则，就不等。每秒包丢失绿可通过NTP时标差除以丢失部分得到。
从发送者信息，第三方监控器可计算载荷平均数据速率与没收到数据间隔的平均包速率，两者比值给出平均载荷大小。如假设包丢失与包大小无关，那么特殊接收者收到的包数量给出此接收者收到的表观流量。
6.2.2.4 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.Doe@megacorp.com\"。连接期间，电子邮件仍希望保持为常数。
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, can´t 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项类型，这样就不再需要前缀。这简化了应用，并提高了传输的效率。
6.2.2.5 BYE：断开RTCP包
如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC/CSRC 标识。如混合器关闭，它也应该发出一个BYE包，列出它所处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个8位八进制计数，后跟很多八进制文本，表示离开原因，如：\"camera malfunction\"或\"RTP loop detected\"。字符串具有同样的编码，如在SDES 中所描述的。如字符串填充包至下32位边界，字符串就不以空结尾；否则，BYE包以空八进制填充。
6.2.2.6 APP：定义应用的RTCP包
APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。
实时流协议RTSP
实时流协议RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。HTTP与RTSP相比，HTTP传送HTML，而RTP传送的是多媒体数据。HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。
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 方法定义
方法记号表示资源上执行的方法，它区分大小写。新方法可在将来定义，但不能以$开头。
某些防火墙设计与其
已赞过
已踩过<
评论
收起
你对这个回答的评价是？
展开全部
开发者们都知道在高端智能手机系统中有两种应用程序：一种是基于本地（操作系统）运行的APP；一种是基于高端机的浏览器运行的WebApp，本文将主要讲解后者。
WebApp与Native App有何区别呢？
Native App：
1、开发成本非常大。
一般使用的开发语言为JAVA、C++、Objective-C。
2、更新体验较差、同时也比较麻烦
每一次发布新的版本，都需要做版本打包，且需要用户手动更新（有些应用程序即使不需要用户手动更新，但是也需要有一个恶心的提示）。
3、非常酷
因为native app可以调用IOS中的UI控件以UI方法，它可以实现WebApp无法实现的一些非常酷的交互效果
4、Native app是被Apple认可的
Native app可以被Apple认可为一款可信任的独立软件，可以放在Apple Stroe出售，但是Web app却不行。
Web App：
1、开发成本较低
使用web开发技术就可以轻松的完成web app的开发
2、升级较简单
升级不需要通知用户，在服务端更新文件即可，用户完全没有感觉
3、维护比较轻松
和一般的web一样，维护比较简单，它其实就是一个站点
Webapp说白了就是一个针对Iphone、Android优化后的web站点，它使用的技术无非就是HTML或HTML5、CSS3、JavaScript，服务端技术JAVA、PHP、ASP。
当然，因为这些高端智能手机（Iphone、Android）的内置浏览器都是基于webkit内核的，所以在开发WEBAPP时，多数都是使用HTML5和CSS3技术做UI布局。当使用HTML5和CSS3l做UI时，若还是遵循着一般web开发中使用HTML4和CSS2那样的开发方式的话，这也就失去了WEBAPP的本质意义了，且有些效果也无法实现的，所以在此又回到了我们的主题–webapp的布局方式和技术。
哥在此说明一下，在此所说的移动平台前端开发是指针对高端智能手机（如Iphone、Android）做站点适配也就是WebApp，并非是针对普通手机开发Wap 2.0，所以在阅读本篇文章以前，你需要对webkit内核的浏览器有一定的了解，你需要对HTML5和CSS3有一定的了解。如果你已经对此有所了解，那现在就开始往下阅读吧……
1、首先我们来看看webkit内核中的一些私有的meta标签，这些meta标签在开发webapp时起到非常重要的作用
1
<meta content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0;" name="viewport" />
2
<meta content="yes" name="apple-mobile-web-app-capable" />
3
<meta content="black" name="apple-mobile-web-app-status-bar-style" />
4
<meta content="telephone=no" name="format-detection" />
第一个meta标签表示：强制让文档的宽度与设备的宽度保持1:1，并且文档最大的宽度比例是1.0，且不允许用户点击屏幕放大浏览；
第二个meta标签是iphone设备中的safari私有meta标签，它表示：允许全屏模式浏览；
第三个meta标签也是iphone的私有标签，它指定的iphone中safari顶端的状态条的样式；
第四个meta标签表示：告诉设备忽略将页面中的数字识别为电话号码
2、HTML5标签的使用
在开始编写webapp时，哥建议前端工程师使用HTML5，而放弃HTML4，因为HTML5可以实现一些HTML4中无法实现的丰富的WEB应用程序的体验，可以减少开发者很多的工作量，当然了你决定使用HTML5前，一定要对此非常熟悉，要知道HTML5的新标签的作用。比如定义一块内容或文章区域可使用section标签，定义导航条或选项卡可以直接使用nav标签等等。
3、放弃CSS float属性
在项目开发过程中可以会遇到内容排列排列显示的布局(见下图)，假如你遇见这样的视觉稿，哥建议你放弃float，可以直接使用display:block;
4、利用CSS3边框背景属性
这个按钮有圆角效果，有内发光效果还有高光效果，这样的按钮使用CSS3写是无法写出来的，当然圆角可以使用CSS3来写，但高光和内发光却无法使用CSS3编写，
这个时候你不妨使用-webkit-border-image来定义这个按钮的样式。
-webkit-border-image就个很复杂的样式属性。
5、块级化a标签
请保证将每条数据都放在一个a标签中，为何这样做？因为在触控手机上，为提升用户体验，尽可能的保证用户的可点击区域较大。
6、自适应布局模式
在编写CSS时，我不建议前端工程师把容器（不管是外层容器还是内层）的宽度定死。为达到适配各种手持设备，我建议前端工程师使用自适应布局模式（支付宝采用了自适应布局模式），因为这样做可以让你的页面在ipad、itouch、ipod、iphone、android、web safarik、chrome都能够正常的显示，你无需再次考虑设备的分辨率。
7、学会使用webkit-box
上一节，我们说过自适应布局模式，有些同学可能会问：如何在移动设备上做到完全自适应呢？很感谢webkit为display属性提供了一个webkit-box的值，它可以帮助前端工程师做到盒子模型灵活控制。
8、如何去除Android平台中对邮箱地址的识别
看过iOS webapp API的同学都知道iOS提供了一个meta标签:用于禁用iOS对页面中电话号码的自动识别。在iOS中是不自动识别邮件地址的，但在Android平台，它会自动检测邮件地址，当用户touch到这个邮件地址时，Android会弹出一个框提示用户发送邮件，如果你不想Android自动识别页面中的邮件地址，你不妨加上这样一句meta标签在head中
1
<meta content="email=no" name="format-detection" />
9、如何去除iOS和Android中的输入URL的控件条
你的老板或者PD或者交互设计师可能会要求你：能否让我们的webapp更加像nativeapp，我不想让用户看见那个输入url的控件条？
答案是可以做到的。我们可以利用一句简单的javascript代码来实现这个效果
1
setTimeout(scrollTo,0,0,0);
请注意，这句代码必须放在window.onload里才能够正常的工作，而且你的当前文档的内容高度必须是高于窗口的高度时，这句代码才能有效的执行。
10、如何禁止用户旋转设备
我曾经也想禁止用户旋转设备，也想实现像某些客户端那样：只能在肖像模式或景观模式下才能正常运行。但现在我可以很负责任的告诉你：别想了!在移动版的webkit中做不到！
至少Apple webapp API已经说到了：我们为了让用户在safari中正常的浏览网页，我们必须保证用户的设备处于任何一个方位时，safari都能够正常的显示网页内容（也就是自适应），所以我们禁止开发者阻止浏览器的orientationchange事件，看来苹果公司的出发点是正确的，苹果确实不是一般的苹果。
iOS已经禁止开发者阻止orientationchange事件，那Android呢？对不起，我没有找到任何资料说Android禁止开发者阻止浏览器orientationchange事件，但是在Android平台，确实也是阻止不了的。
11、如何检测用户是通过主屏启动你的webapp
看过Apple webapp API的同学都知道iOS为safari提供了一个将当前页面添加主屏的功能，按下iphoneipodipod touch底部工具中的小加号，或者ipad顶部左侧的小加号，就可以将当前的页面添加到设备的主屏，在设备的主屏会自动增加一个当前页面的启动图标，点击该启动图标就可以快速、便捷的启动你的webapp。从主屏启动的webapp和浏览器访问你的webapp最大的区别是它清除了浏览器上方和下方的工具条，这样你的webapp就更加像是nativeapp了，还有一个区别是window对像中的navigator子对象的一个standalone属性。iOS中浏览器直接访问站点时，navigator.standalone为false,从主屏启动webapp时，navigator.standalone为true， 我们可以通过navigator.standalone这个属性获知用户当前是否是从主屏访问我们的webapp的。
在Android中从来没有添加到主屏这回事！
12、如何关闭iOS中键盘自动大写
我们知道在iOS中，当虚拟键盘弹出时，默认情况下键盘是开启首字母大写的功能的，根据某些业务场景，可能我们需要关闭这个功能，移动版本webkit为input元素提供了autocapitalize属性，通过指定autocapitalize=”off”来关闭键盘默认首字母大写。
13、iOS中如何彻底禁止用户在新窗口打开页面
有时我们可能需要禁止用户在新窗口打开页面，我们可以使用a标签的target=”_self“来指定用户在新窗口打开，或者target属性保持空，但是你会发现iOS的用户在这个链接的上方长按3秒钟后，iOS会弹出一个列表按钮，用户通过这些按钮仍然可以在新窗口打开页面，这样的话，开发者指定的target属性就失效了，但是可以通过指定当前元素的-webkit-touch-callout样式属性为none来禁止iOS弹出这些按钮。这个技巧仅适用iOS对于Android平台则无效。
14、iOS中如何禁止用户保存图片＼复制图片
我们在第13条技巧中提到元素的-webkit-touch-callout属性，同样为一个img标签指定-webkit-touch-callout为none也会禁止设备弹出列表按钮，这样用户就无法保存＼复制你的图片了。
15、iOS中如何禁止用户选中文字
我们通过指定文字标签的-webkit-user-select属性为none便可以禁止iOS用户选中文字。
16、iOS中如何获取滚动条的值
桌面浏览器中想要获取滚动条的值是通过document.scrollTop和document.scrollLeft得到的，但在iOS中你会发现这两个属性是未定义的，为什么呢？因为在iOS中没有滚动条的概念，在Android中通过这两个属性可以正常获取到滚动条的值，那么在iOS中我们该如何获取滚动条的值呢？
通过window.scrollY和window.scrollX我们可以得到当前窗口的y轴和x轴滚动条的值。
17、如何解决盒子边框溢出
当你指定了一个块级元素时，并且为其定义了边框，设置了其宽度为100％。在移动设备开发过程中我们通常会对文本框定义为宽度100％，将其定义为块级元素以实现全屏自适应的样式，但此时你会发现，该元素的边框(左右)各1个像素会溢了文档，导致出现横向滚动条，为解决这一问题，我们可以为其添加一个特殊的样式-webkit-box-sizing:border-box;用来指定该盒子的大小包括边框的宽度。
18、如何解决Android 2.0以下平台中圆角的问题
如果大家够细心的话，在做wap站点开发时，大家应该会发现android 2.0以下的平台中问题特别的多，比如说边框圆角这个问题吧。
在对一个元素定义圆角时，为完全兼容android 2.0以下的平台，我们必须要按照以下技巧来定义边框圆角：
1＼-webkit这个前缀必须要加上（在iOS中，你可以不加，但android中一定要加）；
2＼如果对针对边框做样式定义，比如border:1px solid #000;那么-webkit-border-radius这属性必须要出现在border属性后。
3＼假如我们有这样的视觉元素，左上角和右上角是圆角时，我们必须要先定义全局的(4个角的圆角值)-webkit-border-radius:5px;然后再依次的覆盖左下角和右下角，-webkit-border-bottom-left-radius:0;-webkit-border-bottom-right-border:0;否则在android 2.0以下的平台中将全部显示直角，还有记住！-webkit这个前缀一定要加上！
19、如何解决android平台中页面无法自适应
虽然你的html和css都是完全自适应的，但有一天如果你发现你的页面在android中显示的并不是自适应的时候，首先请你确认你的head标签中是否包含以下meta标签：
1
<meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1.0,user-scalable=0;" />
如果有的话，那请你再仔细的看清楚有没有这个属性的值width=device-width，如果没有请立即加上吧！
20、如何解决iOS 4.3版本中safari对页面中5位数字的自动识别和自动添加样式
新的iOS系统也就是4.3版本，升级后对safari造成了一个bug：即使你添加了如下的meta标签，safari仍然会对页面中的5位连续的数字进行自动识别，并且将其重新渲染样式，也就是说你的css对该标签是无效的。
1
<meta name="format-detection" content="telphone=no" />
我们可以用一个比较龌龊的办法来解决。比如说支付宝wap站点中显示金额的标签，我们都做了如下改写：
1
<button class="t-balance"style="background:none;padding:0;border:0;">95009.00</button>元
WebApp与Native App有何区别呢？
Native App：
1、开发成本非常大。
一般使用的开发语言为JAVA、C++、Objective-C。
2、更新体验较差、同时也比较麻烦
每一次发布新的版本，都需要做版本打包，且需要用户手动更新（有些应用程序即使不需要用户手动更新，但是也需要有一个恶心的提示）。
3、非常酷
因为native app可以调用IOS中的UI控件以UI方法，它可以实现WebApp无法实现的一些非常酷的交互效果
4、Native app是被Apple认可的
Native app可以被Apple认可为一款可信任的独立软件，可以放在Apple Stroe出售，但是Web app却不行。
Web App：
1、开发成本较低
使用web开发技术就可以轻松的完成web app的开发
2、升级较简单
升级不需要通知用户，在服务端更新文件即可，用户完全没有感觉
3、维护比较轻松
和一般的web一样，维护比较简单，它其实就是一个站点
Webapp说白了就是一个针对Iphone、Android优化后的web站点，它使用的技术无非就是HTML或HTML5、CSS3、JavaScript，服务端技术JAVA、PHP、ASP。
当然，因为这些高端智能手机（Iphone、Android）的内置浏览器都是基于webkit内核的，所以在开发WEBAPP时，多数都是使用HTML5和CSS3技术做UI布局。当使用HTML5和CSS3l做UI时，若还是遵循着一般web开发中使用HTML4和CSS2那样的开发方式的话，这也就失去了WEBAPP的本质意义了，且有些效果也无法实现的，所以在此又回到了我们的主题–webapp的布局方式和技术。
哥在此说明一下，在此所说的移动平台前端开发是指针对高端智能手机（如Iphone、Android）做站点适配也就是WebApp，并非是针对普通手机开发Wap 2.0，所以在阅读本篇文章以前，你需要对webkit内核的浏览器有一定的了解，你需要对HTML5和CSS3有一定的了解。如果你已经对此有所了解，那现在就开始往下阅读吧……
1、首先我们来看看webkit内核中的一些私有的meta标签，这些meta标签在开发webapp时起到非常重要的作用
1
<meta content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0;" name="viewport" />
2
<meta content="yes" name="apple-mobile-web-app-capable" />
3
<meta content="black" name="apple-mobile-web-app-status-bar-style" />
4
<meta content="telephone=no" name="format-detection" />
第一个meta标签表示：强制让文档的宽度与设备的宽度保持1:1，并且文档最大的宽度比例是1.0，且不允许用户点击屏幕放大浏览；
第二个meta标签是iphone设备中的safari私有meta标签，它表示：允许全屏模式浏览；
第三个meta标签也是iphone的私有标签，它指定的iphone中safari顶端的状态条的样式；
第四个meta标签表示：告诉设备忽略将页面中的数字识别为电话号码
2、HTML5标签的使用
在开始编写webapp时，哥建议前端工程师使用HTML5，而放弃HTML4，因为HTML5可以实现一些HTML4中无法实现的丰富的WEB应用程序的体验，可以减少开发者很多的工作量，当然了你决定使用HTML5前，一定要对此非常熟悉，要知道HTML5的新标签的作用。比如定义一块内容或文章区域可使用section标签，定义导航条或选项卡可以直接使用nav标签等等。
3、放弃CSS float属性
在项目开发过程中可以会遇到内容排列排列显示的布局(见下图)，假如你遇见这样的视觉稿，哥建议你放弃float，可以直接使用display:block;
4、利用CSS3边框背景属性
这个按钮有圆角效果，有内发光效果还有高光效果，这样的按钮使用CSS3写是无法写出来的，当然圆角可以使用CSS3来写，但高光和内发光却无法使用CSS3编写，
这个时候你不妨使用-webkit-border-image来定义这个按钮的样式。
-webkit-border-image就个很复杂的样式属性。
5、块级化a标签
请保证将每条数据都放在一个a标签中，为何这样做？因为在触控手机上，为提升用户体验，尽可能的保证用户的可点击区域较大。
6、自适应布局模式
在编写CSS时，我不建议前端工程师把容器（不管是外层容器还是内层）的宽度定死。为达到适配各种手持设备，我建议前端工程师使用自适应布局模式（支付宝采用了自适应布局模式），因为这样做可以让你的页面在ipad、itouch、ipod、iphone、android、web safarik、chrome都能够正常的显示，你无需再次考虑设备的分辨率。
7、学会使用webkit-box
上一节，我们说过自适应布局模式，有些同学可能会问：如何在移动设备上做到完全自适应呢？很感谢webkit为display属性提供了一个webkit-box的值，它可以帮助前端工程师做到盒子模型灵活控制。
8、如何去除Android平台中对邮箱地址的识别
看过iOS webapp API的同学都知道iOS提供了一个meta标签:用于禁用iOS对页面中电话号码的自动识别。在iOS中是不自动识别邮件地址的，但在Android平台，它会自动检测邮件地址，当用户touch到这个邮件地址时，Android会弹出一个框提示用户发送邮件，如果你不想Android自动识别页面中的邮件地址，你不妨加上这样一句meta标签在head中
1
<meta content="email=no" name="format-detection" />
9、如何去除iOS和Android中的输入URL的控件条
你的老板或者PD或者交互设计师可能会要求你：能否让我们的webapp更加像nativeapp，我不想让用户看见那个输入url的控件条？
答案是可以做到的。我们可以利用一句简单的javascript代码来实现这个效果
1
setTimeout(scrollTo,0,0,0);
请注意，这句代码必须放在window.onload里才能够正常的工作，而且你的当前文档的内容高度必须是高于窗口的高度时，这句代码才能有效的执行。
10、如何禁止用户旋转设备
我曾经也想禁止用户旋转设备，也想实现像某些客户端那样：只能在肖像模式或景观模式下才能正常运行。但现在我可以很负责任的告诉你：别想了!在移动版的webkit中做不到！
至少Apple webapp API已经说到了：我们为了让用户在safari中正常的浏览网页，我们必须保证用户的设备处于任何一个方位时，safari都能够正常的显示网页内容（也就是自适应），所以我们禁止开发者阻止浏览器的orientationchange事件，看来苹果公司的出发点是正确的，苹果确实不是一般的苹果。
iOS已经禁止开发者阻止orientationchange事件，那Android呢？对不起，我没有找到任何资料说Android禁止开发者阻止浏览器orientationchange事件，但是在Android平台，确实也是阻止不了的。
11、如何检测用户是通过主屏启动你的webapp
看过Apple webapp API的同学都知道iOS为safari提供了一个将当前页面添加主屏的功能，按下iphoneipodipod touch底部工具中的小加号，或者ipad顶部左侧的小加号，就可以将当前的页面添加到设备的主屏，在设备的主屏会自动增加一个当前页面的启动图标，点击该启动图标就可以快速、便捷的启动你的webapp。从主屏启动的webapp和浏览器访问你的webapp最大的区别是它清除了浏览器上方和下方的工具条，这样你的webapp就更加像是nativeapp了，还有一个区别是window对像中的navigator子对象的一个standalone属性。iOS中浏览器直接访问站点时，navigator.standalone为false,从主屏启动webapp时，navigator.standalone为true， 我们可以通过navigator.standalone这个属性获知用户当前是否是从主屏访问我们的webapp的。
在Android中从来没有添加到主屏这回事！
12、如何关闭iOS中键盘自动大写
我们知道在iOS中，当虚拟键盘弹出时，默认情况下键盘是开启首字母大写的功能的，根据某些业务场景，可能我们需要关闭这个功能，移动版本webkit为input元素提供了autocapitalize属性，通过指定autocapitalize=”off”来关闭键盘默认首字母大写。
13、iOS中如何彻底禁止用户在新窗口打开页面
有时我们可能需要禁止用户在新窗口打开页面，我们可以使用a标签的target=”_self“来指定用户在新窗口打开，或者target属性保持空，但是你会发现iOS的用户在这个链接的上方长按3秒钟后，iOS会弹出一个列表按钮，用户通过这些按钮仍然可以在新窗口打开页面，这样的话，开发者指定的target属性就失效了，但是可以通过指定当前元素的-webkit-touch-callout样式属性为none来禁止iOS弹出这些按钮。这个技巧仅适用iOS对于Android平台则无效。
14、iOS中如何禁止用户保存图片＼复制图片
我们在第13条技巧中提到元素的-webkit-touch-callout属性，同样为一个img标签指定-webkit-touch-callout为none也会禁止设备弹出列表按钮，这样用户就无法保存＼复制你的图片了。
15、iOS中如何禁止用户选中文字
我们通过指定文字标签的-webkit-user-select属性为none便可以禁止iOS用户选中文字。
16、iOS中如何获取滚动条的值
桌面浏览器中想要获取滚动条的值是通过document.scrollTop和document.scrollLeft得到的，但在iOS中你会发现这两个属性是未定义的，为什么呢？因为在iOS中没有滚动条的概念，在Android中通过这两个属性可以正常获取到滚动条的值，那么在iOS中我们该如何获取滚动条的值呢？
通过window.scrollY和window.scrollX我们可以得到当前窗口的y轴和x轴滚动条的值。
17、如何解决盒子边框溢出
当你指定了一个块级元素时，并且为其定义了边框，设置了其宽度为100％。在移动设备开发过程中我们通常会对文本框定义为宽度100％，将其定义为块级元素以实现全屏自适应的样式，但此时你会发现，该元素的边框(左右)各1个像素会溢了文档，导致出现横向滚动条，为解决这一问题，我们可以为其添加一个特殊的样式-webkit-box-sizing:border-box;用来指定该盒子的大小包括边框的宽度。
18、如何解决Android 2.0以下平台中圆角的问题
如果大家够细心的话，在做wap站点开发时，大家应该会发现android 2.0以下的平台中问题特别的多，比如说边框圆角这个问题吧。
在对一个元素定义圆角时，为完全兼容android 2.0以下的平台，我们必须要按照以下技巧来定义边框圆角：
1＼-webkit这个前缀必须要加上（在iOS中，你可以不加，但android中一定要加）；
2＼如果对针对边框做样式定义，比如border:1px solid #000;那么-webkit-border-radius这属性必须要出现在border属性后。
3＼假如我们有这样的视觉元素，左上角和右上角是圆角时，我们必须要先定义全局的(4个角的圆角值)-webkit-border-radius:5px;然后再依次的覆盖左下角和右下角，-webkit-border-bottom-left-radius:0;-webkit-border-bottom-right-border:0;否则在android 2.0以下的平台中将全部显示直角，还有记住！-webkit这个前缀一定要加上！
19、如何解决android平台中页面无法自适应
虽然你的html和css都是完全自适应的，但有一天如果你发现你的页面在android中显示的并不是自适应的时候，首先请你确认你的head标签中是否包含以下meta标签：
1
<meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1.0,user-scalable=0;" />
如果有的话，那请你再仔细的看清楚有没有这个属性的值width=device-width，如果没有请立即加上吧！
20、如何解决iOS 4.3版本中safari对页面中5位数字的自动识别和自动添加样式
新的iOS系统也就是4.3版本，升级后对safari造成了一个bug：即使你添加了如下的meta标签，safari仍然会对页面中的5位连续的数字进行自动识别，并且将其重新渲染样式，也就是说你的css对该标签是无效的。
1
<meta name="format-detection" content="telphone=no" />
我们可以用一个比较龌龊的办法来解决。比如说支付宝wap站点中显示金额的标签，我们都做了如下改写：
1
<button class="t-balance"style="background:none;padding:0;border:0;">95009.00</button>元
已赞过
已踩过<
你对这个回答的评价是？
展开全部
实时传输协议RTP与RTCP
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配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。
6.2.1 RTP数据传输协议
RTP提供端对端网络传输功能，适合通过组播和点播传送实时数据，如视频、音频和仿真数据。RTP没有涉及资源预订和质量保证等实时服务，RTCP扩充数据传输以允许监控数据传送，提供最小的控制和识别功能。RTP与RTCP设计成独立传输和网络层。
2.1.1 RTP固定头
RTP 头格式如下：
-----------------------------------------------------------------------------------------------
|V=2|P|X| CC |M| PT | 系列号 |
-----------------------------------------------------------------------------------------------
| 时标 |
-----------------------------------------------------------------------------------------------
| 同步源标识(SSRC) |
-----------------------------------------------------------------------------------------------
| 作用标识 (CSRC) |
| .... |
-----------------------------------------------------------------------------------------------
开始12个八进制出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。
2.1.2 复用 RTP 连接
为使协议有效运行，复用点数目应减至最小。RTP中，复用由定义RTP连接的目的传输地址（网络地址与端口号）提供。例如，对音频和视频单独编码的远程会议，每个媒介被携带在单独RTP连接中，具有各自的目的传输地址。目标不在将音频和视频放在单一RTP连接中，而根据SSRC段载荷类型进行多路分解。使用同一SSRC ，而具有不同载荷类型的交叉包将带来几个问题：
如一种载荷类型在连接期间切换，没有办法识别新值将替换那一个旧值。
SSRC定义成用于标识单个计时和系列号空间。如媒体时钟速率不同，而要求不同系列号空间以说明那种载荷类型有丢包，交叉复用载荷类型将需要不同计时空间。
RTCP发送和接收报告可能仅描述每个SSRC的计时和系列号空间，而不携带载荷类型段。
RTP混合器不能将不兼容媒体流合并成一个流。
在一个RTP连接中携带多个媒介阻止几件事：使用不同网络路径或网络资源分配；接受媒介子集。
对每种媒介使用不同SSRC，但以相同RTP连接发送可避免前三个问题，但不能避免后两个问题。
2.1.3 对RTP头特定设置的修改
可以认为，现用RTP数据包头对RTP支持的所有应用类共同需要的功能集是完整的。然而，为维持ALF设计原则，头可通过改变或增加设置来裁剪，并仍允许设置无关监控和记录工具起作用。标记位与载荷类型段携带特定设置信息，但由于很多应用需要它们，否则要容纳它们，就要增加另外32位字，故允许分配在固定头中。包含这些段的八进制可通过设置重新定义以适应不同要求，如采用更多或更少标记位。如有标记位，既然设置无关监控器能观察包丢失模式和标记位间关系，我们就可以定位八进制中最重要的位。
其它特殊载荷格式（视频编码）所要求的信息应该携带在包的载荷部分。可出现在头，总是在载荷部分开始处，或在数据模式的保留值中指出。如特殊应用类需要独立载荷格式的附加功能，应用运行的设置应该定义附加固定段跟随在现存固定头SSRC之后。这些应用将能迅速而直接访问附加段，同时，与监控器和记录器无关设置仍能通过仅解释开始12个八进制处理RTP包。如证实附加功能是所有设置共同需要的，新版本RTP应该对固定头作出明确改变
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应用设计人员必须避免使用仅在单播模式下工作的机制，那将导致无法扩展规模。
6.2.2.1 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)处注册。
6.2.2.2 RTCP传输间隔
RTP设计成允许应用自动扩展，连接数可从几个到上千个。例如，音频会议中，数据流量是内在限制的，因为同一时刻只有一两个人说话；对组播，给定连接数据率仍是常数，独立于连接数，但控制流量不是内在限制的。如每个参加者以固定速率发送接收报告，控制流量将随参加者数量线性增长，因此，速率必须按比例下降。
一旦确认地址有效，如后来标记成未活动，地址的状态应仍保留，地址应继续计入共享RTCP带宽地址的总数中，时间要保证能扫描典型网络分区，建议为30分钟。注意，这仍大于RTCP报告间隔最大值的五倍。
这个规范定义了除必需的CNAME外的几个源描述项，如NAME（人名）和EMAIL（电子邮件地址）。它也为定义新特定应用RTCP包类型的途径。给附加信息分配控制带宽应引起注意，因为它将降低接收报告和CNAME发送的速率而损害协议的性能。建议分配给单个参加者用于携带附加信息的RTCP带宽不要超过20%。而且并没有有意让所有SDES项包含在每个应用中。
6.2.2.3 发送者与接收者报告
RTP接收者使用RTCP报告包提供接收质量反馈，报告包根据接收者是否是发送者而采用两种格式中的一种。除包类型代码外，发送者报告与接收者报告间唯一的差别是发送者报告包含一个20个字节发送者信息段。如某地址在发出最后或前一个报告间隔期间发送数据包，就发布SR；否则，就发出RR；SR和RR都可没有或包括多个接收报告块。发布报告不是为列在CSRC列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。既然最大可有31个接收报告块嵌入在SR 或 RR包中，
丢失包累计数差别给出间隔期间丢掉的数量，而所收到扩展的最后一个系列号的差别给出间隔期间希望发送的包数量，两者之比等于经过间隔期间包丢失百分比。如两报告连续，比值应该等于丢失段部分；否则，就不等。每秒包丢失绿可通过NTP时标差除以丢失部分得到。
从发送者信息，第三方监控器可计算载荷平均数据速率与没收到数据间隔的平均包速率，两者比值给出平均载荷大小。如假设包丢失与包大小无关，那么特殊接收者收到的包数量给出此接收者收到的表观流量。
6.2.2.4 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.Doe@megacorp.com\"。连接期间，电子邮件仍希望保持为常数。
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, can´t 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项类型，这样就不再需要前缀。这简化了应用，并提高了传输的效率。
6.2.2.5 BYE：断开RTCP包
如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC/CSRC 标识。如混合器关闭，它也应该发出一个BYE包，列出它所处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个8位八进制计数，后跟很多八进制文本，表示离开原因，如：\"camera malfunction\"或\"RTP loop detected\"。字符串具有同样的编码，如在SDES 中所描述的。如字符串填充包至下32位边界，字符串就不以空结尾；否则，BYE包以空八进制填充。
6.2.2.6 APP：定义应用的RTCP包
APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。
实时流协议RTSP
实时流协议RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。HTTP与RTSP相比，HTTP传送HTML，而RTP传送的是多媒体数据。HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。
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.6 方法定义
方法记号表示资源上执行的方法，它区分大小写。新方法可在将来定义，但不能以$开头。
某些防火墙设计与其
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配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。
6.2.1 RTP数据传输协议
RTP提供端对端网络传输功能，适合通过组播和点播传送实时数据，如视频、音频和仿真数据。RTP没有涉及资源预订和质量保证等实时服务，RTCP扩充数据传输以允许监控数据传送，提供最小的控制和识别功能。RTP与RTCP设计成独立传输和网络层。
2.1.1 RTP固定头
RTP 头格式如下：
-----------------------------------------------------------------------------------------------
|V=2|P|X| CC |M| PT | 系列号 |
-----------------------------------------------------------------------------------------------
| 时标 |
-----------------------------------------------------------------------------------------------
| 同步源标识(SSRC) |
-----------------------------------------------------------------------------------------------
| 作用标识 (CSRC) |
| .... |
-----------------------------------------------------------------------------------------------
开始12个八进制出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。
2.1.2 复用 RTP 连接
为使协议有效运行，复用点数目应减至最小。RTP中，复用由定义RTP连接的目的传输地址（网络地址与端口号）提供。例如，对音频和视频单独编码的远程会议，每个媒介被携带在单独RTP连接中，具有各自的目的传输地址。目标不在将音频和视频放在单一RTP连接中，而根据SSRC段载荷类型进行多路分解。使用同一SSRC ，而具有不同载荷类型的交叉包将带来几个问题：
如一种载荷类型在连接期间切换，没有办法识别新值将替换那一个旧值。
SSRC定义成用于标识单个计时和系列号空间。如媒体时钟速率不同，而要求不同系列号空间以说明那种载荷类型有丢包，交叉复用载荷类型将需要不同计时空间。
RTCP发送和接收报告可能仅描述每个SSRC的计时和系列号空间，而不携带载荷类型段。
RTP混合器不能将不兼容媒体流合并成一个流。
在一个RTP连接中携带多个媒介阻止几件事：使用不同网络路径或网络资源分配；接受媒介子集。
对每种媒介使用不同SSRC，但以相同RTP连接发送可避免前三个问题，但不能避免后两个问题。
2.1.3 对RTP头特定设置的修改
可以认为，现用RTP数据包头对RTP支持的所有应用类共同需要的功能集是完整的。然而，为维持ALF设计原则，头可通过改变或增加设置来裁剪，并仍允许设置无关监控和记录工具起作用。标记位与载荷类型段携带特定设置信息，但由于很多应用需要它们，否则要容纳它们，就要增加另外32位字，故允许分配在固定头中。包含这些段的八进制可通过设置重新定义以适应不同要求，如采用更多或更少标记位。如有标记位，既然设置无关监控器能观察包丢失模式和标记位间关系，我们就可以定位八进制中最重要的位。
其它特殊载荷格式（视频编码）所要求的信息应该携带在包的载荷部分。可出现在头，总是在载荷部分开始处，或在数据模式的保留值中指出。如特殊应用类需要独立载荷格式的附加功能，应用运行的设置应该定义附加固定段跟随在现存固定头SSRC之后。这些应用将能迅速而直接访问附加段，同时，与监控器和记录器无关设置仍能通过仅解释开始12个八进制处理RTP包。如证实附加功能是所有设置共同需要的，新版本RTP应该对固定头作出明确改变
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应用设计人员必须避免使用仅在单播模式下工作的机制，那将导致无法扩展规模。
6.2.2.1 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)处注册。
6.2.2.2 RTCP传输间隔
RTP设计成允许应用自动扩展，连接数可从几个到上千个。例如，音频会议中，数据流量是内在限制的，因为同一时刻只有一两个人说话；对组播，给定连接数据率仍是常数，独立于连接数，但控制流量不是内在限制的。如每个参加者以固定速率发送接收报告，控制流量将随参加者数量线性增长，因此，速率必须按比例下降。
一旦确认地址有效，如后来标记成未活动，地址的状态应仍保留，地址应继续计入共享RTCP带宽地址的总数中，时间要保证能扫描典型网络分区，建议为30分钟。注意，这仍大于RTCP报告间隔最大值的五倍。
这个规范定义了除必需的CNAME外的几个源描述项，如NAME（人名）和EMAIL（电子邮件地址）。它也为定义新特定应用RTCP包类型的途径。给附加信息分配控制带宽应引起注意，因为它将降低接收报告和CNAME发送的速率而损害协议的性能。建议分配给单个参加者用于携带附加信息的RTCP带宽不要超过20%。而且并没有有意让所有SDES项包含在每个应用中。
6.2.2.3 发送者与接收者报告
RTP接收者使用RTCP报告包提供接收质量反馈，报告包根据接收者是否是发送者而采用两种格式中的一种。除包类型代码外，发送者报告与接收者报告间唯一的差别是发送者报告包含一个20个字节发送者信息段。如某地址在发出最后或前一个报告间隔期间发送数据包，就发布SR；否则，就发出RR；SR和RR都可没有或包括多个接收报告块。发布报告不是为列在CSRC列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。既然最大可有31个接收报告块嵌入在SR 或 RR包中，
丢失包累计数差别给出间隔期间丢掉的数量，而所收到扩展的最后一个系列号的差别给出间隔期间希望发送的包数量，两者之比等于经过间隔期间包丢失百分比。如两报告连续，比值应该等于丢失段部分；否则，就不等。每秒包丢失绿可通过NTP时标差除以丢失部分得到。
从发送者信息，第三方监控器可计算载荷平均数据速率与没收到数据间隔的平均包速率，两者比值给出平均载荷大小。如假设包丢失与包大小无关，那么特殊接收者收到的包数量给出此接收者收到的表观流量。
6.2.2.4 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.Doe@megacorp.com\"。连接期间，电子邮件仍希望保持为常数。
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, can´t 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项类型，这样就不再需要前缀。这简化了应用，并提高了传输的效率。
6.2.2.5 BYE：断开RTCP包
如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC/CSRC 标识。如混合器关闭，它也应该发出一个BYE包，列出它所处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个8位八进制计数，后跟很多八进制文本，表示离开原因，如：\"camera malfunction\"或\"RTP loop detected\"。字符串具有同样的编码，如在SDES 中所描述的。如字符串填充包至下32位边界，字符串就不以空结尾；否则，BYE包以空八进制填充。
6.2.2.6 APP：定义应用的RTCP包
APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。
实时流协议RTSP
实时流协议RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。HTTP与RTSP相比，HTTP传送HTML，而RTP传送的是多媒体数据。HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。
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.6 方法定义
方法记号表示资源上执行的方法，它区分大小写。新方法可在将来定义，但不能以$开头。
某些防火墙设计与其
已赞过
已踩过<
评论
收起
你对这个回答的评价是？
展开全部
要开发手机app软件：
1、要有可供开发的软件，可以通过下载得到。
2、要有电脑。安装这些开发工具。
3、要学会软件开发的语言。java等。
软件开发的大致流程是：
1、需求分析。确定要开发某一款软件的同时要对需求进行分析，开发的app有实际实用意义才可以。
2、开发者需要对软件系统进行概要设计，即系统设计。概要设计需要对软件系统的设计进行考虑，包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为软件的详细设计提供基础。
3、详细开发，在概要设计的基础上详细开发。在详细设计中，描述实现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系，需要说明软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑，以便进行编码和测试。
4、测试以及软件交付。
1、要有可供开发的软件，可以通过下载得到。
2、要有电脑。安装这些开发工具。
3、要学会软件开发的语言。java等。
软件开发的大致流程是：
1、需求分析。确定要开发某一款软件的同时要对需求进行分析，开发的app有实际实用意义才可以。
2、开发者需要对软件系统进行概要设计，即系统设计。概要设计需要对软件系统的设计进行考虑，包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为软件的详细设计提供基础。
3、详细开发，在概要设计的基础上详细开发。在详细设计中，描述实现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系，需要说明软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑，以便进行编码和测试。
4、测试以及软件交付。
已赞过
已踩过<
评论
收起
你对这个回答的评价是？
更多回答（2）
推荐律师服务：
若未解决您的问题，请您详细描述您的问题，通过百度律临进行免费专业咨询
