一句话：RTSP发起/终结流媒体、RTP传输流媒体数据 、RTCP对RTP进行控制，同步。
因为CTC标准里没有对RTCP进行要求，因此在标准RTSP的代码中没有看到相关的部分。而在私有RTSP的代码中，有关控制、同步等，是在RTP Header中做扩展定义实现的。另外，RFC3550(datatracker)可以看作是RFC1889的升级文档，只看RFC3550/RFC3551即可。
RTP(Real Time Transport Protocol)是针对Internet上多媒体数据流的一个传输协议, 由IETF(Internet工程任务组)作为RFC1889发布。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP或ATM等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。
多媒体数据传输的一个尖锐的问题就是不可预料数据到达时间。但是流媒体的传输是需要数据的适时的到达用以播放和回放。rtp协议就是提供了时间标签,序列号以及其它的结构用于控制适时数据的流放。在流的概念中”时间标签”是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后,就依照时间标签按照正确的速率恢复成原始的适时的数据。不同的媒体格式调时属性是不一样的。但是rtp本身并不负责同步，rtp只是传输层协议，为了简化运输层处理，提高该层的效率。将部分运输层协议功能（比如流量控制）上移到应用层完成。同步就是属于应用层协议完成的。它没有运输层协议的完整功能，不提供任何机制来保证实时地传输数据，不支持资源预留，也不保证服务质量。rtp报文甚至不包括长度和报文边界的描述。同时rtp协议的数据报文和控制报文的使用相邻的不同端口，这样大大提高了协议的灵活性和处理的简单性。
rtp协议和udp二者共同完成运输层协议功能。udp协议只是传输数据包，不管数据包传输的时间顺序。 rtp的协议数据单元是用udp分组来承载的。在承载rtp数据包的时候，有时候一帧数据被分割成几个包具有相同的时间标签，则可以知道时间标签并不是必须的。而udp的多路复用让rtp协议利用支持显式的多点投递，可以满足多媒体会话的需求。
rtp协议虽然是传输层协议但是它没有作为osi体系结构中单独的一层来实现。rtp协议通常根据一个具体的应用来提供服务，rtp只提供协议框架，开发者可以根据应用的具体要求对协议进行充分的扩展。
如下图所示
开始12个八进制出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。各段含义如下：
①版本（V）
version (V): 2 bits 2位，标识RTP版本,协议初始版本为0，RFC3550中规定的版本号为2。。
②填充标识（P）
padding (P): 1 bit 1位，如设置填充位，在包末尾包含了额外的附加信息，它不属于有效载荷。附加信息的最后一个字节表示额外附加信息的长度（包含该字节本身）。该字段之所以存在是因为某些加密算法需要固定大小的填充字，或为在底层协议数据单元中携带几个RTP包。
③扩展（X）
extension (X): 1 bit 1位，如果该位被设置，则在固定的头部后存在一个扩展头部，格式定义在RFC3550 5.3.1节。
④CSRC计数（CC）
CSRC count (CC): 4 bits 4位，CSRC计数包括紧接在固定头后标识CSRC个数。
⑤标记（M）
marker (M): 1 bit 1位，标记解释由设置定义，目的在于允许重要事件在包流中标记出来。设置可定义其他标示位，或通过改变位数量来指定没有标记位，该位的功能依赖于profile的定义。profile可以改变该位的长度，但是要保持marker和payload type总长度不变（一共是8 bit）。。
⑥载荷类型（PT）
payload type (PT): 7 bits 7位，记录后面资料使用哪种 Codec ， receiver 端找出相应的 decoder 解碼出來，该位标记着RTP packet所携带信息的类型，标准类型列出在RFC3551中。如果接收方不能识别该类型，必须忽略该packet。
⑦系列号
sequence number:16 bits 16位，系列号随每个RTP数据包发送后而增加1，接收方可以根据该序列号重新排列数据包顺序，或者探测包损失。系列号初值是随机的，使对加密的文本攻击更加困难。
⑧时标
timestamp: 32 bits 32位，时标反映RTP数据包中第一个八进制数的采样时刻，采样时刻必须从单调、线性增加的时钟导出，以允许同步与抖动计算。时标可以让receiver端知道在正确的时间将资料播放出来。
由上图可知，如果只有系列号，并不能完整按照顺序的将data播放出来，因为如果data中间有一段是没有资料的，只有系列号的话会造成错误，需搭配上让它知道在哪个时间将data正确播放出来，如此我们才能播放出正确无误的信息。
⑨SSRC
SSRC: 32 bits 32位，SSRC段标识同步源。此标识不是随机选择的，目的在于使同一RTP包连接中没有两个同步源有相同的SSRC标识，也就是在一个RTP Session其间每个数据流都应该有一个不同的SSRC。尽管多个源选择同一个标识的概率很低，所有RTP实现都必须探测并解决冲突。如源改变源传输地址，也必须选择一个新SSRC标识以避免插入成环行源。
⑩CSRC列表
CSRC list: 0 to 15 items bits0到15项，每项32位。CSRC列表表示包内的对载荷起作用的源。标识数量由CC段给出。如超出15个作用源，也仅标识15个。CSRC标识由混合器插入，采用作用源的SSRC标识。只有存在Mixer的时候才有效。如一个将多声道的语音流合并成一个单声道的语音流，在这里就列出原来每个声道的SSRC。
从RTP数据报的格式不难看出，它包含了传输媒体的类型、格式、序列号、时间戳以及是否有附加数据等信息，这些都为实时的流媒体传输提供了相应的基础。RTP协议的目的是提供实时数据（如交互式的音频和视频）的端到端传输服务，因此在RTP中没有连接的概念，它可以建立在底层的面向连接或面向非连接的传输协议之上；RTP也不依赖于特别的网络地址格式，而仅仅只需要底层传输协议支持组帧（Framing）和分段（Segmentation）就足够了；另外RTP本身还不提供任何可靠性机制，这些都要由传输协议或者应用程序自己来保证。在典型的应用场合下，RTP一般是在传输协议之上作为应用程序的一部分加以实现的 ，如下图所示：
RTCP(Real Time Contorl Protocol)负责管理传输质量在当前应用进程之间交换控制信息。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。
当应用程序开始一个rtp会话时将使用两个端口：一个给rtp，一个给rtcp。rtp本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠rtcp提供这些服务。在rtp的会话之间周期的发放一些rtcp包以用来传监听服务质量和交换会话用户信息等功能。rtcp包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。rtp和rtcp配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。根据用户间的数据传输反馈信息，可以制定流量控制的策略，而会话用户信息的交互，可以制定会话控制的策略。
RTCP协议将控制包周期发送给所有连接者，应用与数据包相同的分布机制。低层协议提供数据与控制包的复用，如使用单独的UDP端口号。RTCP执行下列四大功能：
主要是提供数据发布的质量反馈。是作为RTP传输协议的一部分，与其他传输协议的流和阻塞控制有关。反馈对自适应编码控制直接起作用，但IP组播经验表明，从发送者收到反馈对诊断发送错误是致关重要的。给所有参加者发送接收反馈报告允许问题观察者估计那些问题是局部的，还是全局的。诸如IP组播等发布机制使网络服务提供商类团体可能接收反馈信息，充当第三方监控者来诊断网络问题。反馈功能由RTCP发送者和接收者报告执行。
RTCP带有称作规范名字（CNAME）的RTP源持久传输层标识。如发现冲突，或程序重新启动，既然SSRC标识可改变，接收者需要CNAME跟踪参加者。接收者也需要CNAME 与相关RTP连接中给定的几个数据流联系
前两种功能要求所有参加者发送RTCP包，因此，为了RTP扩展到大规模数量，速率必须受到控制。让每个参加者给其它参加者发送控制包，就大独立观察参加者数量。该数量用语计算包发送的速率。
第四个可选功能是传送最小连接控制信息，如参加者辨识。最可能用在"松散控制"连接，那里参加者自由进入或离开，没有成员控制或参数协调，RTCP充当通往所有参加者的方便通道，但不必支持应用的所有控制通讯要求。在IP组播场合应用RTP时，前3个功能是必须的，推荐用于所有情形。RTP应用设计人员必须避免使用仅在单播模式下工作的机制，那将导致无法扩展规模。
RTCP数据报
在RTCP通信控制中，RTCP协议的功能是通过不同的RTCP数据报来实现的，主要有如下几种类型：
①SR:发送端报告，所谓发送端是指发出RTP数据报的应用程序或者终端，发送端同时也可以是接收端。
②RR:接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。
③SDES:源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。
④BYE:通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。
⑤APP:由应用程序自己定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很大的灵活性。
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项
BYE：断开RTCP包
如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC/CSRC 标识。如混合器关闭，它也应该发出一个BYE包，列出它所处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个8位八进制计数，后跟很多八进制文本，表示离开原因，如："camera malfunction"或"RTP loop detected"。字符串具有同样的编码，如在SDES 中所描述的。如字符串填充包至下32位边界，字符串就不以空结尾；否则，BYE包以空八进制填充。
APP：定义应用的RTCP包
APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。
是由Real Networks和Netscape共同提出的。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。数据源包括现场数据与存储在剪辑中的数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、多播UDP与TCP提供途径，并为选择基于RTP上发送机制提供方法。RTSP参考文档 RFC2336
RTSP（Real Time Streaming Protocol）是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。而前面提到的允许同时多个串流需求控制（Multicast），除了可以降低服务器端的网络用量，更进而支持多方视讯会议（Video Conference）。 因为与HTTP1.1的运作方式相似，所以代理服务器《Proxy》的快取功能《Cache》也同样适用于RTSP，并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。
RTSP协 议以客户服务器方式工作，它是一个多媒体播放控制协议，用来使用户在播放从因特网下载的实时数据（音频和视频流）时能够进行控制，如：暂停/继 续、后退、前进等。因此 RTSP 又称为“因特网录像机遥控协议”。
要实现 RTSP 的控制功能，不仅要有协议，而且要有专门的媒体播放器(media player)和 媒体服务器(media server)。媒体服务器与媒体播放器的关系是服务器与客户的关系。媒体服务器与普通的万维网服务器的最大区别就是媒体服务器支持流式音频和视频的传送，因而在客户端的媒体播放器可以边下载边播放（需要先缓存一小段时间的节 目）。但从普通万维网服务器下载多媒体节目时，是先将整个文件下载完毕，然后再进行播放。RTSP 仅仅是使媒体播放器能控制多媒体流的传送。因此，RTSP 又称为带外协议，而多媒体流是使用 RTP 在带内传送的。如图所示
● 可扩展性：新方法和参数很容易加入RTSP。
● 易解析：RTSP可由标准 HTTP或MIME解析器解析。
● 安全：RTSP使用网页安全机制。
● 独立于传输：RTSP传输通道，可使用不可靠数据包协议（UDP）或可靠数据包协议（RDP），如要实现应用级可靠，可使用诸如TCP的可靠流协议。
● 记录设备控制：协议可控制记录和回放设备。
● 适合专业应用：通过SMPTE 时标，RTSP支持帧级精度，允许远程数字编辑。
● 演示描述中立：协议未强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少需包含一个RTSP URI。
● 代理与防火墙友好：协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个“缺口”。
● 适当的服务器控制：如用户启动一个流，则也可以停止一个流。
● 传输协调：实际处理连续媒体流前，用户可协调传输方法。
● 性能协调：如基本特征无效，则必须有一些清理机制让用户决定那种方法不生效。这允许用户提出适合自己的界面。
RTSP在功能上与HTTP有重叠，最明显的交叉是在流媒体内容的发布上——----大多是通过网页进行的。目前的协议规范同时允许网页服务器和流媒体服务器支持RTSP实现。例如，演示描述可通过HTTP或RTSP获取，这样减少了基于浏览器情况下的往返传递时间，同时也支持独立的RTSP 服务器与不依赖HTTP的客户端通信。
但是，RTSP与HTTP 的本质差别在于以下五个方面
● RTSP和HTTP是两个不同的协议，它们采用不同的方法和协议标志符。
● RTSP协议的数据发送不占用协议带宽，并且以不同的协议发送。
● HTTP是一个不对称协议，客户端发出请求，服务器应答。在RTSP中，客户端和服务器都可发出请求，且请求是有状态的。
● HTTP是一个无状态协议，而RTSP在任何情况下，必须保持一定状态，以便在请求确认后的很长时间内，仍可设置参数，控制媒体流。
● RTSP使用ISO 10646（UTF-8）定义，而不使用ISO 8859-1定义，保持与当前的HTML一致。
虽然大多数实时媒体采用RTP作为传输协议，但RTSP并不绑定RTP。重用HTTP的功能至少在两个方面有好处:安全和代理。由于要求非常接近，因此在缓存、代理和授权上采用HTTP功能是有价值的。
HTTP与RTSP传输的差别。概括的讲，RTSP被许多公司防火墙拒绝，而HTTP可以作为一个普通的文件通过；RTSP适合于大数据量、高可用性的流，如直播事件、长事件或大型文件；HTTP更适合于较小的数据传输和交互；当终端用户正在观看时，RTSP允许用户在服务器有效的回放媒体，HTTP更象下载一段媒体并在客户机上播放。从终端用户观点来看，RTSP看起来像是文件从中心位置播放，有点象广播，而HTTP感觉更象时从视频库中取视频，并在家里的机器上播放。从服务质量的观点上看，对于流，RTSP有更好的体验，RTSP提供类似于VCR的媒体控制，如暂停、快进、倒退和绝对定位。使用HTTP传输，只能在整个流下载完成后，播放器软件再模拟该过程。虽然，RTSP能够使用TCP或UDP，但是RTSP控制经常与RTP联合使用，以最好的服务质量传送实际的媒体数据。
RTSP有两类报文：请求报文和响应报文。
请求报文是指从客户向服务器发送请求报文，响应报文是指从服务器到客户的回答。由于RTSP是面向正文的(text-oriented)，因此在报文中的每一个字段都是一些 ASCII 码串，因而每个字段的长度都是不确定的。RTSP报文由三部分组成，即开始行、首部行和实体主体。在请求报文中，开始行就是请求行，RTSP请求报文的结构如图所示。
RTSP请求报文的方法包括：OPTIONS（获得服务器提供的可用方法）、DESCRIBE（得到会话描述信息）、SETUP（客户端提醒服务器建立会话，并确定传输模式）、TEARDOWN（客户端发起关闭请求）、ANNOUNCE(更新会话描述）、PLAY（客户端发送播放请求）、PAUSE（临时停止流，而不释放服务器资源）、GET_PARAMETER（取得流控制参数，可能某些服务器不支持）和SET_PARAMETER（设置流控制参数，可能某些服务器不支持）。响应报文的开始行是状态行，RTSP响应报文的结构如图所示。
C表 示RTSP客户端，S表示RTSP服务端
① C->S: OPTION request //询问S有 哪些方法可用
S->C: OPTION response //S回 应信息中包括提供的所有可用方法
② C->S: DESCRIBE request //要求得到S提供 的媒体初始化描述信息
S->C: DESCRIBE response //S回 应媒体初始化描述信息，主要是sdp
③ C->S: SETUP request //设置会话属性，以及传输模式，提醒S建 立会话
S->C: SETUP response //S建 立会话，返回会话标识符及会话相关信息
④ C->S: PLAY request //C请求播放
S->C: PLAY response //S回 应请求信息
S->C: 发送流媒体数据
⑤ C->S: TEARDOWN request //C请 求关闭会话
S->C: TEARDOWN response //S回应请求
上述的过程是标准的RTSP流程，其中第3步和第4步是必需的。
http和rtsp在功能上有相似重叠的地方，RTSP采用了HTTP/1.1 大多数的状态码，并且增加了RTSP特定的状态码。
HTTP协议定义了8种可能的请求方法：
————————————
GET 检索URI中标识资源的一个简单请求
HEAD 与GET方法相同，服务器只返回状态行和头标，并不返回请求文档
POST 服务器接受被写入客户端输出流中的数据的请求
PUT 服务器保存请求数据作为指定URI新内容的请求
DELETE 服务器删除URI中命名的资源的请求
OPTIONS 关于服务器支持的请求方法信息的请求
TRACE Web服务器反馈Http请求和其头标的请求
CONNECT 已文档化但当前未实现的一个方法，预留做隧道处理
————————————
rtsp和http的协议规范分别在RFC2326 和 RFC2616有详细描述
mms协议为微软的私有协议，未公开协议。采用私有自定义控制结构体来发送命令，而不是像http，rtsp协议采用发送文本命令控制
RTP/RTSP/RTCP的区别 用一句简单的话总结：RTSP发起/终结流媒体、RTP传输流媒体数据 、RTCP对RTP进行控制，同步。
RTP不象http和ftp可完整的下载整个影视文件，它是以固定的数据率在网络上发送数据，客户端也是按照这种速度观看影视文件，当影视画面播放过后，就不可以再重复播放，除非重新向服务器端要求数据。
RTSP与RTP最大的区别在于：RTSP是一种双向实时数据传输协议，它允许客户端向服务器端发送请求，如回放、快进、倒退等操作。当然，RTSP可基于RTP来传送数据，还可以选择TCP、UDP、组播UDP等通道来发送数据，具有很好的扩展性。它时一种类似与http协议的网络应用层协议。目前碰到的一个应用：服务器端实时采集、编码并发送两路视频，客户端接收并显示两路视频。由于客户端不必对视频数据做任何回放、倒退等操作，可直接采用UDP+RTP+组播实现。如下图所示
RTP传输音频/视频数据，如果是PLAY，Server发送到Client端，如果是RECORD，可以由Client发送到Server
整个RTP协议由两个密切相关的部分组成：RTP数据协议和RTP控制协议（即RTCP）。
RTSP的请求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等，顾名思义可以知道起对话和控制作用
RTSP的对话过程中SETUP可以确定RTP/RTCP使用的端口，PLAY/PAUSE/TEARDOWN可以开始或者停止RTP的发送
RTSP在制定时较多地参考了HTTP/1.1协议，甚至许多描述与HTTP/1.1完全相同。RTSP之所以特意使用与HTTP/1.1类似的语法和操作，在很大程度上是为了兼容现有的Web基础结构，正因如此，HTTP/1.1的扩展机制大都可以直接引入到RTSP中。 由RTSP控制的媒体流集合可以用表示描述（Presentation Description）来定义，所谓表示是指流媒体服务器提供给客户机的一个或者多个媒体流的集合，而表示描述则包含了一个表示中各个媒体流的相关信息，如数据编码/解码算法、网络地址、媒体流的内容等。 虽然RTSP服务器同样也使用标识符来区别每一流连接会话（Session），但RTSP连接并没有被绑定到传输层连接（如TCP等），也就是说在整个RTSP连接期间，RTSP用户可打开或者关闭多个对RTSP服务器的可靠传输连接以发出RTSP 请求。此外，RTSP连接也可以基于面向无连接的传输协议（如UDP等）。
RTSP协议目前支持以下操作： 检索媒体：允许用户通过HTTP或者其它方法向媒体服务器提交一个表示描述。如表示是组播的，则表示描述就包含用于该媒体流的组播地址和端口号；如果表示是单播的，为了安全在表示描述中应该只提供目的地址。 邀请加入：媒体服务器可以被邀请参加正在进行的会议，或者在表示中回放媒体，或者在表示中录制全部媒体或其子集，非常适合于分布式教学。 添加媒体：通知用户新加入的可利用媒体流，这对现场讲座来讲显得尤其有用。与HTTP/1.1类似，RTSP请求也可以交由代理、通道或者缓存来进行处理。
参考 RFC3711
安全实时传输协议（Secure Real-time Transport Protocol或SRTP）是在实时传输协议（Real-time Transport Protocol或RTP）基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。它是由David Oran（思科）和Rolf Blom（爱立信）开发的，并最早由IETF于2004年3月作为RFC3711发布。
由于实时传输协议和可以被用来控制实时传输协议的会话的实时传输控制协议（RTP Control Protocol或RTCP）有着紧密的联系，安全实时传输协议同样也有一个伴生协议，它被称为安全实时传输控制协议（Secure RTCP或SRTCP）；安全实时传输控制协议为实时传输控制协议提供类似的与安全有关的特性，就像安全实时传输协议为实时传输协议提供的那些一样。
在使用实时传输协议或实时传输控制协议时，使不使用安全实时传输协议或安全实时传输控制协议是可选的；但即使使用了安全实时传输协议或安全实时传输控制协议，所有它们提供的特性（如加密和认证）也都是可选的，这些特性可以被独立地使用或禁用。唯一的例外是在使用安全实时传输控制协议时，必须要用到其消息认证特性。
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有 
