RTSP（实时流协议）
RTSP中使用会话概念代替连接，由于它本身不与传输层绑定，因此RTSP会话在传输层支持TCP与UDP协议发送请求。RTSP客户机和服务器都可以发出请求，本身并不携带传输的媒体数据，而是控制RTP协议进行媒体数据传输。由于RTSP控制通过单独协议发送流，与控制通道无关，因此RTSP会话状态标记了服务器流资源的分配情况，如果对数据进行提取数据，需要同时进行流媒体数据传输协议（RTP协议）的解析。
一、RTSP消息
RTSP基于文本协议，行以CRLF中断。消息类型包含请求（Request）和响应（Response）两种消息格式。两种消息都可能包括一个起始行，一个或多个标题域（headers），一个空行（用来表示标题域结束）和消息实体（message-body，可为空）
·1.1请求行格式
请求行格式为： 请求方法 SP 请求URI SP RTSP版本 CRLF
RTSP请求方法如下：
| method | direction | object | requirement |
| DESCRIBE | C->S | P,S | recommended |
| ANNOUNCE | C->S, S->C | P,S | optional |
| GET_PARAMETER | C->S, S->C | P,S | optional |
| OPTIONS | C->S, S->C | P,S | required(S->C:optional) |
| PAUSE | C->S | P,S | recommended |
| PLAY | C->S | P,S | required |
| RECORD | C->S | P,S | optional |
| REDIRECT | S->C | P,S | optional |
| SETUP | C->S | S | required |
| SET_PARAMETER | C->S,S->C | P,S | optional |
| TEARDOWN | C->S | P,S | required |
·1.2 状态行格式
状态行格式为： 协议版本 SP 状态码 SP 响应词语文本 CRLF
状态码格式为三位数字，形式如：1XX，2XX等
·1.3 消息实体
实体包含实体头和实体主体。所有HEAD请求方法的响应都不含实体主体。
·1.4 请求、响应、实体头域（标题域）
下表中列出了RTSP中使用到的头域，类型"g"表示通用头，类型"R"表示请求头，类型"r"表示回复头，类型"e"表示实体头。标记为"req."的头说明是必需的（required），标记为"opt."表示可选的（optional）。"entity"表示所有方法应当含有消息主体。
| 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 | 3 | 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. | entitiy |
| 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 |
下面对常见的部分头域进行描述：
·1.4.1 Accept头域（请求头、可选、含实体可用的头域）
Accept请求头域可被用于指定回复中可被接受的呈现描述内容类型
·1.4.2 Allow头域（响应头、可选、所有可用的头域）
Allow回复头域中列出了请求URI中指定资源支持的所有方法，其目的是告知接收者资源相关的有效方法。Allow头域必须出现在405(方法不支持)回复中。
示例：
Allow:SETUP,PLAY,RECORD,SET_PARAMETER
·1.4.3 Conference头域（请求、可选、SETUP）
会议请求头域在RTSP流和已建立会议之间建立了一条逻辑连接，对于同一RTSP会话，其会议id必须保持一致。
Conference = "Conference" ":" conference-ide.g. Conference:199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr当无法找到会议id时可回复“452（未找到会议）”。
·1.4.4 Content-Length（实体、必须、SET-PARAMETER/ANNOUNCE/实体）
该域包含了内容的长度（从紧跟最后一个头的两个CRLF开始计算）。与HTTP不同的是，该域必须存在于所有携带除头信息内容以外的消息中，如果该域不存在，默认值将赋为0。
·1.4.5 CSeq头域（通用、必须、所有）
CSeq域标识RTSP请求-回复对序号，该域所有请求和回复中必须有。对于每一个包含特定序号的RTSP请求而言，一定有一个拥有相同序号的对应回复。重传的请求必须使用和原始序号一致的值。
·1.4.6 Range头域（响应、可选、PLAY/PAUSE/RECORD）
请求和回复头域中指定一个时间范围，其单位有几种。RTSP中常用为smpte、npt和clock范围单元。在RTSP中，byte ranges没有意义且不能被使用。头中可能还包含一个UTC格式的时间参数，标明该操作何时生效。支持Range头的服务器必须也支持NPT范围格式，应该支持SMPTE范围格式。Range回复头表示实际播放和录制的时间。如果Range头是以不能理解的格式给出的，那么接收者应回复"501 未实现"错误。
Range是半闭合区间，包含低点，而不包含高点。换言之，a-b表示从a点开始，在b点前结束。只有音视频的起始点才是有关联的，比如每隔40ms产生一个视频帧，10.0-10.1的范围说明一个视频帧从10.0开始，最后一个视频帧时间为10.08而不是10.1。
Range = "Range" ":" 1\#range-specifier [":" "time" "=" utc-time ]ranges-specifier = npt-range | utc-range | smpte-rangee.g. Range: clock=19960213T143205Z-;time=19970123T143720ZRange概念类似于HTTP/1.1中byte-range头的概念，它允许客户端从媒体对象中选择片段，然后正常播放出来。播放的起始点可以是未来的任一位置，尽管有些服务器会拒绝长时间保持资源。
·1.4.7 RTP-Info头域（响应、必须、PLAY）
该域用于在PLAY回复中设置RTP相关的参数。
- url:
指明之后RTP参数所针对的流URL - seq:
指明流中的第一个分组序号 - rtptime
指明基于Range回复头中的RTP时间戳
语法： RTP-Info = "RTP-Info" ":" 1#stream-url 1*parameter stream-url = "url" "=" url parameter = ";" "seq" "=" 1*DIGIT | ";" "rtptime" "=" 1*DIGITe.g. RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102, url=rtsp://foo.com/bar.avi/streamid=1;seq=30211·1.4.8 Session头域（请求/响应、必须、除SETUP/OPTION的所有）
Session在请求回复头中标识RTSP会话中的媒体流，该流在服务器SETUP回复中启动，在TEARDOWN呈现URL时结尾。会话标识符由媒体服务器选择。
Session = "Session" ":" session-id [";" "timeout" "=" delta-seconds]
timeout参数仅允许在回复头中使用，服务器使用它来告知客户端其多久不活动（发送RTSP命令）后会话将会被关闭。timeout以秒为单位，默认值为60s（1分钟）。一个会话标识符可跨传输会话或连接使用，操作多个RTSP URL的控制消息可能通过同一个RTSP会话进行发送。因此，客户端使用同一会话控制同一呈现中来自同一服务器的多个流也是有可能的。此外，同一客户端中对于相同URL的不同的用户会话必须使用不同的会话标识符。会话标识符用于区分来自同一客户端对于相同URL的不同传输请求。如会话标识符无效，则返回“454（未找到会话）”错误。·1.4.9 Transport头域（请求/响应、必须、SETUP）
Transport头标明要使用何种传输协议，并为流配置其参数如目标地址、压缩、多播TTL（time-to-live）以及目标端口。它设置那些表示描述未能确定的值。
Transport之间以逗号分隔，依次列出。每个transport可添加参数，以分号隔开。Transport还可能用于修改具体transport参数，服务器可以拒绝修改已存在流上的参数。
服务器可在回复中的Transport头里标明实际使用的参数值。
Transport请求头域中可能包含一系列客户端支持的传输选项，这种情况下，服务器必须返回实际选择的某一选项。
transport/profile/lower-tranpsort"lower-tranport"的默认参数值与profile密切相关。对于RTP/AVP，默认为UDP。
·通用参数
unicast | multicast
互斥选项，要么单播要么多播，默认值为多播。同时支持多播和单播的客户端必须在参数中分别列出完整传输规格（transport-spec）以说明能力范围
destination
流发送的目标地址，客户端可在destination参数中指定多播地址。
source
如果流的源地址与可传输的RTSP端点地址不同，source字段将被指定。
该信息还可从SDP中获取。该信息的权威source应是SETUP回复中出现过的。
layers
该流可使用的多播层数量，所有层将发送给以目标地址开头的连续地址
mode
mode参数用于标示当前会话支持的所有方法，有效值为PLAY和RECORD。如不提供，则默认为PLAY
append
如果mode参数包含了RECORD，紧跟的参数标示媒体数据应当追加到已存在的资源上而不是覆盖。如请求中追加的参数服务器并不支持，它必须拒绝该请求而不是使用URI覆盖资源标识符。如mode未包含RECORD，则追加参数会被直接忽略。
interleaved
交错参数表示在控制流使用的任何协议中交错传输媒体流和控制流。interleaved提供了语句中将要使用到的channel序号。该参数可能被指派一个范围，如interleaved=4-5 以便媒体流选择传输时做决定。
这使得RTP/RTCP可使用与UDP一致的方法处理，如RTP一个channel，其他channel则给RTCP使用。
- RTP 的特殊参数
port
port参数为多播会话提供RTP/RTCP端口对，以范围形式给出，如 port=3456-3457
client_port
该参数为被选择用于接收媒体数据和控制信息的客户端提供了单播RTP/RTCP端口对，以范围形式给出，如 client_port=3456-3457
server_port
参数为被选择用于接收媒体数据和控制信息的服务器提供了单播RTP/RTCP端口对，以范围形式给出，如 server_port=3456-3457
ssrc
ssrc参数标明了RTP SSRC值可能会被媒体服务器使用。该参数仅对单播传输有效。它标示与媒体流相联系的同步源。
Transport = "Transport" ":" 1\#transport-spectransport-spec = transport-protocol/profile[/lower-transport] *parametertransport-protocol = "RTP"profile = "AVP"lower-transport = "TCP" | "UDP"parameter = ( "unicast" | "multicast" ) | ";" "destination" [ "=" address ] | ";" "interleaved" "=" channel [ "-" channel ] | ";" "append" | ";" "ttl" "=" ttl | ";" "layers" "=" 1*DIGIT | ";" "port" "=" port [ "-" port ] | ";" "client_port" "=" port [ "-" port ] | ";" "server_port" "=" port [ "-" port ] | ";" "ssrc" "=" ssrc | ";" "mode" = <"> 1\#mode <">ttl = 1*3(DIGIT)port = 1*5(DIGIT)ssrc = 8*8(HEX)channel = 1*3(DIGIT)address = hostmode = <"> *Method <"> | Method示例： Transport: RTP/AVP;multicast;ttl=127;mode="PLAY" RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"二、RTSP方法定义
·2.1 OPTION方法
OPTION方法可能在任何时候发出，但该方法不影响服务器状态，客户端发出请求后，服务器返回客户端支持的方法，示例如下：
C->S: OPTIONS * RTSP/1.0
CSeq: 1
Require: implicit-play
Proxy-Require: gzipped-messages
S->C: RTSP/1.0 200 OK
CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
其中CSeq为RTSP的包序号，同一个会话中，每次后一个RTSP包为前一个包的CSeq +1，当包未被确认而重传时，要携带初始序列号。
·2.2 DESCRIBE方法
DESCRIBE方法可以结合Accept首部域使用。客户端发出请求，携带其理解的资源描述格式，服务器针对请求发出响应，返回服务器资源的所有媒体初始化信息。一个DESCRIBE示例如下：
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 1
Accept: application/sdp, application/rtsl, application/mheg
在请求中，Accept首部域支持sdp返回格式，因此服务器返回了一个sdp响应包，格式如下：
S->C: RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:25:06 GMT
Content-Type: applicaiton/sdp
Content-Length: 376
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu(Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
m=whiteboard 32416 UDP WB
a=orient:portrait
·2.3 SETUP方法
客户端发出SETUP请求提示服务器端开始建立会话，在服务器响应报文中给出会话的标识符和会话信息。在Transport首部域中标出了客户端数据传输时可以接受的传输参数类型。
示例：
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589
Transport内容为RTP/AVP表示UDP方式传输，为RTP/AVP/TCP时为TCP方式传输，其中unicast为单播传输（RTSP还支持多播和组播）。当传输方式为UDP时会在后面指定传输端口client_port，其中偶数为RTP奇数为RTCP端口。当传输方式为TCP时，第三部分为inter-leaved=0-1的形式，即0代表RTP，1代表RTCP。
在服务器的SETUP响应包中（如下图），返回一个Session，标识当前会话序列号。
S->C: RTSP/1.0 200 OK
CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344
Tranport: RTP/AVP;unicast;client_port=4588-4589;server_port=6256-6257
·2.4 PLAY方法
在捕包数据分析时，SETUP和PLAY中间有时会有RTP或RTCP包，通常用来穿墙，这些包数据无意义。
客户端发送PLAY方法必须在SETUP请求后，请求将正常播放时间（npt）到指定范围起始处，并传输数据流直到播放范围结束。后一个PLAY请求要等到前一个PLAY请求完成后才能被执行。即对于下面例子，无论两个PLAY请求到达服务器时有多接近，服务器依然会先播放10s-15s内容，然后20s-25s，并最终从30s到结束。
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 835
Session: 12345678
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq:836
Session: 12345678
Range: npt=20-25
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 837
Session: 12345678
Range: npt=30-
没有Range头的PLAY请求是合法的，它会从头开始播放流。而如果流已处于暂停状态，则从暂停点开始播放。如果一个流正处于播放状态，那么新的PLAY请求不会有任何作用。
·2.5 PAUSE方法
PAUSE方法的URL中指定具体的媒体流（音频或视频），停止某一个如音频，则暂停音频，视频无声播放；也可以停止一组媒体流。如果URL指定的是一组流，则呈现或组中所有活动流将会被暂停。当恢复播放或录制时，所有轨道的流必须进行同步。此过程中，所有服务器资源均会保留，除非SETUP时，头中有参数指定延时，那么服务器可能在触发延时后关闭会话并释放资源。
不同于播放流中Range值是一个时间范围，暂停方法对应的Range一个时刻，表示一个暂停点。暂停请求生效后，下一次PLAY请求如果超出播放范围则请求无效，恰好在暂停点开始则不会被播放，Range首部域缺失，则收到暂停消息后，媒体流立即中断，并将暂停点设置成正常播放时间。
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 834
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT
·2.6 TEARDOWN方法
TEARDOWN请求终止给定的URI媒体流传输并释放相关资源，如果URI关联的是一个呈现，那么RTSP会话标识符将不再有效。停止后，除非所有传输参数都通过绘画描述来定义，否则重新播放前必须发出SETUP请求。
示例：
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 892
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 892
·2.7 GET PARAMETER方法
GET PARAMETER 请求检索 URI 指定的表示或媒体流的参数值。答复和响应的内容留给了实现。不带实体主体的 GET PARAMETER 可用来测试客户端或服务器是否存活（ "Ping" ）。
·2.8 SET PARAMETER方法
此方法给 URI 指定的表示或媒体流设置参数值。
·2.9 RECORD方法
根据提供的时间戳记录媒体数据
·2.10 REDIRECT方法
REDIRECT方法可以使得客户端在会话中重新连接到另一服务器。新的服务器的URI在首部域 Location给出 ，Range中指出重定向生效的范围。
在发出重定向请求后，如果客户端要继续传输或接受媒体流，必须要先关闭当前会话（发送TEARDOWN请求），然后再向指定主机开启一个新会话（通过发送SETUP请求）。
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 732
Location: rtsp://bigserver.com:8001
Range: clock=19960213T143205Z-
·2.11 ANNOUNCE方法
ANNOUNCE 方法有两个用途：
当客户端向服务器发送时， ANNOUNCE 将通过请求 URL 识别的表示描述或者媒体对象提交给服务器；
当服务器相客户端发送时， ANNOUNCE 实时更新会话描述。
·2.12 嵌入式二进制数据Embedded (Interleaved) Binary Data
某些防火墙设计和环境会强制服务器交叉 RTSP 方法和媒体流数据。只有 RTSP 在 TCP 上运载时，交叉的二进制数据才能使用。媒体流数据，如 RTP 包，被封装成下列形式：每个RTP/RTCP包前都是长度为4字节的RTP interleaved frame 包。该包第一个字节固定为‘$’，第二个字节位为interleaved值，三四字节是接下来的RTP包或RTCP包的长度。
三、几种常见RTSP情况
简单的RTSP信息交互如下图所示，其中，这个过程只是标准的rtsp流程，实际需求中并不一定按照此过程。其中第三第四步为必需。
在服务器客户端约定可用方法时可以省略option请求（第一步）。如果有其他途径得到媒体初始化描述信息（比如http请求等等），则可以省略rtsp中的describe请求（第二步）。
其中蓝色字体是客户端请求，红色字体表示上一个请求相对应的服务器响应
·3.1 媒体点播（单播）
客户端C从服务器A(audio.example.com)和服务器V（video.example.com）请求一个影片。媒体描述存储在web服务器W上。
媒体描述中包括呈现及其所有流信息、支持的编码器、动态RTP负载类型、协议栈以及如语言、版权等内容信息。甚至有可能涉及影片的timeline。
本例中，客户端只希望接收影片的最后一部分。
即使音视频轨可能来自不同的服务器，甚至有不同的起始时间，客户端都能够通过标准RTP方法将两者同步，特别是RTCP发送报告总的时间刻度。
C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com
Accept: application/sdp
W->C: HTTP/1.0 200 OK
Content-Type: application/sdp
v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session
m=audio 0 RTP/AVP 0 a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31 a=control:rtsp://video.example.com/twister/video
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 1
Transport: RTP/AVP/UDP;unicast;client_port=3056-3057
A->C: RTSP/1.0 200 OK
CSeq: 1
Session: 12345678
Tranport:RTP/AVP/UDP;unicast;client_port=30563057;server_port=5000-5001
C->V: SETUP rtsp://video.example.com/twister/vidoe RTSP/1.0
CSeq: 1
Transport: RTP/AVP/UDP;unicast;client_port=3058-3059
V->C: RTSP/1.0 200 OK
CSeq: 1
Session: 23456789
Transport: RTP/AVP/UDP;unicast;client_port=30583059;server_port= 5002-5003
C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-
V->C: RTSP/1.0 200 OK
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-0:20:00
RTP-Info: url=rtsp://video.example.com/twister/video; seq=12312232;rtptime=78712811
C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 2
Session: 12345678
Range: smpte=0:10:00-
A->C: RTSP/1.0 200 OK
CSeq: 2
Session: 12345678
Range: smpte=0:10:00-0:20:00
RTP-Info: url=rtsp://audio.example.com/twister/audio.en; seq=876655;rtptime=1032181
C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0 CSeq: 3
Session: 12345678
A->C: RTSP/1.0 200 OK
CSeq: 3
C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 3
Session: 23456789
V->C: RTSP/1.0 200 OK
CSeq: 3
图示如下：
由于向两个服务器请求两个不同URL下的资源(可以采用http也可以通过)，因此必需建立两次会话。尽管发送的包的顺序有所交叉，但可以通过两个会话各自的id对会话加以区分。下面例子基于RTP/UDP的单播传输，因此不同会话中的端口号都在SETUP时可以获得。同时因为开启了两个会话，在释放资源时要分别向两个服务器发送TEARDOWN。
其中一个双向箭头表示一次客户端请求和服务器应答，两种颜色分别代表两个会话。
·3.2 容器文件串流
容器文件表示一个存储实体中含有同一终端呈现相关的多个连续媒体类型。可以通过一条简单的作用于聚合URL的控制消息来控制所有流。
下面给出了一个使用RTSP会话来控制多个流的例子，它还演示了聚合URL的使用。
客户端C从媒体服务器M上获取一个呈现，影片存放在一个容器文件中。客户端已获得一个指向容器文件的RTSP URL。
因为音频文件和视频文件分别传输，URL分别为 rtsp://foo/twister/audio和rtsp://foo/twister/video
首先通过DESCRIBE获取服务器资源描述格式
获取成功后开启会话。由于该音视频是一个聚合URL，因此尽管通过两次SETUP分别开启了音频和视频流，然而它们对应了一个相同的对话。即针对一个聚合URL，RTSP将会为聚合URL下的不同同步源分别发送SETUP请求，但只会形成一个会话。然而在后续发送PLAY和TEARDOWN时，只需要针对聚合URL发送请求即可。
·3.3 单一流容器文件
有些服务器可能将所有文件都视为容器，因此客户端应当使用会话描述中规则去请求URL，而不是假设会一直使用同一个URL。下面是一个期望multi-stream服务器提供single-stream服务的例子。
在请求资源响应时，返回的sdp包表明s=mu-law即支持Multi-stream。
SETUP命令中的URL有所不同，紧跟着的PLAY命令仍然使用聚合URL。这使得对多个流进行聚合控制的概念更加完整，而当流数目为第一个SETUP对应URL后streamid=0。
有的服务器支持SETUP直接加聚合URL，如下：
·3.4 使用多播的直播呈现
当媒体服务器选择多播地址和端口时，RTSP支持多播方式。此时在SETUP过程中，客户端的Transport将为Transport:RTP/AVP;multicast，而返回的服务器SETUP响应包中将会包含目的地址（通常为服务器地址），示例如下：
·3.5 在已存在的会话中播放媒体
一个会议参与者C希望媒体服务器M在现有会议中播放一个demo，C告知了媒体服务器M会议的网络地址和加密后的key，所以服务器没必要进行地址选择
同时注意SETUP中携带了会议信息
·3.6 录制
RTSP支持录制方法。因此下图示例为会议参与者客户端C请求服务器M去录制会议音视频部分，其中clock表示录制的时钟时间
·3.7 基于TCP的RTSP/RTP流媒体传输
在UDP 协议上的RTSP/RTP需要打开许多UDP端口，一个端口用于RTSP通信，n个端口用于RTP，n个端口用于RTCP。通常RTSP协议缺省端口554，UDP协议上，同一同步源的RTP端口与RTCP端口相邻，RTP端口通常为偶数，RTCP端口为奇数，且RTCP为RTP端口号+1。对于每一路流媒体，都需要一对UDP端口。
在TCP协议上的RTSP/RTP，RTSP/RTP的控制命令和数据都通过一个端口，即RTSP的端口（默认为554），进行交互。相较于UDP，TCP的优点在于可靠传输、节省端口、同时更容易穿透中间网络路由。
但是TCP协议上的RTSP/RTP采用二元交织（交错传输二进制）的方法传输数据，且可靠传输协议容易在实时媒体流中造成时延。
TCP与UDP上的RTSP/RTP协议的主要差异如下：
·3.7.1 rtsp指令交互差异
与UDP rtsp指令集相比，TCP指令集在setup指令上存在差异：
下面是一个TCP示例：
请求部分如下：
SETUP rtsp://192.168.100.123:554/mpeg4cif/track1 RTSP/1.0
CSeq: 4
User-Agent: LibVLC/2.2.4 (LIVE555 Streaming Media v2016.02.22)
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Transport头域中，UDP为RTP/AVP/UDP或RTP/AVP，而TCP为RTP/AVP/TCP。
同时TCP在Transport中没有像UDP一样指出RTP和RTCP端口号（因为数据和RTSP公用一个端口传输），同时多了一个Interleaved指出传输数据时使用的TCP信道。
使用偶数信道作为数据传输（rtp）信道，使用奇数信通道（rtcp）作为控制信道（数据信道 + 1）。
假如对聚合URL存在两次SETUP请求，可能的interleaved值分别对应0-1和3-4
响应部分如下：
RTSP/1.0 200 OK
CSeq: 4
Date: Mon, Mar 06 2017 02:56:22 GMT
Transport: RTP/AVP/TCP;unicast;destination=192.168.100.145;source=192.168.100.123;interleaved=0-1
Session: 425EC42F
·3.7.2 rtp数据接收差异
使用udp 接收数据时不需要对数据做rtp包解包处理，使用tcp接收数据时，由于rtp,rtcp,rtsp都在同一端口上，用户需要做tcp解包处理。
为了区分RTP通道和RTCP通道，在RTP层之上增加一层，即RTSP Interleaved Frame 层。
RTP数据将通过用来发送RTSP命令的TCP Socket进行发送。RTP数据将以如下格式进行封装：
| 标识符 | 信道 |数据长度 | 数据 |
其中：
RTP数据标识符，"$" （0x24）这个一般是固定为0x24
信道数字 1个字节，用来指示信道。可以用来区分音视频等多路流媒体的通道，其中偶数通道为流媒体内容，奇数通道为RTCP(即0x00 一般代表rtp数据， 0x01 一般代表rtsp数据)
数据长度 2个字节，用来指示插入数据长度（数据包的长度减去开始的4个字节，即len字段之后的数据长度）
数据 - 数据包，比如说RTP包，总长度与上面的数据长度相同
然而，由于RTSP是应用协议，没有办法控制TCP连接的超时。所以，在RTSP的SETUP阶段，新建一个会话（SESSION）用于标识已连接的流。
Session = "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ]
一旦会话（SESSION）被创建，接下来的每一个RTSP命令都必须加上session_id，否则服务端无法识别命令对应的流。另外，"timeout"的值是可选
数据包封装格式示例图如下：
WireShark捕包的RTP over RTSP(TCP)数据流如下：
其中Payload type 为97时表示音频，为96时是视频（RTP包的负载类型）
四、RTSP协议状态机
·4.1 客户端协议状态机
客户端会有如下状态：
- Init
SETUP已发出，等待回复 - Ready
已接收SETUP回复或播放中收到PAUSE回复 - Playing
已接收PLAY回复 - Recording
已接收RECORD回复
通常，客户端会在收到请求回复情况下改变状态。注意有些请求会在将来的某一时间或位置生效（如PAUSE），那么状态也会对应再发生改变。如果对象不需要显式SETUP(如多播组中可行的），状态从Ready开始。该情况下，只有两种有效状态，Ready和PLAYING。当请求中Range结尾点抵达后，客户端状态同样会从Playing/Recording切换至Ready。
“next state”栏表示收到成功回复（2xx）后将会切换至的目标状态。如果请求响应的是3xx的状态码，那么状态会切换至Init，而状态码4xx时不会做出任何改变。未列出的消息中，除了之前提到不会影响状态的消息，其他均不应该由该状态客户端发出。
*从服务器接收到REDIRECT等同于从服务器收到收到3xx重定向状态。 *
·4.2 服务器协议状态机
服务器有如下状态：
- Init
初始化状态，未收到有效SETUP请求 - Ready
完成上一次SETUP接收，已回复或在playing后回复；
完成上一次PAUSE接收，已回复 - Playing
完成上一次PLAY接收，已回复，数据已发送 - Recording
服务器正在录制媒体数据
通常来讲，服务器在接收请求后会改变状态。如果服务器处于单播模式的Playing或Recording状态时，如未收到健康信息（如定义好的从客户端以多少间隔发送的RTSP报告或RTSP命令，该间隔默认为1分钟），它可能回退到Init或退出RTSP会话。服务器可在会话回复头中修改延时值。如果服务器处于Ready状态，它可能会在指定间隔或超过一分钟内未收到RTSP请求后回退到Init。注意有些命令将在将来的某一时间或位置才生效，此时服务器会在合适时间转换状态。当请求中Range结尾点抵达后，服务器会从Playing或Recording状态切换为Ready状态。
发送REDIRECT消息后，将会立即生效，除非消息中带有Range头以指定生效时间。这种情况下，服务器状态也会在合适时间进行切换。
如果对象没有要求显式SETUP，那么状态从Ready开始，且只有两种有效状态：Ready和Playing。
“next state”栏表示收到成功回复（2xx）后将会切换至的目标状态。如果请求结果状态码为3xx，状态切换为Init。状态码为4xx的结果不会引起任何变化。
五、RTSP会话描述中SDP的使用
·5.1 SDP协议介绍
SDP 完全是一种会话描述格式 ― 它不属于传输协议 ― 它只使用不同的适当的传输协议，包括会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、MIME 扩展协议的电子邮件以及超文本传输协议（HTTP）。SDP协议是也是基于文本的协议，这样就能保证协议的可扩展性比较强，这样就使其具有广泛的应用范围。SDP 不支持会话内容或媒体
编码的协商，所以在流媒体中只用来描述媒体信息。媒体协商这一块要用RTSP来实现．
·5.2 SDP协议格式
SDP描述由许多文本行组成，文本行的格式为<类型>=<值>，<类型>是一个字母，<值>是结构化的文本串，其格式依<类型>而定。
＜type＞=<value>[CRLF]
常见的域包括会话描述、时间描述和媒体信息描述
其中各个域对应的类型标识和是否可选以及简单描述如下所示：
会话描述如下：
时间描述如下：
媒体描述如下：
具体协议格式及格式描述如下：
会话描述：
时间描述：
媒体描述：
对于上述描述，v,o,s,t,m为必需，其他项可选。如果SDP语法分析器不能识别某一类型（Type）,则整个描述丢失。如果“a=”的属性值不能被理解，则予以丢弃。
·5.3 SDP的两个属性
针对SDP的a和m属性有以下扩展：
其中在RTSP会话描述中：
"a=control:"属性用于转换控制URL，该属性同时用于会话和媒体描述。如用于单独媒体，它表示控制特定媒体流的URL，如果在会话级别有该关键字，则表示URL用于聚合操作。
如： a=control:rtsp://example.com/foo
如概述性只包含"*"，则URL被视为空的嵌入式URL，即继承了整个base URL。
在会话中是否支持URL聚合操作也在a=描述中有体现：
如：
v=0
o=- 2890844256 2890842807 IN IP4 204.34.34.32
s=I came from a web page
t=0 0
c=IN IP4 0.0.0.0
m=video 8002 RTP/AVP 31
a=control:rtsp://audio.com/movie.aud
m=audio 8004 RTP/AVP 3
a=control:rtsp://video.com/movie.vid
此种控制URL中的位置表示客户端向服务器audio.com和video.com分别建立独立的RTSP控制会话。因此不支持聚合操作
而：
v=0
o=- 2890844256 2890842807 IN IP4 204.34.34.32
s=I contain i=<more info>
t=0 0
c=IN IP4 0.0.0.0
a=control:rtsp://example.com/movie/
m=video 8002 RTP/AVP 31
a=control:trackID=1
m=audio 8004 RTP/AVP 3
a=control:trackID=2
上面例子中，客户端向服务器请求建立一个简单RTSP会话，并使用URL "rtsp://example.com/movie/trackID=1"和"rtsp://example.com/movie/trackID=2"来设置音视频流，而URL "rtsp://example.com/movie/"则控制整个影片。此种方式为支持聚合URL。
在用于RTSP的会话中：
“m=”域用于枚举媒体流，理想情况下所有指定流都会被合适同步处理。如果会话是单播，那么服务器提供给客户端的port值仅作为建议值，客户端仍然需要在SETUP请求中包含它，并有可能忽略该建议。如果服务器没有优先值，则应设置port值为0。
在SDP中，"c="域中包含了媒体流的目标地址。对于点播（单播）流和一些多播流而言，目标地址是通过客户端的SETUP请求确定的。除非媒体内容有一个固定的目标地址，此时"c="域将被设置为合适的空值。如对于“IP4”类型该空值为"0.0.0.0"。
RTP（实时应用程序传输协议）
RTP协议基于UDP，实时实现端对端数据传输服务，传输的数据如：交互式的音频和视频。那些服务包括有效载荷类型定义，序列号，时间戳和传输监测控制。RTP控制协议
RTCP，用于监控服务质量和传达关于在一个正在进行的会议中的参与者的信息。
RTP的使用场景为：简单多播音频会议、音频和视频会议、 混频器和转换器和分层编码。
在简单多播音频会议中，一个工作组采用IP多播进行语音通讯，工作组中心分配到一个多播的组地址和一对端口。一个端口用于音频数据，另一个端口用于控制（RTCP）数据包。该地址和端口信息发布给预定的参与者，利用RTP包头中计时信息和序列号来进行丢包排查和重排包操作，利用RTCP控制协议周期性多播一个附加用户名的接收报告来检验会议中是否有人员离开。
在音频和视频会议中通常需要同时使用音视频媒体，两者将基于不同RTP会话，即两种媒体中的RTP包和RTCP包的传输，是使用两个不同的UDP端口对和（或）多播地址。在RTP层次，音频和视频会话没有直接的耦合，下面这种情况除外：一个同时参加两个会话的参与者，在两个会话的RTCP包中，使用了相同的规范名，这样两个会话就发生关联（耦合）了。例如如果RTSP以TCP运载时，交叉二进制数据情况下，将产生音视频为相同规范名的情况。
混频器和转换器（RTP中继）。混频器可以实现将接受的音频报文重新同步，并将重建后的音频流混合成单一流，且将音频码翻译给一个低带宽，然后通过低速率链路形成低带宽报文流。RTP头包含了用于混频器识别混合报文中的源方法用来识别讲话者。转换器可以方便与会者不能直达的情况（如防火墙，在墙两侧设立两个转换器，从而方便报文通过）
分层编码常用来调节匹配接收方的能力（容量）以及适应网络拥塞
- RTP数据传输协议
- RTP固定头中的字段
RTP头格式如下：
其中，头部长为12字节，CSRC字段仅在混合器插入时才有。
V 2bit 版本号
P 1bit 填充位，为1时表示报文末端含有一个或多个填充字节，填充位长度不算在负载长度中，且填充部分的最后用来充当计数器
X 1bit 扩展， 标识是否含有扩展头（最多只能有一个扩展头）
CC 4bit CSRC数， RTP头中含有的CRSC的数量
M 1bit 标记，用来标记比特流中重要事件（如帧边界）
PT 7bit RTP负载格式，当接受者收到不能识别的PT格式时将忽略该RTP包
序列号 16bit 初值随机，每发送一个RTP，序列号加一。可以用来检测丢包和重传
时间戳 32bit 时间戳反映了RTP数据包中第一个字节的采样时间。
SSRC 32bit 同步源，即RTP报文的源。同一个同步源的报文有相同时序间隔和序列号间隔。全局随机值，有RTCP分配。一个会话中，如果参与者从不同视频源生成多个流，则每个必须表示为不同的SSRC。
如果RTP头部中X=1，则包含扩展头，格式如下，包含16bit长度域，指示扩展项中32比特字的个数，不包括4个字节扩展头。扩展项的前16比特用以识别标识符或参数。这16比特的格式由具体实现的上层协议定义。基本的RTP说明并不定义任何头扩展本身。
- RTCP协议
RTP控制协议(RTCP)向会议中所有成员周期性发送控制包。它使用与数据包相同的传输机制。底层协议必须提供数据包和控制包的复用，例如用不同的UDP端口。RTCP提供以下四个功能：
基本功能是提供数据传输质量的反馈。这是RTP作为一种传输协议的主要作用，它与其他协议的流量和拥塞控制相关。
RTCP为每个RTP源传输一个固定的识别符，称为规范名（CNAME）。由于当发生冲突或程序重启时SSRC可能改变，接收者要用CNAME来跟踪每个成员。接收者还要用CNAME来关联一系列相关RTP会话中来自同一个成员的多个数据流，例如同步语音和图像。
通过让每个成员向所有成员发送控制包，各个成员都可以独立地观察会议中所有成员的数目。此数目可以用来估计发包速率。
第四个可选的功能是传输最少的会议控制信息，指示会议中存在的成员信息和退出情况
2.1 RTCP包类型
RTCP包类型如下：
SR：发送者报告，描述作为活跃发送者成员的发送和接收统计数字；
RR：接收者报告，描述非活跃发送者成员的接收统计数字；
SDES：源描述项，其中包括规范名CNAME。
BYE：表明参与者将结束会话。
APP：应用描述功能。
每个RTCP包的开始部分是与RTP数据包相类似的固定部分，随后是一块结构化单元，它随负载类型不同长度发生变化，但是总以32比特终止。可以将多个RTCP包形成一个复合RTCP包，在底层协议(如UDP)中，通常都是将复合包作为一个包传输的。复合包中的每个RTCP单包可以单独处理，而无需考虑包复合的顺序。
每一个登录都应在表中创建一条记录，并以SSRC或CSRC进行索引。新的登录直到接收到含有SSRC的包或含有与此SSRC相联系的规范名的SDES包才视为有效）。当一个与SSRC标识符相对RTCP BYE包收到时，登录会被从表中删除。
当收到一个参与者的RTP或RTCP包时，若其SSRC不在成员列表中，将其SSRC加入列表；若此参与者被确认有效，就把列表中成员的值更新。对每个有效的RTP包中的CSRC执行相同的过程。如果收到一个RTCP BYE包，则检测成员列表。若SSRC存在；先移除之，并更新成员的值。如果在几个RTCP报告时间间隔内没有RTP或RTCP包收到，一个参与者可能标记另外一个站点静止，RTCP会自动删除它。
2.2 RTCP包格式
RTP接收者利用RTCP报告包提供接收质量反馈。根据接收者是否同时还是发送者，RTCP包采取两种不同的形式。发送者报告(SR)和接收者报告(RR)格式中唯一的不同，除包类型码之外，在于发送者报告包括20字节的发送者信息。 SR包和RR包都包括零到多个接收报告块。
2.2.1 SR格式：
发送者报告包：
版本(V)：2比特 填充(P)：1比特
接收报告块计数(RC)：5比特 该包中所含接收报告块的数目。零值有效。
包类型(PT)：8比特 包含常数200，用以识别这个为SR包。
长度：16比特 该RTCP包的长度减1。
SSRC：32比特 SR包发送者的同步源标识符。
NTP时间戳：64比特 此报告发送时的时钟（wallclock）时刻
RTP时间戳：32比特 与以上的NTP时间标志对应同一时刻。与数据包中的RTP时间戳具有相同的单位和偏移量。
发送的报文数：32比特 从开始传输到此SR包产生时该发送者发送的RTP数据包总数。若发送者改变SSRC识别符，该计数器重设。
发送的字节文数：32比特 从开始传输到此SR包产生时该发送者在RTP数据包发送的字节总数(不包括头和填充)。若发送者改变SSRC识别符，该计数器重设。 SSRC_n(同步源标识符)：32比特 在此接收报告块中信息所属源的SSRC标识符。
2.2.2 RR格式：
接收者报告包(RR)与发送者报告包基本相同，除了包类型域包含常数201和没有发送者信息的5个字(NTP和RTP时间标志和发送者包和字节计数)。余下区域与SR包意义相同。若没有发送和接收据报告，在RTCP复合包头部加入空的RR包(RC=0)。
2.2.3 SDES 包
源描述（SDES）包由一个头及0个或多个块组成。每个块都由块中所标识的数据源的标识符及其后的各个描述构成。
2.2.4 BYE 包
BYE包表明一个或多个源将要离开。BYE包可能会有选择的包含8个字节的统计字段，其后跟上几个字节的文本表明离开的原因。
扫一扫
4858
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
