流媒体传输协议
在基于IP的网络中，用于多媒体数据实时传输的协议通常有四种，即资源预留协议(Resource Reservation Protocol , RSVP)、实时流协议(Real-TimeStreaming Protocol, RTSP)和实时传输协议(Real-Time Transport Protocol, RTP)及实时控制协议(Real-Time Control Protocol, RTCP) 。
RSVP被主机用来为特定应用流向网络请求一定的服务质量(QoS)[5]，它也被路由器用来在节点间传送这种服务质量请求，从而建立能提供特定服务质量的状态，并维护这种状态。资源预留协议最终将在数据流的路径上预留相应的资源(主要包括内存资源和CPU资源)。
实时流协议RTSP是由Real Networks和Netscape共同提出的，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。与HTTP相比，HTTP传送HTML，而RTP传送的是多媒体数据。HTTP请求由客户机发出，服务器响应请求;使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。
RTP被定义为在一对一或一对多传输的情况下工作，其目的是提供时间信息和实现流同步。RTP通常使用UDP来传送数据，它本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。RTCP和RTP一起提供流量控制和拥塞控制服务，它们配合使用，能够以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。
流媒体协议栈如下图所示：
图1流媒体协议栈‘”
Fig. 1 Streaming video protocol stack
在发送方的数据面，压缩且经过ASF编码的视频数据被读出并在RTP/RTCP/RTSP层上打包，提供定时和同步信息以及包的序列号。然后把这些打包的RTP数据流发送到UDP/TCP 层和IP层，得到的IP包在网络上传输。在接收方则按照相反的方向处理。在控制面，RTCP 包和RTSP包在UDP/TCP层上复用，并且被送到IP层，以便通过网络传输[4]
1. 1、RTP协议
1.1.1、RTP固定头域，RTP头格式如下：
图2 RTP头格式[5]
Fig. 2 RTP head format
头12个字节在每个RTP包中都有，而CSRC标识列表仅在有混合器插入的时
候才有。各段具体意义如下:
1.版本(V): 2bit
RTP版本信息。目前版本是2。 (RTP第一版草案是版本1，最初应用在“vat"音频工具中的是第0版)
2.填充位(P): l bit
如果填充位置1，末尾有一个或者多个附加的非有效载荷的填充字节。填充的最后一个字节是该忽略的填充数目，包括本身所占一个字节。填充在按照固定块大小加密的加密算法中或者在低层的协议数据单元中装载几个RTP包时可能需要。
3.扩展位(X): lbit
如果扩展位置1，固定头后必须跟了一个头扩展。
4. CSRC计数(CO: Obit
CSRC计数包含了紧跟在固定头后的CSRC标识符的个数。
5.标记(M) : 1 bit
在序言中定义了该标记的具体解释，目的是允许重要事件在包流中标记l止来。序言可以定义附加的标记位，或者通过改变有效载荷类型域中的数据位来指示没有标记位。
6.有效载荷类型(PT) : 7bit
定义RTP有效载荷的格式，通过应用程序定义具体的说明。序言可以指定和有效载荷格式相对应的有效载荷码的默认静态影像码。附加的有效载荷码可以通过非RTP方式动态定义。在RFC 3551中定义了一系列音频和视频的默认映射初集。会话中，RTP元可以修改有效载荷的类型，但是该域不能用于复用单独的媒体流。
对于有效载荷类型无法识别的数据包，接收方一律忽略。
7.序列号(Sequence Number) : 16bit
每发送一个RTP数据包序列号就增加1，这样接收方可以检测到数据包的丢失重新保存包序列。序列号的初始值是随机的，这样可以加大被人窃取攻击的难度。
8.时间戳(Timestamp) : 32bit
时间戳反映了RTP数据包的第一个字节的采样信息。采样信息由单调、线性的时钟导出，允许同步与抖动时间计算。时钟必须有足够分辨率，满足所需同步和测定包到达抖动精度。时钟频率依靠有效载荷中装载的数据的格式，在序言中或者定义格式的有效载荷格式说明中静态定义，或者也可以通过非RTP方式动态定义有效载荷的格式。如果RTP包是周期生成的，名义上的采样信息就通过采样时钟决定，而不是读一次系统时钟。例如，对于固定速率的音频每个采样周期时间戳就增加一。如果音频应用程序读一次覆盖了输入设备的160个采样周期，每读一块这样的数据块，时间戳就增加160，而不管这一块是在一个包中传输还是被丢弃了。
像序列号一样，时间戳的初始值也应该是随机的。如果几个连续的RTP包在逻辑上是同时生成的就具有相同的时间戳，比如同一个视频帧。如果数据不是以采集顺序发送，像MPEG插入的视频帧，连续RTP包包含的时间戳可能不是单调的。
源自不同的媒体流的RTP时间戳可能以不同的速率，单独的随机的偏移步进。因此，尽管由这些时间戳就足以重建一个单独流的时间，直接比较从不同的媒体源的RTP时间戮对于同步来说效率不高。相反，对于每个媒体RTP时间戮和采样间隔是通过参考的时钟配对关联起来的，这个参考时钟代表了和RTP时间戮相对应的数据的采样时间。所有的媒体都共享参考时钟来达到同步。不是每个数据包中都传输了时间戮配对信息，而是在更低速率的RTCP SR包中传输。
采样间隔(instant)的选择目的是RTP时间戳的参考，因为已知传输端点对于所有的媒体信息是一个通常的定义，独立于编码延迟或者其他处理。目的是允许所有的媒体的同步描述都在同一时刻采样。
9. SSRC: 32bit
SSRC段定义了同步源。标识应该是随机选择的，防止在同一个RTP会话中有两个同名的同步源。尽管多个源选择相同的标识的可能性是很低的，所有的RTP实现都必须具有检测和防止碰撞机制。如果源改变了源传输地址，就必须选择一个新的SSRC标识防止被解释为循环源。
10. CSRC列表:0到15项，每个项都32bit
CSRC列表定义了该包中的有效载荷的所有源的标识。CC域给出标识的数量。如果有多于15个作用源(contributing source)，只能标识出其中的15个。CSRC标识由混合器(mixer)加入，使用作用源的SSRC标识。例如，对于音频包来说所有的被混合生成一个包的SSRC 都被列出来了。
1.1.2、复用RTP会话
为了使协议有效运行，应该降低复用点的数量，正像集合层处理设计规则(10)描述的那样。在RTP中，复用是由多个目标传输地址提供(网址和端口号)，每个RTP会话都有不同的传输地址。例如，有单独编码的音频和视频媒体组成的远程电信会议中，每个媒体都用单独的RTP会话来携带，而且有自己的目标传输地址。单独的音频和视频数据流不能用相同的RTP会话携带，分解复用是基于有效载荷
类型或者SSRC载荷类型的。
1.1.3 RTP头的序言特定修改
现在的RTP数据包的头完全符合所有的RTP可能支持的应用程序类型的通用
功能。然而，为了和ALF设计规则相一致，头可以在允许序言独立监视和记录工
具的情况下，通过修改或者在序言说明中适当的附加信息进行功能裁减。
标记位和有效载荷类型域含有序言说明信息，但是它们是放在固定头里的，因为很多应
用程序都要用着它们，不然的话就不得不为了装载它们而附加另外32bit字。含有这些域的字节可以在序言中重新定义来满足不同的需要，例如更多或者更少的标记位。如果有标识位，其中的一位必须放到这个字节的最高位，因为独立于序言的监视器可能能够检测出包损失格式和标识位的关系。
特定有效载荷格式的附加信息，例如编码，应该放在包的有效载荷段中。可以放在有效载荷段起始的头里，也可以用数据格式的一个保留值来指示。
如果特定类型的应用程序需要独立于有效载荷格式的附加功能，那些应用程序运行所符合的序言应该在现存的头的紧跟SSRC域后附加固定域。这些程序能够迅速直接访问附加域，而独立于序言的监视器或者记录器也能通过解析头12个字节信息就处理RTP包。
如果在所有的序言中都附加了相同的附加功能，就要定义一个新版本的RTP，在固定头域中作永久性修改。
1. 1. 4 RTP头扩展
注意只在有限的使用范围内要求头扩展。使用这个机制最好通过另外的方式实现，使用前段描述的方法。例如，给固定头的序言说明扩展处理起来就更加廉价，因为既不是有条件的也不是可变的位置。特定有效载荷格式的附加信息不应该使用头扩展，但是应该在包的有效载荷段中携带。
如果RTP头的X位为1，在RTP头中必须追加可变长度的头扩展，如果CSRC列表存在就紧跟其后。头扩展中包含了16bit长度域，存放的是扩展中的32bit长度字的数量，不包括四字节的扩展头(因此0也是有效长度)。只有一个单独的扩展能够追加到RTP数据头后。为了允许每个协调工作的多个互相作用的实现和不同的头扩展相独立，或者允许某一特定执行能够和多于一个类型的头扩展协调工作，头扩展的头16bit数据用于区分标识或者参数。这16bit数据的格式定义符合实现所遵守的序言说明。RTP说明不定义任何头扩展本身。
图3 RTP头扩展
Fig. 3 RTP head extension
1．2、RTP控制协议一RTCP
RTP控制协议(RTCP)将控制包周期发送给所有连接者，应用与数据包相同的分布机制。下层的协议必须提供数据包和控制包的复用，例如使用单独的UDP端口号。RTCP具有四个功能:
第一个功能是提供数据发布的质量反馈aRTCP是作为RTP传输协议的一部分，与其他传输协议的流和阻塞控制有关。反馈对自适应编码控制直接起作用，但IP多播经验表明，从发送者收到反馈对诊断发送错误是至关重要的。给所有参与者发送接收反馈报告允许问题观察者估计哪些问题是局部的，哪些是全局的。诸如IP多播等发布机制使网络服务提供商
类团体可能接收反馈信息，充当第三方监控者来诊断网络问题。反馈功能由RTCP发送者和接收者报告执行。
第二个功能是RTCP携带了一个RTP源永久传输层标识，即规范名字或者CNAME。如果发现了冲突或者程序重新启动SSRC就会改变，接收方需要CNAME跟踪每个参与者。接收方也需要有CNAME来从一系列相关的RTP会话中把多个给定的参与者的多个数据流联合起来，例如把音频和视频数据同步起来。媒体内部的同步也要求数据发送方的RTCP包中包含的NTP和RTP时间戳。
前两个功能要求所有的参与者都发送RTCP数据包，因此必须控制速率来适应大量的参与者。通过每个参与者都把自己的控制包发送给所有的参与者，每个都能独立的观察参与者的数目。这个数目用于计算数据包发送的速率。
第4个可选功能是传达最小的会话控制信息，例如在用户接口处显示参与者身份。这在“松控制”会话中最有用，这类会话中参与者进入或离开而不需要成员控制或者参数信息。RTCP提供到达所有参与者的一个方便的渠道，但是并不要求支持应用程序的所有控制通信要求。可能需要更高层的会话控制协议，但是已经超过了本文探讨的范围。
头三个功能应该用于所有的环境中，尤其在IP多播的情况下。RTP应用程序设计者应该避免只能在单播的情况下工作的机制，也不能适应更大的数量。RTCP传输可以为发送方和接收方单独控制，例如接收方无法接收到反馈的单向连接中。
1 .2. 1、RTCP包格式
下面定义了几个携带变化的控制信息的RTCP包类型:
SR:发送方报告，源于活动发送方参与者的用于传输和接收统计。
RR:接收方报告，源于非活动发送方的参与者用于接收统计，和SR组合起来用于活动发送者报告多于31个源。
SDES:源描述项，包括CNAME。
BYE:显示参与中止。
APP:应用程序特定功能。
和RTP数据包中的内容类似，每个RTCP包都以固定的部分开头，之后紧跟和包类型有关的长度可能变化的结构化的元素，但是必须以32bit为边界结束。包含了排列要求和每个包中的固定部分内的长度域使RTCP包“可堆叠的”。多个RTCP包不用插入分隔部分就可直接连接到一起形成一个复合RTCP包，这个复合的RTCP包在低层的协议中用一个单独的包发送出去，如UDP。在复合包中没有精确的RTCP包的数量，因为更低层协议只要提供整个长度就可以决定复合包的结束。
复合包中的每个单独的RTCP包都可以单独处理而不依赖于组合包的顺序或者组合。然而，为了执行协议的这些功能，必须满足如下限制：
*接收统计((SR或者RR中)应该经常发送，只要带宽允许，因此每个周期性的传输的复合RTCP包中必须包含有报告包。
*新的接收者需要接收CNAME，并尽快识别源，并开始连接媒体进行同步，所以每个复合RTCP包都必须包括SDES CNAME，除非复合RTCP包分割开用于部分加密。
*出现在组合包前面的是包类型数量，其增长应该受到限制，以提高常数位数量。
因此，所有的RTCP包必须用至少有两个单独包的复合包传输，用如下格式:
(1)加密前缀(Encryption Prefix)
仅当复合包被加密，才加上一个32位随机数用于每个复合包发送。
(2)SR或RR:
复合包中的第一个RTCP包必须总是一个报告包，方便头的确认。即使没有数
据发送或者接收，也必须发送空的RR，哪怕复合包中的另一个RTCP包是BYE.
(3)附加RR:
如果接收统计报告的源的数量超过了31，在初始报告包后面应该附加RR包。
(4)SDES:
每个复合RTCP包必须包含CNAME项的SDES包。其他源描述项可选，但受到带宽制。
(5)BYE或者APP:
其他的RTCP包类型可以任意顺序排列，但是BYE应作为最后一个包发送，包类型出现可以不止一次。
建议转换器(translator)或者混合器(mixer)从多个组合单个的RTCP包。如复合包整体长度超过了网络路径最大传输单元，可以分成多个较短组合包用低层协议以单个包形式发送。注意，每个复合包必须以SR或者RR包开始。附加RTCP包类型可在Internet Assigned Numbers Authority (IANA)处注册。注意每个复合包都必须用SR或者RR包开始。程序要能够忽略接收到的RTCP包中无法识别类型的包。
1.2.2、发送方与接收方报告
RTP接收方使用RTCP报告包提供接收质量反馈，报告包根据接收方是否是发送者而采用两种格式中的一种。除包类型代码外，发送者报告与接收方报告间唯一的差别是发送方报告包含一个20个字节发送方信息段。如某地址在发出最后或前一个报告间隔期间发送数据包，就发布SR;否则，就发出RR; SR和RR都可没有或包括多个接收报告块。发布报告不是为列在CSRC列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。既然最大可有31个接收报告块嵌入在SR或RR包中，附加RR包可堆叠在初始SR或RR包之后。
发送方报告包由3部分组成，也可能还有第四个特定设置扩展部分。
第一部分为头，8个字节长，包括了版本(V)、填充位(P)、接收报告计数(RC),包类型(PT)、长度、同步源标识(SSRC)等信息。
第二部分为发送方信息，20个字节，出现在每个发送方报告包中。包括了NTP时间戳、RTP时间戳、发送方包计数、发送方字节计数等信息。
第三部分包括接收报告块，大小与自最后一个报告来发送方监听的其他源数量有关。每个接收报告块传输单个同步源接收RTP包的统计。发生冲突，当源改变SSRC标识时，接收方并不继续统计。这些统计包括:SSRC n(源标识)、丢失部分、丢失包累积数、收到已扩展的最高系列号、时间抖动、最后SR时间戳(LSR ),自最后一个SR来的延迟(DLSR)统计。
1.2.3 SDES:源描述RTCP包
SDES包为三层结构，由头与数据块组成，数据块可以没有，也可以有多个，组成项描述块所表明的源。
项描述如下:
1.版本(V)、填充(P)、长度：如SR包中所描述。
2.包类型(PT) ：8bit，包含常数202，区别RTCP SDES包。
3.源计数(SC)：Sbit，包含在SDES包中的SSRC/CSRC块数量，零值有效，但没有意义。
4.源描述项内容包括:CNAME, NAME, E-mail, PHONE, LOC, TOOL，NOTE, PRIV。
1) CNAME:规范终端标识SDES项。
2) NAME:用户名称SDES项。
3) E-mail:电子邮件地址SDES项。
4) PHONE:电话号码SDES项。
5) LOC:用户地理位置SDES项。
6) TOOL:应用或工具名称SDES项。
7) NOTE:通知/状态SDES项。
8) PRIV:专用扩展SDES项。
1. 2. 4、 BYE:断开RTCP包
如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC/CSRC标识。如混合器关闭，它也应该发出一个BYE包，列出它所处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个8bit的字节计数，后跟很多字节文本，标识离开原因，如:"camera malfunction”或“RTP loop detected".字符串具有同样的编码，如在SDES中所描述的。如字符串填充包至下32bit边界，字符串就不以空结尾;否则，BYE包以空字节填充。
1. 2. 5、APP:定义应用的RTCP包
APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA 注册子类型和名称段。
1．3、RTSP协议[6]
1.3.1简介
1.目的:
实时流协议(RTSP)建立并控制一个或者多个时间同步连续媒体流，如视频和音频。尽管连续媒体流与控制流可以交叉，通常它不直接传输连续流本身。换句话说，RTSP是多媒体服务器的“网络远程控制”。
TCP可以绑定到传输层连接上，而RTSP会话无法绑定到传输层连接上。RTSP会话期间，RTSP用户可以打开和关闭很多连接到服务器的可靠传输来发出RTSP请求。此外，它可以使用无连接传输协议，比如UDP 。
RTSP流控制的流可能使用到RTP协议，但是RTSP操作不依赖于用来传输连续媒体的传输机制。这个协议在语法和操作方面类似于HTTP/1.1，以至于扩展的HTTP机制也可以被加入到RTSP中。这个协议支持如下操作:
※从媒体服务器恢复媒体:
用户可以通过HTTP或者别的方式请求一个演示描述。如果演示正在多播，演示描述符包含了多播地址和传输连续媒体的端口。如果演示是通过单播传输给用户的，用户提供安全目的地地址。
※邀请媒体服务器加入到会议中:
媒体服务器可以被“邀请”来参加正进行的会议，或回放媒体，或记录其中一部分或全部。这个模式对分布式的教学应用方面很有用。会议中的几个组可以轮流“按下远程控制按钮”。
※把媒体加入到现成的讲座中:
如果服务器可以告诉用户可以获得的附加媒体内容，在直播讲座方面尤其有用。RTSP 请求可以用代理，管道，缓存处理，正像HTTP/ 1.1中那样。
2. RTSP特性
RTSP有如下特性:
可扩展性、解析简单、安全、传输独立、流控制和会议初始化分离、适合专业应用、友
好的代理和防火墙、友好的HTTP等。
更早一点的RTSP要求可以多用户。然而后来人们决定最好的办法是协议能够很容易地扩展到多用户。流标识符可以被几个控制流共同使用，以至于“通过远程”可以成为可能。协议不能指定几个用户怎样互相访问。
3.和其他协议的关系
RTSP在性能方面和HTTP有些重叠。和HTTP相互作用体现在与流内容的初始接触是通过web页的。目前的协议说明目的在于允许在WEB服务器和媒体服务器之间存在不同传输点。比如，演示描述符可以用HTTP或者RTSP获得，这降低了浏览器的往返传递，也允许独立RTSP服务器与用户不全依靠HTTP 。
然而，RTSP在另一种协议下数据传输超过带宽方面和HTTP有基础性的不同。HTTP 是一个不对称协议，用户发出请求，服务器响应。在RTSP中，媒体用户和服务器都能够发出请求，RTSP请求是无序的，请求收到之后还可以设置参数和控制媒体流。
重新使用HTTP功能在至少两个方面有优势，即安全和代理。请求很类似，所以使HTTP 能够工作在缓存、代理和鉴权方面是很有价值的。
很多实时媒体传输协议使用RTP，但是RTSP不是绑到RTP上的。
RTP假设演示描述符格式存在包括几个媒体流，这些演示描述符格式能表达静态和暂时的演示特性。
1.3.2、协议参数
1.RTSP版本
(H3.1)采用，用RTSP代替HTTP o
2. RTSP URL
rtsp命令通过可靠协议(Internet中用TCP)处理，而rtspu命令使用不可靠协议处理(Internet网中使用UDP) o
如果端口554没有被使用，默认情况下使用端口554。服务器端在主机的这个端口监听TCP (rtsp)或者UDP(rtspu)来控制唯一的资源用RTSP协议，资源的请求URI是rtsp URL a 在URL中应该避免直接使用IP。
3.会议标识
会议标识对RTSP来说是模糊的，采用标准URI编码方法编码，可包含任何字节数值。会议标识必须全局唯一。
4.连接标识
连接标识是长度不确定的字符串，必须随机选择，至少要8个字节长，使它很难能被猜测出。
5. SMPTE相关时间戳
SMPTE相关时间戳标识相对剪辑开始的时间，相关时间戳表示成SMPTE时间代码，精确到帧级。时间代码格式为小时:分钟:秒:帧。缺省SMPTE格式是"SMPTE 30"，帧速率为每秒29.97帧。其他SMPTE代码可选择使用SMPTE时间获得支持(如“SMPTE 25")。时间数值中帧段值可从0到29。顺便指出30帧每秒和29.97帧每秒的区别:30帧每秒的视频帧序列中丢弃每分钟的起始两帧，除了时间是10分钟的整数倍的那些分钟，就变成了29.97帧每秒了。
6.正常播放时间
正常播放时间(NPT)标识相对演示开始的流绝对位置。时间戳由十进制分数组成。左边部分用秒或小时、分钟、秒表示;小数点右边部分表示秒的部分。演示的开始对应0.0上，NPT是联系观看者与程序的时钟，通常以数字式显示在VCR上。
7.绝对时间
绝对时间表示成IS08601时间戳，采用UTC (GMT).
8.可选标签
可选标签是用于指定RTSP新可选项的唯一标记。这些标记用在请求和代理一请求头段。当登记新RTSP选项时，需提供下列信息:
(1)名称和描述选项。名称长度不限，但应该不多于20个字符。名称不能包括空格、控制字符。
(2)表明谁改变选项的控制。如IETF, ISO, ITU-T，或其他的国际标准团体、联盟或公司。
(3)深入描述的参考，如RFC、论文、专利、技术报告、文档源码和计算机手册。
(4)对专用选项，附上联系方式。
1.3.3、RTSP消息
RTSP是基于文本的协议，使用ISO 10646字符集UTF-8编码(RFC 2279)方案。RTCP 也使用ISO 10646编码方式。
如果消息中有消息体，消息体的长度按照如下方法确定(按照优先权顺序):
1.没有消息体的任何回应信息(如lxx, 204和304回应信息)，总是在头域后紧跟一个空行来结束消息，不管消息中的实体头域。(注意:空行仅仅包含CRLF回车换行。)
2.如果内容长度头域存在，以字节为单位的数值代表消息体的长度。如果头域不存在，这个数值为Oo
3.服务器关闭连接的时候。(关闭连接不意味着请求体的结束，因为那样的话服务器将不可能发回一个回应信息。)
如果合适长度的演示描述符返回，服务器应该能够知道它的长度，尽管它是动态生成的，使大块传输编码不必要。尽管如果有实体内容长度必须存在，尽管长度没有明确给出，这个规则保证了合理的行为。
1.3.4、实体
如不受请求方法或响应状态编码限制，请求和响应信息可传输实体，实体由实体头文件和实体体组成，有些响应仅包括实体头。在此，根据谁发送实体、谁接收实体，发送者和接收者可分别指用户和服务器。
实体头定义实体体可选元信息，如没有实体体，指请求标识的资源。扩展头机
制允许定义附加实体头段，而不用改变协议，但这些段不能假定。
1.3.5、连接
RTSP请求可以用几种不同的方式传输出去:
※几个请求一一回应模式的永久的传输连接
※每个请求/回应模式的连接
※无连接模式
传输连接的类型用RTSP的URI定义。对于“rtsp"，就假设永久连接，然而“rtspu”请求在发送数据的时候就不建立连接。
不像HTTP, RTSP允许媒体服务器给媒体用户发送请求。然而，只是在永久连接的情况下才支持，因为不然的话媒体服务器就没有可靠的到达用户的方式。而且，这是从媒体服务器发给用户的请求穿过防火墙的唯一方式。
如果可靠传输协议用于携带RTSP，请求必须不能重新传输；RTSP应用必须依靠下层的传输来提供可靠性。
如果下层的可靠传输(如TCP)和RTSP应用程序重新传输请求，可能每个包丢了两次重新传输的结果。接收者不能典型的应用层重传，因为传输堆栈不能在第一次请求到达接收者之前重新传输。如果丢包是由于拥塞引起，不同层的多重传会加剧拥塞。
如果RTSP用在小RTT局域网中，标准的程序对优化初始TCP RTT估值是很有用的。时间戳头用于防止重传含糊问题，排除了Karn的算法的需要。
每个请求都有一个序列号在Cseq头中，每个不同的请求传输后都自动加1。如果请求由于缺少确认信息而重复，请求必须使用的一直都是最初的序列号(也就是序列号不递增)。
采用RTSP的系统必须支持在TCP上传输RTSP，也可能支持UDP。不管是UDP还是TCP，默认的RTSP服务器端口号都是5540
很多个去往同一个控制端点的RTSP包可以打包到单独的更低层PDU或者封装给TCP 流。RTSP数据可以用RTP和RTCP包交替。不像HTTP，只要信息包含了有效载荷，RTSP 信息必须包含内容长度头。不然，RTSP包就要在最后一个信息头后用一个空行来中止。
1.3.6、缓冲
在HTTP中，回应一一请求对是缓冲的。RTSP在这方面是不同的。回应是不缓冲的，除了演示描述符由DESCRIBE返回或者包含在ANNOUNCE中。(因为除了DERCRIBE和GET PARAMETER之外的回应不返回任何数据，对于这些请求来说缓冲不是必要的)。然而，对于连续媒体数据，尤其是用RTSP协议传输超过带宽的数据和会话描述符时，缓冲是必要的。
接收到建立和播放请求的时候，代理确定它是否有新的连续媒体内容的复制和描述符。它是通过处理建立或者描述请求来决定复制是否是最新的，把最后的修改过的头和缓冲了的复制比较。如果复制不是最新的，就把修改“建立”(SETUP)传输参数修改成合适的数字，继续把请求发给原始服务器。接下来的控制命令如"PLAY"(播放)或者“PAUSE"(停止)，之后不修改任何代理继续传输出去。代理把连续媒体递送给用户，同时也会拷贝一份留着后来使用。允许缓冲做的准确行为是由缓冲回应指示描述的。如果缓冲正在给请求器送流信息，缓冲必须回答任何DESCRIBE(描述)请求，因为流描述符的低电平详情可能在原始服务器上改变了。
注意:不像HTTP缓冲，RTSP缓冲具有“cut through”型变量。不是从原始服务器中提取出完整的资源，缓冲只是简单的在把数据传送给用户途中顺便拷贝流数据。因此，不加入额外的冗余。
对于用户来说，RTSP代理缓冲像是一个常规的媒体服务器，而原始的服务器倒像是个用户。正像HTTP缓冲必须储存它所要储存对象的内容类型、内容语言等等，媒体缓冲必须要储存演示描述符。典型地，缓冲降低了所有的演示描述符的传输内容(即多播信息)，因为这些是从缓冲到用户的独立数据传输。编码器的信息仍然没变。如果缓冲能够翻译缓冲的媒体数据，它就尽自己所能提供的所有编码方式生成一个新的演示描述符。
[4]吴国勇，邱学刚，万燕仔等.《网络视频流媒体技术与应用》.北京:北京邮电大学出版社。2001年.
[5] (RFC 3550) H.Schulzrinne Columbia University,etc ,July 2003
[6] (RFC 2326) H.Schulzrinne Columbia Universityetc ,April 1998
[7] Microsoft Corporation.(ASF Specification)): America:2004.
rtsp简介(ZT) Real Time Streaming Protocol或者RTSP（实时流媒体协议），是由Real network 和Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议。RTSP提供一种可扩展的框架，使能够提供能控制的，按需传输实时数据，比如音频和视频文件。源数据可以包括现场数据的反馈和存贮的文件。rtsp对流媒体提供了诸如暂停，快进等控制，而它本身并不传输数据，rtsp作用相当于流媒体服务器的远程控制。传输数据可以通过传输层的tcp，udp协议，rtsp也提供了基于rtp传输机制的一些有效的方法。RTSP消息格式: RTSP的消息有两大类,一是请求消息(request),一是回应消息(response),两种 消息的格式不同. 请求消息: 方法URI RTSP版本CR LF 消息头CR LF CR LF 消息体CR LF 其中方法包括OPTION回应中所有的命令,URI是接受方的地址,例如 :rtsp://192.168.20.136 RTSP版本一般都是RTSP/1.0.每行后面的CR LF表示回车换行，需要接受端有相应的解析，最后一个消息头需要有两个CR LF 回应消息: RTSP版本状态码解释CR LF 消息头CR LF CR LF 消息体CR LF 其中RTSP版本一般都是RTSP/1.0,状态码是一个数值,200表示成功,解释是与状态码对应的文本解释. 简单的rtsp交互过程: C表示rtsp客户端,S表示rtsp服务端 1.C->S:OPTION request //询问S有哪些方法可用 1.S->C:OPTION response //S回应信息中包括提供的所有可用方法 2.C->S:DESCRIBE request //要求得到S提供的媒体初始化描述信息 2.S->C:DESCRIBE response //S回应媒体初始化描述信息，主要是sdp 3.C->S:SETUP request //设置会话的属性，以及传输模式，提醒S建立会 话 3.S->C:SETUP response //S建立会话，返回会话标识符，以及会话相关信息 4.C->S:PLAY request //C请求播放 4.S->C:PLAY response //S回应该请求的信息 S->C:发送流媒体数据 5.C->S:TEARDOWN request //C请求关闭会话 5.S->C:TEARDOWN response //S回应该请求
RCTP实时控制/传输通讯协议 RCTP协议(RealTime Control and Translate Protocol)为自定义实时控制/传输通讯协议。 1、基本帧格式 1.1帧结构 typedef struct { uchar head; //帧头 uchar length; //帧长度 uchar length_rep; //帧长度重复 uchar head_rep; //帧头重复 uchar source_id; //发送设备号 uchar directory_id; //接收设备号 uchar handle; //帧与操作类型 uchar parameter[frame_data_size]; //帧参数域buf uchar AccVal; //累加和校验 uchar stop; //结束符 } struct_frame; 1.2开始符的判断 条件：if(struct_frame.head == struct_frame.head_rep) && (struct_frame.length == struct_frame.length_rep)成立。 1.3帧与操作类型 1.3.1 数据帧的操作类型定义 1.3.2 命令帧的操作类型定义
1.4 校验和 校验和为：0-N的累加值，1字节。 2、基于RCTP的LED数码管数据采集通讯协议: RCTP-Ⅰ协议 RCTP-Ⅰ协议是基于RCTP的LED数码管数据采集通讯协议，物理上基于RS-485口，通过屏蔽双绞线实现通讯。RCTP-Ⅰ协议是一种主-从协议。主站设备发送要求到从站设备，从站设备响应，从站不能主动发出信息。 波特率代码表： 在默认状态下通信的设置速率一般是9600、无效验、8数据位、1个停止位。
1.1音视频编解码技术 1.1.1 MPEG4 MPEG全称是Moving Pictures Experts Group，它是“动态图象专家组”的英文缩写，该专家组成立于1988年，致力于运动图像及其伴音的压缩编码标准化工作，原先他们打算开发MPEG1、MPEG2、MPEG3和MPEG4四个版本，以适用于不同带宽和数字影像质量的要求。 目前，MPEG1技术被广泛的应用于VCD，而MPEG2标准则用于广播电视和DVD等。MPEG3最初是为HDTV开发的编码和压缩标准，但由于MPEG2的出色性能表现，MPEG3只能是死于襁褓了。MPEG4于1999年初正式成为国际标准。它是一个适用于低传输速率应用的方案。与MPEG1和MPEG2相比，MPEG4更加注重多媒体系统的交互性和灵活性MPEG1、MPEG2技术当初制定时，它们定位的标准均为高层媒体表示与结构，但随着计算机软件及网络技术的快速发展，MPEG1、MPEG2技术的弊端就显示出来了：交互性及灵活性较低，压缩的多媒体文件体积过于庞大，难以实现网络的实时传播。而MPEG4技术的标准是对运动图像中的内容进行编码，其具体的编码对象就是图像中的音频和视频，术语称为“AV对象”，而连续的AV对象组合在一起又可以形成AV场景。因此，MPEG4标准就是围绕着AV对象的编码、存储、传输和组合而制定的，高效率地编码、组织、存储、传输AV 对象是MPEG4标准的基本内容。 在视频编码方面，MPEG4支持对自然和合成的视觉对象的编码。（合成的视觉对象包括2D、3D动画和人面部表情动画等）。在音频编码上，MPEG4可以在一组编码工具支持下，对语音、音乐等自然声音对象和具有回响、空间方位感的合成声音对象进行音频编码。 由于MPEG4只处理图像帧与帧之间有差异的元素，而舍弃相同的元素，因此大大减少了合成多媒体文件的体积。应用MPEG4技术的影音文件最显著特点就是压缩率高且成像清晰，一般来说，一小时的影像可以被压缩为350M左右的数据，而一部高清晰度的DVD电影, 可以压缩成两张甚至一张650M CD光碟来存储。对广大的“平民”计算机用户来说，这就意味着, 您不需要购置DVD-ROM就可以欣赏近似DVD质量的高品质影像。而且采用MPEG4编码技术的影片，对机器硬件配置的要求非常之低，300MHZ 以上CPU，64M的内存和一个8M显存的显卡就可以流畅的播放。在播放软件方面，它要求也非常宽松，你只需要安装一个500K左右的MPEG4 编码驱动后，用WINDOWS 自带的媒体播放器就可以流畅的播放了 AV对象（AVO，Audio Visual Object）是MPEG-4为支持基于内容编码而提出的重要概念。对象是指在一个场景中能够访问和操纵的实体，对象的划分可根据其独特的纹理、运动、形状、模型和高层语义为依据。在MPEG-4中所见的音视频已不再是过去MPEG-1、MPEG-2中图像帧的概念，而是一个个视听场景（AV场景），这些不同的AV场景由不同的AV对象组成。AV对象是听觉、视觉、或者视听内容的表示单元，其基本单位是原始AV对象，它可以是自然的或合成的声音、图像。原始AV对象具有高效编码、高效存储与传输以及可交互性的特性，它又可进一步组成复合AV对象。因此MPEG-4标准的基本内容就是对AV对象进行高效编码、组织、存储与传输。AV对象的提出，使多媒体通信具有高度交互及高效编码的能力，AV对象编码就是MPEG-4的核心编码技术。 MPEG-4不仅可提供高压缩率，同时也可实现更好的多媒体内容互动性及全方位的存取性，它采用开放的编码系统，可随时加入新的编码算法模块，同时也可根据不同应用需求现场配置解码器，以支持多种多媒体应用 1.1.2 H264 H.264是由ITU-T的VCEG（视频编码专家组）和ISO/IEC的MPEG（活动图像编码专家组）联合组建的联合视频组（JVT：joint video team）提出的一个新的数字视频编码标准，
实时传输协议RTP 1.RTP协议： RTP（ Real-time Transport Protocol）协议最初是在70年代为了尝试传输声音文件，把包分 成几部分用来传输语音，时间标志和队列号。经过一系列发展，RTP第一版本在 1991年8月由美国的一个实验室发布了。到本世纪1996年形成了标准的的版本。很多著名的公司如Netscape ,就宣称“Netscape LiveMedia”是基于RTP协议的。Microsoft 也宣称他们的“NetMeeting”也是支持RTP协议. RTP被定义为传输音频、视频、模拟数据等实时数据的传输协议。最初设计是为了数据传输的多播，但是它也用于单播的。与传统的注重的高可靠的数据传输的运输层协议相比，它更加侧重 的数据传输的实时性。此协议提供的服务包括时间载量标识、数据序列、时戳、传输控制等。RTP与辅助控制协议RTCP一起得到数据传输的一些相关的控制信息。 2．RTP协议的工作原理： 如上所说明的，影响多媒体数据传输的一个尖锐的问题就是不可预料数据到达时间。但是流媒体的传输是需要数据的适时的到达用以播放和回放。RTP协议就是提供了时间标签,序列号以及 其它的结构用于控制适时数据的流放。 在流的概念中‘时间标签’是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后,就依照时间标签按照正确的速率恢复成原始的适时的数据。不同的媒体格式调时属性是不一样的。但是RTP本身并不负责同步，RTP只是传输层协议，为了 简化了运输层处理，提高该层的效率。将部分运输层协议功能（比如流量控制）上移到应用层 完成。同步就是属于应用层协议完成的。它没有运输层协议的完整功能，不提供任何机制来保 证实时地传输数据，不支持资源预留，也不保证服务质量。RTP报文甚至不包括长度和报文边界的描述。同时RTP协议的数据报文和控制报文的使用相邻的不同端口，这样大大提高了协议的灵活性和处理的简单性。 RTP协议和UDP二者共同完成运输层协议功能。UDP协议只是传输数据包，是不管数据包传输的时间顺序。RTP的协议数据单元是用UDP分组来承载的。在承载RTP数据包的时候，有时候一帧数据被分割成几个包具有相同的时间标签，则可以知道时间标签并不是必须的。而UDP的多路复用让RTP协议利用支持显式的多点投递，可以满足多媒体会话的需求。 RTP协议虽然是传输层协议但是它没有作为OSI体系结构中单独的一层来实现。RTP协议通常根据一个具体的应用来提供服务， RTP只提供协议框架，开发者可以根据应用的具体要求对协议进行充分的扩展。目前，RTP的设计和研究主要是用来满足多用户的多媒体会议的需要，另外它也适用于连续数据的存储，交互式分布仿真和一些控制、测量的应用中。基于RTP的实验和商业产品也层出不穷。最常用的协议是RTMP(Real Time Messaging Protocol，实时消息传送协议)，RTMP是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。还有RTSP,HLS等。 实时传输控制协议RTCP协议 1. RTCP协议： RTCP（Real-time Transpor、Control Protocol）是设计和RTP一起使用的进行流量控制和拥塞控制的服务控制协议。 2. RTCP协议如何工作： 当应用程序开始一个RTP会话时将使用两个端口：一个给RTP，一个给RTCP。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。在RTP的会话之间周期的发放一些RTCP包以用来传监听服务质量和交换会话用户信息等功能。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利 用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。根据用户间的数
H5视频直播扫盲 1 H5到底能不能做视频直播 当然可以， H5火了这么久，涵盖了各个方面的技术。 对于视频录制，可以使用强大的webRTC（Web Real-Time Communication）是一个支持网页浏览器进行实时语音对话或视频对话的技术，缺点是只在PC的chrome上支持较好，移动端支持不太理想。 对于视频播放，可以使用HLS(HTTP Live Streaming)协议播放直播流，ios和android都天然支持这种协议，配置简单，直接使用video标签即可。 webRTC兼容性： video标签播放hls协议视频：
1 2 3 4 2 到底什么是HLS协议 简单讲就是把整个流分成一个个小的，基于HTTP的文件来下载，每次只下载一些，前面提到了用于H5播放直播视频时引入的一个.m3u8的文件，这个文件就是基于HLS协议，存放视频流元数据的文件。 每一个.m3u8文件，分别对应若干个ts文件，这些ts文件才是真正存放视频的数据，m3u8文件只是存放了一些ts文件的配置信息和相关路径，当视频播放时，.m3u8是动态改变的，video标签会解析这个文件，并找到对应的ts文件来播放，所以一般为了加快速度，.m3u8放在web服务器上，ts文件放在cdn上。 .m3u8文件，其实就是以UTF-8编码的m3u文件，这个文件本身不能播放，只是存放了播放信息的文本文件： 1 2 3 4 5#EXTM3U m3u文件头 #EXT-X-MEDIA-SEQUENCE 第一个TS分片的序列号#EXT-X-TARGETDURATION 每个分片TS的最大的时长#EXT-X-ALLOW-CACHE是否允许cache #EXT-X-ENDLISTm3u8文件结束符
RTP协议分析 一．RTP协议背景 (2) 二．RTP协议原理及工作机制 (2) 2．1 RTP协议原理 (3) 2．1．1 RTP协议原理 (3) 2．1．2 RTCP协议原理 (3) 2．2 RTP数据包格式 (4) 2．2．1 RTP数据包格式 (4) 2．2．2 RTCP数据包格式 (6) 2．3 RTP工作机制 (9) 2．3．1 RTP工作机制 (9) 2．3．2 RTCP工作机制 (9) 三．RTP协议关键技术指标 (10) 3．1 时间戳 (10) 3．2时延 (10) 3．3 抖动 (11) 3．4丢包率 (11) 3．5 会话和流两级分用 (11) 3．6 多种流同步控制 (12) 四．RTP协议应用方案 (12) 4．1 RTP协议应用方案之单播 (12) 4．2 RTP协议应用方案之广播 (12) 4．3 RTP协议应用方案之组播 (13) 4．3.1 RTP协议组播方案总体概述 (13) 4．3.2 RTP协议组播方案服务器端实现 (14) 4．3. 3RTP协议组播方案客户端实现 (14) 4．3. 4RTP协议视频帧率和质量调整策略 (15) 五．RTP协议移植计划 (16) 六．RTP协议安全方面考虑 (16)
一．RTP协议背景 流（Streaming）是近年在Internet上出现的新概念，其定义非常广泛，主要是指通过网络传输多媒体数据的技术总称。流媒体包含广义和狭义两种内涵：广义上的流媒体指的是使音频和视频形成稳定和连续的传输流和回放流的一系列技术、方法和协议的总称，即流媒体技术；狭义上的流媒体是相对于传统的下载-回放方式而言的，指的是一种从Internet上获取音频和视频等多媒体数据的新方法，它能够支持多媒体数据流的实时传输和实时播放。通过运用流媒体技术，服务器能够向客户机发送稳定和连续的多媒体数据流，客户机在接收数据的同时以一个稳定的速率回放，而不用等数据全部下载完之后再进行回放。 流式传输有顺序流式传输(Progressive Streaming)和实时流式传输(Realtime Streaming)两种方式。实时流式传输是实时传送，特别适合现场事件，实时流式传输必须匹配连接带宽，这意味着图像质量会因网络速度降低而变差，以减少对传输带宽的需求。“实时”的概念是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系，这需要相应的协议支持，这样RTP和RTCP就相应的出现了。 实时传输协议RTP（Realtime Transport Protocol）：是针对Internet上多媒体数据流的一个传输协议, 由IETF作为RFC1889发布，现在最新的为RFC3550。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。 实时传输控制协议RTCP（Realtime Transport Control Protocol）：负责管理传输质量,在当前应用进程之间交换控制信息，提供流量控制和拥塞控制服务。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP 和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。 二．RTP协议原理及工作机制 让我们先看一下RTP和RTCP在网络层次中的位置，以便我们更加清楚的了解该协议，如下图1-1所示：
一.UDP和Socket通信步骤 1.UDP Server程序 1、编写UDP Server程序的步骤 (1)使用socket()来建立一个UDP socket，第二个参数为SOCK_DGRAM。 (2)初始化sockaddr_in结构的变量，并赋值。sockaddr_in结构定义： struct sockaddr_in { uint8_t sin_len; sa_family_t sin_family; in_port_t sin_port; struct in_addr sin_addr; char sin_zero[8]; }; 这里使用“08”作为服务程序的端口，使用“INADDR_ANY”作为绑定的IP地址即任何主机上的地址。 (3)使用bind()把上面的socket和定义的IP地址和端口绑定。这里检查bind()是否执行成功，如果有错误就退出。这样可以防止服务程序重复运行的问题。(4)进入无限循环程序，使用recvfrom()进入等待状态，直到接收到客户程序发送的数据，就处理收到的数据，并向客户程序发送反馈。这里是直接把收到的数据发回给客户程序。 2、udpserv.c程序内容： #include
RTSP协议学习笔记 目录 RTSP协议学习笔记 (1) 第一部分:RTSP协议 (2) 一、RTSP协议概述 (2) 二、RTSP协议与HTTP协议区别 (2) 三、RTSP重要术语 (3) 1.集合控制(Aggregate control ): (3) 2.实体(Entity)： (3) 3.容器文件（Container file）： (3) 4.RTSP会话(RTSP session )： (3) 四、RTSP请求消息 (3) 1.消息格式： (3) 五、RTSP回应消息 (4) 1.消息格式： (4) 六、RTSP 重要方法 (4) 1. OPTIONS: (4) 2. DESCRIBE： (5) 3. SETUP： (6) 4. PLAY： (7) 5. PAUSE： (8) 6. TEARDOWN： (8) 七、RTSP重要头字段参数 (9) 1.Accept: (9) 2.Bandwidth: (9) 3. CSeq： (9) 4. Rang： (9) 5.Session: (9) 6.Transport: (9) 八、简单的RTSP消息交互过程 (10) 1.第一步：查询服务器端可用方法 (10) 2.第二步：得到媒体描述信息 (10) 3.第三步：建立RTSP会话 (10) 4.第四步：请求开始传送数据 (10) 5.第五步：数据传送播放中 (10) 6.第六步：关闭会话，退出 (10) 第二部分:SDP协议 (11) 一、SDP协议概述 (11) 二、SDP格式 (11) 三、SDP示例 (12) 第三部分:MMS协议 (13) 一、MMS协议概述 (13)
RFC3550 RTP：实时应用程序传输协议 摘要 本文描述RTP（real-time transport protocol），实时传输协议。RTP在多点传送（多播）或单点传送（单播）的网络服务上，提供端对端的网络传输功能，适合应用程序传输实时数据，如：音频，视频或者仿真数据。RTP没有为实时服务提供资源预留的功能，也不能保证QoS（服务质量）。数据传输功能由一个控制协议（RTCP）来扩展，通过扩展，可以用一种方式对数据传输进行监测控制，该协议（RTCP）可以升级到大型的多点传送（多播）网络，并提供最小限度的控制和鉴别功能。RTP和RTCP被设计成和下面的传输层和网络层无关。协议支持RTP标准的转换器和混合器的使用。 本文的大多数内容和旧版的RFC1889相同。在线路里传输的数据包格式没有改变，唯一的改变是使用协议的规则和控制算法。为了最小化传输，发送RTCP数据包时超过了设定的速率，而在这时，很多的参与者同时加入了一个会话，在这样的情况下，一个新加入到（用于计算的可升级的）计时器算法中的元素是最大的改变。 目录（Table of Contents） 1. 引言（Introduction） 1 1 术语（Terminology） 2 RTP使用场景（RTP Use Scenarios） 2 1 简单多播音频会议（Simple Multicast Audio Conference） 2 2 音频和视频会议（Audio and Video Conference） 2 3 混频器和转换器（Mixers and Translators） 2 4 分层编码（Layered Encodings） 3 定义（Definitions） 4 字节序，校正和时间格式（Byte Order, Alignment, and Time Format） 5 RTP数据传输协议（RTP Data Transfer Protocol） 5 1 RTP固定头域（RTP Fixed Header Fields） 5 2 多路复用RTP会话（Multiplexing RTP Sessions） 5 3 RTP头的配置文件详细变更（Profile-Specific Modifications to the RTP Header） 5 3 1 RTP报头扩展（RTP Header Extension） 6 RTP控制协议（RTP Control Protocol）-- RTCP 6 1 RTCP包格式（RTCP Packet Format） 6 2 RTCP传输间隔（RTCP Transmission Interval） 6 2 1 维护会话成员数目（Maintaining the number of session members） 6 3 RTCP包的发送与接收规则（RTCP Packet Send and Receive Rules） 6 3 1 计算RTCP传输间隔（Computing the RTCP Transmission Interval） 6 3 2 初始化（Initialization） 6 3 3 接收RTP或RTCP（非BYE)包（Receiving an RTP or Non-BYE RTCP Packet） 6 3 4 接收RTCP（BYE）包（Receiving an RTCP BYE Packet） 6 3 5 SSRC计时失效（Timing Out an SSRC）
基于TCP协议的网络通信系统的设计与实现 摘要:网络通信，由于其具有实时性、跨平台性、成本低、效率高等优点而受到广泛的使用。设计并实现一个能够处理多用户进行实时、安全的即时通信系统具有较强的现实意义。即时通信的底层通信是通过SOCKET套接字接口实现的。当前的主流UNIX系统和微软的WINDOWS系统都在内核提供了对SOCKET字接口的支持。使用这个统一的接口，可以编写一个可移植的TCP/IP通信程序。使信息能够在INTERNET上可靠的传输。 本文设计并实现了基于局域网内的简单即时通信系统，系统采用C/S模式，底层通信通过SOCKET套接字接口实现，服务器负责客户端的登录验证，好友信息的保存和心跳报文的发送。客户端采用P2P方式实现消息传递，并能实现文件的传输。本文首先讨论了同步套接字，异步套接字，多线程并发执行任务等；然后阐述了客户端、服务器如何使用XML序列化的消息进行通信。 关键词：即时通信；文件传输；套接字；TCP协议 Abstract :Instant messages have several advantages such as real-time, cross-platform, cheap and efficient. To design a Multi-user IM (instant message) architecture is very i mportant in both theory and realism. Instant message based on TCP/IP protocol that is realized by socket interface. Almost all UNIX operation systems and Microsoft's win dows operation systems provide support of socket in the kernel. Using the uniform int erface, we can develop a portable program of TCP/IP, which help us transfer informati on in Internet safely and credibly. The system uses the client/server(C/S) mode. The server takes the responsibility of th e login message of client, the saving of friend message and Message heartbeat. The tra nsmission of the basic messages of the customer end will be designed on P2P architec ture. This thesis explains how the client and server communicate via serializing XML message. Key words: Instant Message; File Transfer; Socket; TCP protocol
1.1 音视频编解码技术 1.1.1 MPEG4 MPEG全称是Moving Pictures Experts Group，它是“动态图象专家组”的英文缩写，该专家组成立于1988年，致力于运动图像及其伴音的压缩编码标准化工作，原先他们打算开发MPEG1、MPEG2、MPEG3和MPEG4四个版本，以适用于不同带宽和数字影像质量的要求。 目前，MPEG1技术被广泛的应用于VCD，而MPEG2标准则用于广播电视和DVD 等。MPEG3最初是为HDTV开发的编码和压缩标准，但由于MPEG2的出色性能表现， MPEG3只能是死于襁褓了。MPEG4于1999年初正式成为国际标准。它是一个适用于低传输速率应用的方案。与MPEG1和MPEG2相比，MPEG4更加注重多媒体系统的交互性和灵活性 MPEG1、MPEG2技术当初制定时，它们定位的标准均为高层媒体表示与结构，但随着计算机软件及网络技术的快速发展，MPEG1、MPEG2技术的弊端就显示出来了：交互性及灵活性较低，压缩的多媒体文件体积过于庞大，难以实现网络的实时传播。而MPEG4技术的标准是对运动图像中的内容进行编码，其具体的编码对象就是图像中的音频和视频，术语称为“AV对象”，而连续的AV对象组合在一起又可以形成AV场景。因此，MPEG4标准就是围绕着AV对象的编码、存储、传输和组合而制定的，高效率地编码、组织、存储、传输AV对象是MPEG4标准的基本内容。 在视频编码方面，MPEG4支持对自然和合成的视觉对象的编码。（合成的视觉对象包括2D、3D动画和人面部表情动画等）。在音频编码上，MPEG4可以在一组编码工具支持下，对语音、音乐等自然声音对象和具有回响、空间方位感的合成声音对象进行音频编码。 由于MPEG4只处理图像帧与帧之间有差异的元素，而舍弃相同的元素，因此大大减少了合成多媒体文件的体积。应用MPEG4技术的影音文件最显著特点就是压缩率高且成像清晰，一般来说，一小时的影像可以被压缩为350M左右的数据，而一部高
RTP 参考文档 RFC3550/RFC3551 Real-time Transport Protocol)是用于Internet上针对多媒体数据流的一种传输层协议。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通（Push to Talk）系统（配合H.323或SIP），使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是建立在UDP协议上的。 RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。 RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。 RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。 RTP 由两个紧密链接部分组成： RTP ―传送具有实时属性的数据；RTP 控制协议（RTCP）―监控服务质量并传送正在进行的会话参与者的相关信息。 RTCP 实时传输控制协议（Real-time Transport Control Protocol或RTP Control Protocol或简写RTCP）是实时传输协议（RTP）的一个姐妹协议。RTCP为RTP媒体流提供信道外（out-of-band）控制。RTCP本身并不传输数据，但和RTP一起协作将多媒体数据打包和发送。RTCP定期在流多媒体会话参加者之间传输控制数据。RTCP的主要功能是为RTP 所提供的服务质量（Quality of Service）提供反馈。 RTCP收集相关媒体连接的统计信息，例如：传输字节数，传输分组数，丢失分组数，jitter，单向和双向网络延迟等等。网络应用程序可以利用RTCP所提供的信息试图提高服务质量，比如限制信息流量或改用压缩比较小的编解码器。RTCP本身不提供数据加密或身份认证。SRTCP可以用于此类用途。 SRTP & SRTCP 参考文档 RFC3711 安全实时传输协议（Secure Real-time Transport Protocol或SRTP）是在实时传输协议（Real-time Transport Protocol或RTP）基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。它是由David Oran（思科）和Rolf Blom（爱立信）开发的，并最早由IETF于2004年3 月作为RFC3711发布。
E-mail：bryanj@http://biz.doczj.com/doc/fc11005820.html, 译者：Bryan.Wong（王晶，宁夏固原） 译文版本：alpha 0.80 译文发布时间：2007-7-25 版权：本中文翻译文档之版权归王晶所有。可于非商业用途前提下自由转载，但必须保留此翻译及版权信息。 http://biz.doczj.com/doc/fc11005820.html,/filedownload?user=bryanj&id=611206 网络工作组 H. Schulzrinne 请求注释: 2326 哥伦比亚大学. 类别: 标准跟踪 A. Rao Netscape R. Lanphier RealNetworks 1998年4月 实时流协议(RTSP) 本备忘录状态 本文为Internet社区描述了一种Internet标准跟踪协议，还需要讨论和建议以便进行改善。请查看最新版本的"Internet正式协议标准"（STD 1）了解本协议的标准化进程和状态。本备忘录的传播不受限制。 版权声明： 版权为The Internet Society 所有。所有权利保留。 摘要： 实时流协议（RTSP）是应用层协议，控制实时数据的传送。RTSP提供了一个可扩展框架，使受控、按需传输实时数据（如音频与视频）成为可能。数据源包括现场数据与存储在剪辑中的数据。本协议旨在于控制多个数据发送会话，提供了一种选择传送途径（如UDP、组播UDP与TCP）的方法，并提供了一种选择基于RTP (RFC1889)的传送机制的方法。
目录： 1 介绍 1.1 目的 1.2 要求 1.3 术语 1.4 协议特性 1.5 RTSP扩展 1.6 整体运作 1.7 RTSP状态 1.8 与其他协议的关系 2 符号协定 3 协议参数 3.1 RTSP版本 3.2 RTSP URL 3.3 会议标识 3.4 会话标识 3.5 SMPTE 相对时间戳 3.6正常播放时间 3.7 绝对时间 3.8 选项标签 3.8.1 用IANA注册新的选项标签*4 RTSP消息 4.1 消息类型 4.2 消息头
全球眼 实时视频传输和控制协议v2 修改历史 复审人
一、说明 这份协议描述了视频服务器与流媒体分发服务器、视频服务器与企业客户端之间传输实时视频的方法。文档中没有针对媒体分发服务器与企业客户端（第三方播放器）之间的通信方法，但是媒体分发服务器与企业客户端（第三方播放器）之间的通信方法尊守RTC1889和RPC2326定义的规范。 在这篇文档里我们把象视频服务器这样能够给观看者提供视频数据的设备称为逻辑上的服务端角色（也就是视频源），象企业客户端这样播放视频的终端设备称为逻辑上的客户端角色（也就是接收者或观看者）。流媒体分发服务器同时具有两种角色。 交互流程中列出了两种模式，我们当前要先实现接模式。推模式是为了视频服务器在私网环境时也可以通过流媒体发服务器向用户提供视频服务。推模式暂不实现。 协议中没有提及RTCP协议，但并不影响视频通信质量，而且目前很难实现有效的编解码之间返馈的处理方法，所以现在，以及将来的一段时间都不会考虑RTCP协议，除非出现有效的视频质量控制机制。 本文参考RFC 1889、1890、2326、3550完成，如有不符合标准的、或者不完善的陈述，请提出来，发电子邮件到piaoxichuang@。如果您有更好的想法也可以通过邮件进行交流。 二、协议 通信方式使用RTP over TCP方式。（RTC1889、RFC2326） 1、一个完整的包 网络字节顺序
2、RTP包的封装（RTP over TCP） 网络字节顺序 Channel Identifier：取值0。因为只有一个流在一个TCP连接中传递，同时不使用RTCP协议。参见RFC 2326 [10.12]节。 Lenth：取值为RTP包的大小，包括RTP头部，但不包含本身的4个字节，以BYTE为单位。 3、RTP 12字节头部 网络字节顺序 V：版本，取值2。[可能会使用0值，还没想清楚，可能的使用情况是为了实现防火墙穿透] P：附加数据，取值为0。 X：扩展头，取值为1。 CC：CSRC列表数量，取值为0。 M：记号，取值0或1。关于M字段的取值：如果扩展头中T字段为1，则当一个包（RTP Packet）是一个帧（Sample）的最后一个包时取值1，否则取值0；扩展头中T字段为1时，由于指令长度较小，一个RTP就可以传输完成，所以取值为1。除非要使用多个RTP包传输，最后一个RTP包取值为1，前面的包取值为0。 PT：负载类型，动态，取值96。参见RFC 1890 [7]节。 Sequence Number：RTP包的序号，初始值是随机的，不是0。 Timestamp：以视频编码算法提供者的需要填写或单调增长的时间戳。[将来可能把这个值也传递给视频解码算法中去。] SSRC：随机数，用于在同一个会话中区分不同的流。建议使用MD32。 UINT Y[4] If Y = MD5(X) Then MD32(X) = Y[1] ^ Y[2] ^ Y[3] ^ Y[4] 注：RTP包大小最大值为2048。（因为DSS支持的最大包为2048Bytes）
几种安全的网络传输协议 ·从URL谈起（可以直接跳到第4页看FTPS，HTTPS） 当我们想浏览一个网站的时候，只要在浏览器的地址栏里输入网站的地址就可以了，这个网站地址，术语叫做URL（Uniform Resource Locator)，译成中文即“统一资源定位符”。就像每家每户都有一个门牌地址一样，每个网页也都有一个互联网地址。当你在浏览器的地址框中输入一个URL或是单击一个超级链接时，URL就确定了要浏览的地址。 ·超文本传输协议HTTP 大家一定注意到，在输入网站地址时，http://这一部分通常不用输入，系统软件会自动补上，所有网页地址都少不了它。那么，http 究竟是个什么含义呢？ HTTP 是“超文本传输协议（Hypertext Transfer Protocol）”的意思。 简单地讲，HTTP协议是用于从WWW服务器传输超文本到本地浏览器的传送协议。浏览器通过超文本传输协议(HTTP)，将Web服务器上站点的网页代码提取出来，并翻译成漂亮的网页。 它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。这就是你为什么在浏览器中看到的网页地址都是以http://开头的原因。 基于HTTP协议的通讯的基本工作过程如下： 由于HTTP协议是基于请求/响应范式的（相当于客户机/服务器）。一个客户机与服务器建立连接后，发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息，包括请求修饰符、客户机信息和可能的内容。服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。 在互联网上，HTTP通讯通常发生在TCP/IP连接之上。缺省端口是TCP 80，但其它的端口也是可用的。HTTP只预示着一个可靠的传输。它并不特别指明网络传输媒介，HTTP传输可以在互联网上完成，也可以在其它网络的其它协议之上完成。 在WWW中，“客户机”与”服务器”是一个相对的概念，只存在于一个特定的连接期间，即在某个连接中的客户机在另一个连接中可能作为服务器。基于HTTP协议的客户机/服务器模式的信息交换过程，它分四个过程：建立连接、发送请求信息、发送响应信息、关闭连接。 任何服务器除了包括HTML文件以外，还有一个HTTP驻留程序，用于响应用户请求。你的浏览器是HTTP客户机，向服务器发送请求，当浏览器中输入了一个开始文件或点击了一个超级链接时，浏览器就向服务器发送了HTTP请求，此请求被送往由IP地址指定的URL。服务器的驻留程序接收到请求，在进行必要的操作后回送所要求的文件。在这一过程中，根据TCP/IP协议的规定，在网络上发送和接收的数据被分成一个或多个数据包（packet），每个数据包包括：要传送的数据；控制信息，即告诉网络怎样处理数据包。TCP/IP协议决定了每个数据包的格式。传输完成后的这些数据包再重新组合，还原为数据信息。从网络层次模型的角度讲，HTTP协议以及下面将要讲述的几种互联网传输协议都属于TCP/IP模型最上层的应用层协议。
公告：2010年SD2.0大会即将在上海召开了～历届参会网友精彩心得集锦[意见反馈][官方博客] 实时传输协议（RTP）和实时控制协议（RTCP）收藏 RTP是一种提供端对端传输服务的实时传输协议，用来支持在单目标广播和多目标广播网络服务中传输实时数据，而实时数据的传输则由RTCP协议来监视和控制。 RTP定义在RFC 使用RTP协议的应用程序运行在RTP之上，而执行RTP的程序运行在UDP的上层，目的 、
从应用开发人员的角度来看，可把RTP执行程序看成是应用程序的一部分，因为开发人员必需把RTP集成到应用程序中。在发送端，开发人员必需把执行RTP协议的程序写入到创建RTP信息包的应用程序中，然后应用程序把RTP信息包发送到UDP的套接接口(socket interface)，如图16-13所示；同样，在接收端，RTP信息包通过UDP套接接口输入到应用程序，因此开发人员必需把执行RTP协议的程序写入到从RTP信息包中抽出媒体数据的应用程序。 图16-13 RTP和UDP之间的接口
现以用RTP传输声音为例来说明它的工作过程。假设音源的声音是64 kb/s的PCM编码声音，并假设应用程序取20毫秒的编码数据为一个数据块(chunk)，即在一个数据块中有160个字节的声音数据。应用程序需要为这块声音数据添加RTP标题生成RTP信息包，这个标题包括声音数据的类型、顺序号和时间戳。然后RTP信息包被送到UDP套接接口，在那里再被封装在UDP信息包中。在接收端，应用程序从套接接口处接收RTP信息包，并从RTP 信息包中抽出声音数据块，然后使用RTP信息包的标题域中的信息正确地译码和播放声音。 如果应用程序不使用专有的方案来提供有效载荷类型(payload type)、顺序号或者时间戳，而是使用标准的RTP协议，应用程序就更容易与其他的网络应用程序配合运行，这是大家都