1.1. RTSP协议简介
一种应用层协议，可基于tcp或udp协议。
Real Time Streaming Protocol或者RTSP（实时流媒体协议），是由Real network 和 Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议。RTSP提供一 种可扩展的框架，使能够提供可控制的，按需传输实时数据，比如音频和视频文件。源数据可以包括现场数据的反馈和存贮的文件。rtsp对流媒体提供了诸如暂停，快进等控制，而它本身并不传输数据，rtsp作用相当于流媒体服务器的远程控制。传输数据可以通过传输层的tcp，udp协议，rtsp也提供了基于rtp传输机制的一些有效的方法。
实 时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体，如音频和视频。尽管连续媒体流与控制流交叉是可能的，RTSP 本身并不发送连续媒体流。换言之，RTSP 充当多媒体服务器的网络远程控制。RTSP 提供了一个可扩展框架，实现实时数据（如音频与视频）的受控、按需传送。数据源包括实况数据与存储的剪辑。RTSP 用于控制多个数据发送会话，提供了选择发送通道（如 UDP、组播 UDP 与 TCP 等）的方式，并提供了选择基于 RTP 的发送机制的方法。
目前还没有 RTSP 连接的概念；服务器维护由识别符标识的会话。RTSP 会话不会绑定到传输层连接，如 TCP。在 RTSP 会话期间，RTSP 客户端可打开或关闭多个对服务器的可靠传输连接以发出 RTSP 请求。它也可选择使用无连接传输协议，如 UDP.
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请求也可以交由代理、通道或者缓存来进行处理。
RTSP 控制的流可能用到 RTP，但 RTSP 操作并不依赖用于传输连续媒体的传输机制。RTSP 在语法和操作上与 HTTP/1.1 类似，因此 HTTP 的扩展机制在多数情况下可加入 RTSP。然而，在很多重要方面 RTSP 仍不同于 HTTP ：
1. RTSP 引入了大量新方法并具有一个不同的协议标识符： 2. 在大多数情况下，RTSP 服务器需要保持缺省状态，与 HTTP 的无状态相对； 3. RTSP 中客户端和服务器都可以发出请求； 4. 在多数情况下，数据由不同的协议传输； 5. RTSP 使用 ISO 10646 （UTF-8）而并非 ISO 8859-1，与当前的国际标准 HTML 相一致； 6. URI 请求总是包含绝对 URI。为了与过去的错误相互兼容，HTTP/1.1 只在请求过程中传送绝对路径并将主机名置于另外的头字段。
该协议支持如下操作：
1. 从媒体服务器上检索媒体：用户可通过 HTTP 或其它方法提交一个演示描述请求； 2. 媒体服务器邀请进入会议： 媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录部分或全部演示； 3. 将新媒体加到现有演示中：如服务器能告诉客户端接下来可用的媒体内容，对现场直播显得尤其有用
要实现 RTSP 的控制功能，不仅要有协议，而且要有专门的媒体播放器(media player)和媒体服务器(media server)。媒体服务器与媒体播放器的关系是服务器与客户的关系。
媒体服务器与普通的万维网服务器的最大区别就是媒体服务器支持流式音频和视频的传送，因而在客户端的媒体播放器可以边下载边播放（需要先缓存一小段时间的节目）。但从普通万维网服务器下载多媒体节目时，是先将整个文件下载完毕，然后再进行播放。
图1 RTSP与RTP和RTCP的关系
RTSP 仅仅是使媒体播放器能控制多媒体流的传送。因此，RTSP 又称为带外协议，而多媒体流是使用 RTP 在带内传送的。
1.2. RTSP的报文结构
RTSP的消息有两大类,一是请求消息(request),一是回应消息(response),两种消息的格式不同. 请求报文是指从客户向服务器发送请求报文，响应报文是指从服务器到客户的回答。
由于 RTSP 是面向正文的(text-oriented)，因此在报文中的每一个字段都是一些 ASCII 码串，因而每个字段的长度都是不确定的。RTSP报文由三部分组成，即开始行、首部行和实体主体。在请求报文中，开始行就是请求行，RTSP请求报文的结构如图2所示。
图2 RTSP请求报文的结构
方法 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请求报文的方法包括：OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER和SET_PARAMETER。RTSP请求报文的常用方法及作用如表1所示。
|
方法 |
作用 |
|
OPTIONS |
获得服务器提供的可用方法 |
|
DESCRIBE |
得到会话描述信息 |
|
SETUP |
客户端提醒服务器建立会话，并确定传输模式 |
|
TEARDOWN |
客户端发起关闭请求 |
|
PLAY |
客户端发送播放请求 |
响应报文的开始行是状态行，RTSP响应报文的结构如图3所示。
RTSP版本 状态码 解释 CR LF
消息头 CR LF CR LF
消息体 CR LF
其中RTSP版本一般都是RTSP/1.0,状态码是一个数值,200表示成功,解释是与状态码对应 的文本解释。
1.3. RTSP交互过程
简单的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回应该请求的信息 5.S->C: 发送流媒体数据 6.C->S:TEARDOWN request //C请求关闭会话 6.S->C:TEARDOWN response //S回应该请求
上述的过程是标准的、友好的rtsp流程，但实际的需求中并不一定按部就班来。 其中第3和4步是必需的！ 第一步，只要服务器客户端约定好，有哪些方法可用，则option请求可以不要。第二步，如果我们有其他途径得到媒体初始化描述信息（比如http请求等等），则我们也不需要通过rtsp中的describe请求来完成。第五步，可以根据系统需求的设计来决定是否需要。
rtsp中常用方法：
1. OPTION 目的是得到服务器提供的可用方法:
OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0 CSeq: 1 // 每个消息都有序号来标记，第一个包通常是option请求消息 User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10) // 服务器的回应信息包括提供的一些方法,例如: RTSP/1.0 200 OK Server: UServer 0.9.7_rc1 Cseq: 1 // 每个回应消息的cseq数值和请求消息的cseq相对应 Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SCALE, GET_PARAMETER // 服务器提供的可用的方法
2. DESCRIBE C向S发起DESCRIBE请求,为了得到会话描述信息(SDP):
DESCRIBE rtsp://192.168.20.136:5000/xxx666 RTSP/1.0 CSeq: 2 // 如果没有 option 交互，此处的CSeq依然为2 token: Accept: application/sdp Timeshift: 0 x-Retrans: yes x-NAT: 192.168.123.110:36550 User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10) // 服务器回应一些对此会话的描述信息(sdp): RTSP/1.0 200 OK Server: UServer 0.9.7_rc1 Cseq: 2 x-prev-url: rtsp://192.168.20.136:5000 x-next-url: rtsp://192.168.20.136:5000 x-Accept-Retransmit: our-retransmit x-Accept-Dynamic-Rate: 1 Cache-Control: must-revalidate Last-Modified: Fri, 10 Nov 2006 12:34:38 GMT Date: Fri, 10 Nov 2006 12:34:38 GMT Expires: Fri, 10 Nov 2006 12:34:38 GMT Content-Base: rtsp://192.168.20.136:5000/xxx666/ Content-Length: 344 Content-Type: application/sdp v=0 // 以下都是sdp信息 o=OnewaveUServerNG 1451516402 1025358037 IN IP4 192.168.20.136 s=/xxx666 u=http:/// e=admin@ c=IN IP4 0.0.0.0 t=0 0 a=isma-compliance:1,1.0,1 a=range:npt=0- m=video 0 RTP/AVP 96 //m表示媒体描述，下面是对会话中视频通道的媒体描述 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=245;config=000001B0F5000001B509000001000000012000C888B0E0E0FA62D089028307 a=control:trackID=0 //trackID＝0 表示视频流用的是通道0
3. SETUP 客户端提醒服务器建立会话,并确定传输模式:
SETUP rtsp://192.168.20.136:5000/xxx666/trackID=0 RTSP/1.0 CSeq: 3 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10) //uri中带有trackID＝0，表示对该通道进行设置。Transport参数设置了传输模式，包的结构。
//接下来的数据包头部第二个字节位置就是interleaved，它的值是每个通道都不同的，trackID＝0的interleaved值有两个0或1，0表示rtp包，1表示rtcp包，接受端根据interleaved的值来区别是哪种数据包。 //服务器回应信息: RTSP/1.0 200 OK Server: UServer 0.9.7_rc1 Cseq: 3 Session: 6310936469860791894 //服务器回应的会话标识符 Cache-Control: no-cache Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=6B8B4567
4. PLAY 客户端发送播放请求:
PLAY rtsp://192.168.20.136:5000/xxx666 RTSP/1.0 CSeq: 4 Session: 6310936469860791894 Range: npt=0.000- //设置播放时间的范围 User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10) // 服务器回应信息: RTSP/1.0 200 OK Server: UServer 0.9.7_rc1 Cseq: 4 Session: 6310936469860791894 Range: npt=0.000000- RTP-Info: url=trackID=0;seq=17040;rtptime=1467265309 //seq和rtptime都是rtp包中的信息
5. PAUSE 客户端发起暂停请求:
PAUSE rtsp://192.168.20.136:5000/xxx666 RTSP/1.0 Cseq: 5 Session: 6310936469860791894 // 服务器回应: RTSP/1.0 200 OK Server: UServer 0.9.7_rc1 Cseq: 5 Session: 6310936469860791894
6.TEARDOWN 客户端发起关闭请求:
TEARDOWN rtsp://192.168.20.136:5000/xxx666 RTSP/1.0 CSeq: 6 Session: 6310936469860791894 User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10) // 服务器回应: RTSP/1.0 200 OK Server: UServer 0.9.7_rc1 Cseq: 6 Session: 6310936469860791894 Connection: Close
7. 其他方法
以上方法都是交互过程中最为常用的,其它还有一些重要的方法如: get/set_parameter,redirect,scale等等
sdp的格式
v=<version> o=<username> <session id> <version> <network type> <address type> <address> s=<session name> i=<session description> u=<URI> e=<email address> p=<phone number> c=<network type> <address type> <connection address> b=<modifier>:<bandwidth-value> t=<start time> <stop time> r=<repeat interval> <active duration> <list of offsets from start-time> z=<adjustment time> <offset> <adjustment time> <offset> .... k=<method> k=<method>:<encryption key> a=<attribute> a=<attribute>:<value> m=<media> <port> <transport> <fmt list> v = （协议版本） o = （所有者/创建者和会话标识符） s = （会话名称） i = * （会话信息） u = * （URI 描述） e = * （Email 地址） p = * （电话号码） c = * （连接信息） b = * （带宽信息） z = * （时间区域调整） k = * （加密密钥） a = * （0 个或多个会话属性行） 时间描述： t = （会话活动时间） r = * （0或多次重复次数） 媒体描述： m = （媒体名称和传输地址） i = * （媒体标题） c = * （连接信息 — 如果包含在会话层则该字段可选） b = * （带宽信息） k = * （加密密钥） a = * （0 个或多个媒体属性行）
RTSP 协议结构
RTSP 是一种文本协议，采用 UTF-8 编码中的 ISO 10646 字符集。一行可通过 CRLF 终止，但接收端需要做好解释 CR 和 LF 作为一行终止符的准备。关于头字段概述如下：
| Header | Type | Support | Methods |
| Accept | R | opt. | entity |
| Accept-Encoding | R | opt. | entity |
| Accept-Language | R | opt. | all |
| Allow | R | opt. | all |
| Authorization | R | opt. | all |
| Bandwidth | R | opt. | all |
| Blocksize | R | opt. | All but OPTIONS, TEARDOWN |
| Cache-Control | G | opt. | SETUP |
| Conference | R | opt. | SETUP |
| Connection | G | req. | all |
| Content-Base | E | opt. | entity |
| Content-Encoding | E | req. | SET_PARAMETER |
| Content-Encoding | E | req. | DESCRIBE, ANNOUNCE |
| Content-Language | E | req. | DESCRIBE, ANNOUNCE |
| Content-Length | E | req. | SET_PARAMETER, ANNOUNCE |
| Content-Length | E | req. | entity |
| Content-Location | E | opt. | entity |
| Content-Type | E | req. | SET_PARAMETER, ANNOUNCE |
| Content-Type | R | req. | entity |
| CSeq | G | req. | all |
| Date | G | opt. | all |
| Expires | E | opt. | DESCRIBE, ANNOUNCE |
| From | R | opt. | all |
| If-Modified-Since | R | opt. | DESCRIBE, SETUP |
| Last-Modified | E | opt. | entity |
| Proxy-Authenticate | |||
| Proxy-Require | R | req. | all |
| Public | R | opt. | all |
| Range | R | opt. | PLAY, PAUSE, RECORD |
| Range | R | opt. | PLAY, PAUSE, RECORD |
| Referer | R | opt. | all |
| Require | R | req. | all |
| Retry-After | R | opt. | all |
| RTP-Info | R | req. | PLAY |
| Scale | Rr | opt. | PLAY, RECORD |
| Session | Rr | req. | All but SETUP, OPTIONS |
| Server | R | opt. | all |
| Speed | Rr | opt. | PLAY |
| Transport | Rr | req. | SETUP |
| Unsupported | R | req. | all |
| User-Agent | R | opt. | all |
| Via | G | opt. | all |
| WWW-Authenticate | R | opt. | all |
类 型 "g" 表示请求和响应中的通用请求头；类型 "R" 表示请求头；类型 "r" 表示响应头；类型 "e" 表示实体头字段。在 "support" 一栏中 标有 "req." 的字段 必须由接收者以特殊的方法实现；而 "opt." 的字段是可选的。注意，不是所有 "req." 字段在该类型的每个请求中都会被发送。 "req." 只表示客户机（支持响应头）和服务器（支持请求头）必须执行该字段。最后一栏列出了关于头字段产生作用的方法；其中 "entity" 针对于返回一个信息主体的所有方法。
RTSP点播消息流程实例
客户端：VLC
RTSP服务器：LIVE555 Media Server
1)C(Client)-> M(Media Server) OPTIONS rtsp://192.168.1.109/1.mpg RTSP/1.0 CSeq: 1 user-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20) 1)M -> C RTSP/1.0 200 OK CSeq: 1 Date: wed, Feb 20 2008 07:13:24 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE 2)C -> M DESCRIBE rtsp://192.168.1.109/1.mpg RTSP/1.0 CSeq: 2 Accept: application/sdp User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20) 2)M -> C RTSP/1.0 200 OK CSeq: 2 Date: wed, Feb 20 2008 07:13:25 GMT Content-Base: rtsp://192.168.1.109/1.mpg/ Content-type: application/sdp Content-length: 447 v=0 o =- 2284269756 1 IN IP4 192.168.1.109 s=MPEG-1 or 2 program Stream, streamed by the LIVE555 Media Server i=1.mpg t=0 0 a=tool:LIVE555 Streaming Media v2008.02.08 a=type:broadcast a=control:* a=range:npt=0-66.181 a=x-qt-text-nam:MPEG-1 or Program Stream, streamed by the LIVE555 Media Server a=x-qt-text-inf:1.mpg m=video 0 RTP/AVP 32 c=IN IP4 0.0.0.0 a=control:track1 m=audio 0 RTP/AVP 14 c=IN IP4 0.0.0.0 a=control:track2 3)C -> M SETUP rtsp://192.168.1.109/1.mpg/track1 RTSP/1.0 CSeq: 3 Transport: RTP/AVP; unicast;client_port=1112-1113 User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20) 3)M -> C RTSP/1.0 200 OK CSeq: 3 Date: wed, Feb 20 2008 07:13:25 GMT Transport: RTP/AVP;unicast;destination=192.168.1.222;source=192.168.1.109;client_port=1112-1113;server_port=6970-6971 Session: 3 4)C -> M SETUP rtsp://192.168.1.109/1.mpg/track2 RTSP/1.0 CSeq: 4 Transport: RTP/AVP; unicast;client_port=1114-1115 Session: 3 User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20) 4)M -> C RTSP/1.0 200 OK CSeq: 4 Date: wed, Feb 20 2008 07:13:25 GMT Transport: RTP/AVP;unicast;destination=192.168.1.222;source=192.168.1.109;client_port=1114-1115;server_port=6972-6973 Session: 3 5)C -> M PLAY rtsp://192.168.1.109/1.mpg/ RTSP/1.0 CSeq: 5 Session: 3 Range: npt=0.000- User-Agent: VLC media player(LIVE555 Streaming Media v2007.02.20) 5)M -> C RTSP/1.0 200 OK CSeq: 5 Range: npt=0.000- Session: 3 RTP-Info: url=rtsp://192.168.1.109/1.mpg/track1;seq=9200;rtptime=214793785,url=rtsp://192.168.1.109/1.mpg/track2;seq=12770;rtptime=31721
rtsp和http的区别和联系
（1）联系：两者都用纯文本来发送消息，且rtsp协议的语法也和HTTP类似。Rtsp一开始这样设计，也是为了能够兼容使用以前写的HTTP协议分析代码 。
（2）区别：rtsp是有状态的，不同的是RTSP的命令需要知道现在正处于一个什么状态，也就是说rtsp的命令总是按照顺序来发送，某个命令总在另外一个命令之前要发送。Rtsp不管处于什么状态都不会去断掉连接。，而http则不保存状态，协议在发送一个命令以后，连接就会断开，且命令之间是没有依赖性的。rtsp协议使用554端口，http使用80端口。
2. RTP 协议介绍
实时传输协议（Real-time Transport Protocol，RTP）是在Internet上处理多媒体数据流的一种网络协议，由 IETF（http://www.ietf.org/）定义在 RFC 3550和3551中, 利用它能够在一对一（unicast，单播）或者一对多（multicast，多播）的网络环境中实现流媒体数据的实时传输。RTP通常使用UDP来进行多媒体数据的传输，但如果需要的话可以使用TCP或者ATM等其它协议，整个RTP协议由两个密切相关的部分组成：RTP数据协议和RTCP控制协议。RTP只负责实时数据的传输，RTCP负责对RTP的通信和会话进行带外管理（如流量控制、拥塞控制、会话源管理等）. 实时流协议（Real Time Streaming Protocol，RTSP）最早由Real Networks和Netscape公司共同提出，它位于RTP和RTCP之上，其目的是希望通过IP网络有效地传输多媒体数据。
2.1 RTP数据协议
RTP数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个RTP数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前12个字节的含义是固定的，而负载则可以是音频或者视频数据。RTP数据报的头部格式如图1所示：
在RTP分组的首部中，前12个字节是必须的，12字节以后的是可选的。
其中比较重要的几个域及其意义如下：
版本(V)： 2比特 此域定义了RTP的版本。此协议定义的版本是2。(值1被RTP草案版本使用，值0用在最初"vat"语音工具使用的协议中。)
填充(P)： 1比特 若填料比特被设置，则此包包含一到多个附加在末端的填充比特，填充比特不算作负载的一部分。填充的最后一个字节指明可以忽略多少个填充比特。填充可能用于某些具有固定长度的加密算法，或者用于在底层数据单元中传输多个RTP包。
扩展(X)： 1比特 若设置扩展比特，固定头(仅)后面跟随一个头扩展。
CSRC计数数（CC） 4比特 表示跟在固定头后面CSRC识别符的数目。CSRC标识紧跟在RTP固定头部之后，用来表示RTP数据报的来源，RTP协议允许在同一个会话中存在多个数据源，它们可以通过RTP混合器合并为一个数据源。例如，可以产生一个CSRC列表来表示一个电话会议，该会议通过一个RTP混合器将所有讲话者的语音数据组合为一个RTP数据源。
标志(M)： 1比特 标志的解释由具体协议规定。它用来允许在比特流中标记重要的事件，如帧边界。
负载类型（PT）: 7比特, 标明RTP负载的格式，包括所采用的编码算法、采样频率、承载通道等。例如，类型2表明该RTP数据包中承载的是用ITU G.721算法编码的语音数据，采样频率为8000Hz，并且采用单声道。 由具体应用决定其解释。协议可以规定负载类型码和负载格式之间一个默认的匹配。其他的负载类型码可以通过非RTP方法动态定义。RTP发送端在任意给定时间发出一个单独的RTP负载类型；此域不用来复用不同的媒体流。
序列号（sequence number）：16比特 每发送一个RTP数据包，序列号加1，接收端可以据此检测丢包和重建包序列。用来为接收方提供探测数据丢失的方法，但如何处理丢失的数据则是应用程序自己的事情，RTP协议本身并不负责数据的重传。
时间戳（timestamp） 32比特 时间戳记录了RTP数据包中第一个字节的采样时间。时间戳能够确定数据的到达是否受到了延迟抖动的影响，但具体如何来补偿延迟抖动则是应用程序自己的事情。（采样时钟必须来源于一个及时的单调、线性递增时钟，以便允许同步和去除网络引起的数据包抖动（见RFC3550章节6.4.1）。该时钟的分辨率必须满足理想的同步精度和测量数据包到来时的抖动的需要（一种典型的时钟分辨率不满足情况是每个视频帧仅一个时钟周期）时钟频率依赖于负载数据的格式，并在描述文件（profile）中或者是在负载格式描述中（payload format speci_cation）进行静态描述。也可以通过非RTP方法（non-RTP means）对负载格式动态描述。
如果RTP包是周期性产生的，那么将使用由采样时钟决定的名义上的采样时刻，而不是读取系统时间。例如，对一个固定速率的音频，采样时钟（时间戳时钟）将在每个周期内增加1。如果一个音频从输入设备中读取含有160个采样周期的块，那么对每个块，时间戳的值增加160，而不考虑该块是否用一个包传递或是被丢弃。
时间戳的初始值应当是随机的，就像序号一样。几个连续的RTP包如果（逻辑上）是同时产生的，如：属于同一个视频帧的RTP包，将有相同的序列号。如果数据并不是以它采样的顺序进行传输，那么连续的RTP包可以包含不是单调递增（或递减）的时间戳（RTP包的序列号仍然是单调变化的）。
SSRC：32比特 用以识别同步源。标识符应该被随机生成，以使在同一个RTP会话期中没有任何两个同步源有相同的SSRC识别符。一个用于创造随机标示符的示例算法在A.6第六章讲述。尽管多个源选择同一个SSRC识别符的概率很低，所有RTP实现工具都必须准备检测和解决冲突。第8章讲述了冲突的可能性及其解决机制。若一个源改变本身的源传输地址，必须选择新的SSRC识别符，以避免被当作一个环路源(see Section 8.2)。
CSRC列表：0到15项，每项32比特 CSRC列表指出了对此包中负载内容的所有贡献源。识别符的数目在CC域中给定。若有贡献源多于15个，仅识别15个。CSRC识别符由混合器插入(see Section 7.1)，并列出所有贡献源的SSRC识别符。例如语音包，混合产生新包的所有源的SSRC标识符都被列出，以在接收端处正确指示参与者。
从RTP数据报的格式不难看出，它包含了传输媒体的类型、格式、序列号、时间戳以及是否有附加数据等信息，这些都为实时的流媒体传输提供了相应的基础。RTP协议的目的是提供实时数据（如交互式的音频和视频）的端到端传输服务，因此在RTP中没有连接的概念，它可以建立在底层的面向连接或面向非连接的传输协议之上；RTP也不依赖于特别的网络地址格式，而仅仅只需要底层传输协议支持组帧（Framing）和分段（Segmentation）就足够了；另外RTP本身还不提供任何可靠性机制，这些都要由传输协议或者应用程序自己来保证。在典型的应用场合下，RTP一般是在传输协议之上作为应用程序的一部分加以实现的。
2.2 RTCP控制协议
RTCP控制协议需要与RTP数据协议一起配合使用，当应用程序启动一个RTP会话时将同时占用两个端口，分别供RTP和RTCP使用。RTP本身并不能为按序传输数据包提供可靠的保证，也不提供流量控制和拥塞控制，这些都由RTCP来负责完成。通常RTCP会采用与RTP相同的分发机制，向会话中的所有成员周期性地发送控制信息，应用程序通过接收这些数据，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进行控制或者对网络状况进行诊断。
RTCP协议的功能是通过不同的RTCP数据报来实现的，主要有如下几种类型：
SR 发送端报告，所谓发送端是指发出RTP数据报的应用程序或者终端，发送端同时也可以是接收端。
RR 接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。
SDES 源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。
BYE 通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。
APP 由应用程序自己定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很大的灵活性。
RTCP数据报携带有服务质量监控的必要信息，能够对服务质量进行动态的调整，并能够对网络拥塞进行有效的控制。由于RTCP数据报采用的是多播方式，因此会话中的所有成员都可以通过RTCP数据报返回的控制信息，来了解其他参与者的当前情况。
在一个典型的应用场合下，发送媒体流的应用程序将周期性地产生发送端报告SR，该RTCP数据报含有不同媒体流间的同步信息，以及已经发送的数据报和字节的计数，接收端根据这些信息可以估计出实际的数据传输速率。另一方面，接收端会向所有已知的发送端发送接收端报告RR，该RTCP数据报含有已接收数据报的最大序列号、丢失的数据报数目、延时抖动和时间戳等重要信息，发送端应用根据这些信息可以估计出往返时延，并且可以根据数据报丢失概率和时延抖动情况动态调整发送速率，以改善网络拥塞状况，或者根据网络状况平滑地调整应用程序的服务质量。
RTP的协议层次（灵活理解）
从应用开发者的角度看，RTP 应当是应用层的一部分。在应用的发送端，开发者必须编 写用 RTP 封装分组的程序代码，然后把 RTP 分组交给 UDP。在接收端，RTP 分组通过 UDP 进入应用层后，还要利用开发者编写的程序代码从 RTP 分组中把应用数据块提取出来。
RTP 封装了多媒体应用的数据块。由于 RTP 向多媒体应用程序提供了服务（如时间戳和序号），因此也可以将 RTP 看成是在 UDP 之上的一个运输层的子层。
RTP的工作机制
当应用程序建立一个RTP会话时，应用程序将确定一对目的传输地址。目的传输地址由一个网络地址和一对端口组成，有两个端口：一个给RTP包，一个 给RTCP包，使得RTP/RTCP数据能够正确发送。RTP数据发向偶数的UDP端口，而对应的控制信号RTCP数据发向相邻的奇数UDP端口（偶数的 UDP端口＋1），这样就构成一个UDP端口对。 RTP的发送过程如下，接收过程则相反。
1) RTP协议从上层接收流媒体信息码流（如H.263），封装成RTP数据包；RTCP从上层接收控制信息，封装成RTCP控制包。
2) RTP将RTP 数据包发往UDP端口对中偶数端口；RTCP将RTCP控制包发往UDP端口对中的奇数端口。
RTP分组只包含RTP数据，而控制是由另一个配套使用的RTCP协议提供。 RTP在1025到65535之间选择一个未使用的偶数UDP端口号，而在同一次会话中的RTCP则使用下一个奇数UDP端口号。端口号5004和 5005分别用作RTP和RTCP的默认端口号。RTP是目前解决流媒体实时传输问题的最好办法，存在一些开放源代码的RTP库，如LIBRTP、JRTPLIB等。JRTPLIB是一个面向对象的 RTP库，它完全遵循RFC 3550（RFC 1889已过时）设计，是一个用C++语言实现的RTP库。
2.3 RTP协议层次
RTP用来提供实时传输，因而可以看成是传输层的一个子层。
下图给出了流媒体应用中的一个典型的协议体系结构。
从图中可以看出，RTP被划分在传输层，它建立在UDP上。同UDP协议一样，为了实现其实时传输功能，RTP也有固定的封装形式。RTP用来为端到端的实时传输提供时间信息和流同步，由RTCP来保证其服务质量。
不少人把RTP归为应用层的一部分，这是从应用开发者的角度来说的。操作系统中的TCP/IP等协议栈所提供的是我们最常用的服务，而RTP部分的封闭还是要靠开发者自己来实现。因此从开发的角度来说，RTP的实现和应用层协议的实现没什么不同，所以可将RTP看成应用层协议。在发送RTP数据时，需先将数据封装成RTP包，而在接收到RTP数据包，需要将数据从RTP包中提取出来。
2.4 常见RTP的术语简介
RTP负载（RTP payload）：通过RTP传输的数据，如:音频样本或压缩好的视频数据。
RTP包（RTP packet）：封装后的数据包，其组成部分有：一个固定RTP报头，一个可能为空的作用源（contributing sources）列表，以及负载数据。
RTCP包（RTCP packet）：一种控制包，其组成部分有：一个类似RTP包的固定报头，后跟一个结构化的部分，该部分具体元素依不同RTCP包的类型而定。
端口（Port）：“传输协议用来在同一主机中区分不同目的地的一种抽象。TCP/IP协议使用正整数来标识不同端口。”[12] OSI传输层使用的传输选择器（TSEL,the transport selectors）等同于这里的端口。RTP需依靠底层协议提供的多种机制，如“端口”用以传输多路复用会话中的RTP或RTCP包。
传输地址(Transport address)：是网络地址与端口的结合，用来标识一个传输层次的终端，例如一个IP地址与一个UDP端口。包是从源传输地址发送到目的传输地址。
RTP媒体类型（RTP media type）：一个RTP媒体类型是一个单独RTP会话所载有的负载类型的集合。RTP配置文件把RTP媒体类型指派给RTP负载类型。
多媒体会话（Multimedia session）：在一个参与者公共组中，并发的RTP会话的集合。例如，一个视频会议（为多媒体会话）可能包含一个音频RTP会话和一个视频RTP会话。
RTP会话（RTP session）：一群参与者通过RTP进行通信时所产生的关联。一个参与者可能同时参与多个RTP会话。在一个多媒体会话中，除非编码方式把多种媒体多路复用到一个单一数据流中，否则每种媒体都将使用各自的RTCP包，通过单独的RTP会话来传送。通过使用不同的目的传输地址对（一个网络地址加上一对分别用于RTP和RTCP的端口，构成了一个传输地址对）来接收不同的会话，参与者能把多个RTP会话区隔开来。单个RTP会话中的所有参与者，可能共享一个公用目的传输地址对，比如IP多播的情况；也可能各自使用不同的目的传输地址对，比如个体单播网络地址加上一个端口对。对于单播的情况，参与者可能使用相同端口对来收听其他所有参与者，也可能对来其他每个参与者使用不同的端口对来收听。
RTP会话间相互区别的特征，在于每个RTP会话都维护一个用于SSRC标识符的独立完整的空间。RTP会话所包含的参与者组，由能接收SSRC标识符的参与者组成，这些SSRC标识符由RTP（同步源或作用源）或RTCP中的任意参与者传递。例如，考虑下述情况，用单播UDP实现的三方会议，每方都用不同的端口对来收听其他两方。如果收到一方的数据，就只把RTCP反馈发送给那一方，则会议就相当于由三个单独的点到点RTP会话构成；如果收到一方的数据，却把RTCP反馈发送另两方，则会议就是由一个多方（multi-party)RTP会话构成。后者模拟了三方间进行IP多播通信时的行为。
RTP框架允许上述规定发生变化，但一个特定的控制协议或者应用程序在设计时常常对变化作出约束。
同步源(SSRC，Synchronization source)：RTP包流的源，用RTP报头中32位数值的SSRC标识符进行标识，使其不依赖于网络地址。一个同步源的所有包构成了相同计时和序列号空间的一部分，这样接收方就可以把一个同步源的包放在一起，来进行重放。举些同步源的例子，像来自同一信号源的包流的发送方，如麦克风、摄影机、RTP混频器（见下文）就是同步源。一个同步源可能随着时间变化而改变其数据格式，如音频编码。SSRC标识符是一个随机选取的值，它在特定的RTP会话中是全局唯一（globally unique）的（见章节8）。参与者并不需要在一个多媒体会议的所有RTP会话中，使用相同的SSRC标识符；SSRC标识符的绑定通过RTCP（见章节6.5.1）。如果参与者在一个RTP会话中生成了多个流，例如来自多个摄影机，则每个摄影机都必须标识成单独的同步源。
作用源（CSRC，Contributingsource )：若一个RTP包流的源，对由RTP混频器生成的组合流起了作用，则它就是一个作用源。对特定包的生成起作用的源，其SSRC标识符组成的列表，被混频器插入到包的RTP报头中。这个列表叫做CSRC表。相关应用的例子如，在音频会议中，混频器向所有的说话人（talker)指出，谁的话语（speech)将被组合到即将发出的包中，即便所有的包都包含在同一个（混频器的）SSRC标识符中，也可让听者（接收者）可以清楚谁是当前说话人。
参考:
1. http://blog.csdn.net/ww506772362/article/details/47998943
2.RTSP协议分析与标准RTSP服务端与客户端交互流程 http://blog.csdn.net/beilingshan/article/details/72905571
3. rtsp和sdp协议简介 http://blog.csdn.net/lgm252008/article/details/6169579
4. RTSP学习之RTP(实时传输协议)简介【整理】 http://blog.csdn.net/zqj6893/article/details/14455457
5. 实时流媒体编程简介(RTP,RTCP,RTSP) http://blog.csdn.net/bupt_arccosxy/article/details/17395303
