網(wǎng)絡(luò)流媒體協(xié)議之——RTSP協(xié)議
RTSP(Real-Time Stream Protocol)協(xié)議是一個基于文本的多媒體播放控制協(xié)議,屬于應(yīng)用層。RTSP以客戶端方式工作,對流媒體提供播放、暫停、后退、前進(jìn)等操作。該標(biāo)準(zhǔn)由IETF指定,對應(yīng)的協(xié)議是RFC2326。
RTSP作為一個應(yīng)用層協(xié)議,提供了一個可供擴(kuò)展的框架,使得流媒體的受控和點播變得可能,它主要用來控制具有實時特性的數(shù)據(jù)的發(fā)送,但其本身并不用于傳送流媒體數(shù)據(jù),而必須依賴下層傳輸協(xié)議(如RTP/RTCP)所提供的服務(wù)來完成流媒體數(shù)據(jù)的傳送。RTSP負(fù)責(zé)定義具體的控制信息、操作方法、狀態(tài)碼,以及描述與RTP之間的交互操作。RTSP媒體服務(wù)協(xié)議框架如下:
客戶端要播放RTSP媒體流,就需要知道媒體源的URL,RTSP的URL格式一般如下:
- rtsp://host[:port]/[abs_path]/content_name
- host:有效的域名或IP地址;
- port:端口號,缺省為554,若為缺省可不填寫,否則必須寫明。
例如,一個完整的RTSP URL可寫為:
- rtsp://192.168.1.67:554/test
又如目前市面上常用的海康網(wǎng)絡(luò)攝像頭的RTSP地址格式為:
- rtsp://[username]:[password]@[ip]:[port]/[codec]/[channel]/[subtype]/av_stream
示例:
- rtsp://admin:12345@192.168.1.67:554/h264/ch1/main/av_stream
- rtsp://admin:12345@192.168.1.67/mpeg4/ch1/sub/av_stream
RTSP報文
對RTSP協(xié)議的使用有了一個大概的了解之后,我們來看一下RTSP報文結(jié)構(gòu)。
RTSP是一種基于文本的協(xié)議,用CRLF(回車換行)作為每一行的結(jié)束符,其好處是,在使用過程中可以方便地增加自定義參數(shù),也方便抓包分析。從消息傳送方向上來分,RTSP的報文有兩類:請求報文和響應(yīng)報文。請求報文是指從客戶端向服務(wù)器發(fā)送的請求(也有少量從服務(wù)器向客戶端發(fā)送的請求),響應(yīng)報文是指從服務(wù)器到客戶端的回應(yīng)。
RTSP請求報文的常用方法與作用:
一次基本的RTSP交互過程如下,C表示客戶端,S表示服務(wù)端。
首先客戶端連接到流媒體服務(wù)器并發(fā)送一個RTSP描述請求(DESCRIBE request),服務(wù)器通過一個SDP(Session DescriptionProtocol)描述來進(jìn)行反饋(DESCRIBEresponse),反饋信息包括流數(shù)量、媒體類型等信息??蛻舳朔治鲈揝DP描述,并為會話中的每一個流發(fā)送一個RTSP連接建立請求(SETUPrequest),該命令會告訴服務(wù)器用于接收媒體數(shù)據(jù)的端口,服務(wù)器響應(yīng)該請求(SETUP response)并建立連接之后,就開始傳送媒體流(RTP包)到客戶端。在播放過程中客戶端還可以向服務(wù)器發(fā)送請求來控制快進(jìn)、快退和暫停等。最后,客戶端可發(fā)送一個終止請求(TEARDOWN request)來結(jié)束流媒體會話。
下面我們通過具體的消息實例來進(jìn)一步了解一下RTSP的工作過程:
(1) OPTIONS
OPTIONS請求是客戶端向服務(wù)器詢問可用的方法,請求和回復(fù)實例如下:
- C->S: OPTIONS rtsp://example.com/media.mp4 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
(2) DESCRIBE
客戶端向服務(wù)器請求媒體資源描述,服務(wù)器端通過SDP(Session Description Protocol)格式回應(yīng)客戶端的請求。資源描述中會列出所請求媒體的媒體流及其相關(guān)信息,典型情況下,音頻和視頻分別作為一個媒體流傳輸。實例如下:
- C->S: DESCRIBE rtsp://example.com/media.mp4 RTSP/1.0
- CSeq: 2
- S->C: RTSP/1.0 200 OK
- CSeq: 2
- Content-Base: rtsp://example.com/media.mp4
- Content-Type: application/sdp
- Content-Length: 460
- m=video 0 RTP/AVP 96
- a=control:streamid=0
- a=range:npt=0-7.741000
- a=length:npt=7.741000
- a=rtpmap:96 MP4V-ES/5544
- a=mimetype:string;"video/MP4V-ES"
- a=AvgBitRate:integer;304018
- a=StreamName:string;"hinted video track"
- m=audio 0 RTP/AVP 97
- a=control:streamid=1
- a=range:npt=0-7.712000
- a=length:npt=7.712000
- a=rtpmap:97 mpeg4-generic/32000/2
- a=mimetype:string;"audio/mpeg4-generic"
- a=AvgBitRate:integer;65790
- a=StreamName:string;"hinted audio track"
(3) SETUP
SETUP請求確定了具體的媒體流如何傳輸,該請求必須在PLAY請求之前發(fā)送。SETUP請求包含媒體流的URL和客戶端用于接收RTP數(shù)據(jù)(audio or video)的端口以及接收RTCP數(shù)據(jù)(meta information)的端口。服務(wù)器端的回復(fù)通常包含客戶端請求參數(shù)的確認(rèn),并會補(bǔ)充缺失的部分,比如服務(wù)器選擇的發(fā)送端口。每一個媒體流在發(fā)送PLAY請求之前,都要首先通過SETUP請求來進(jìn)行相應(yīng)的配置。
- C->S: SETUP rtsp://example.com/media.mp4/streamid=0 RTSP/1.0
- CSeq: 3
- Transport: RTP/AVP;unicast;client_port=8000-8001
- S->C: RTSP/1.0 200 OK
- CSeq: 3
- Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001;ssrc=1234ABCD
- Session: 12345678
(4) PLAY
客戶端通過PLAY請求來播放一個或全部媒體流,PLAY請求可以發(fā)送一次或多次,發(fā)送一次時,URL為包含所有媒體流的地址,發(fā)送多次時,每一次請求攜帶的URL只包含一個相應(yīng)的媒體流。PLAY請求中可指定播放的range,若未指定,則從媒體流的開始播放到結(jié)束,如果媒體流在播放過程中被暫停,則可在暫停處重新啟動流的播放。
- C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0
- CSeq: 4
- Range: npt=5-20
- Session: 12345678
- S->C: RTSP/1.0 200 OK
- CSeq: 4
- Session: 12345678
- RTP-Info: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012
(5) PAUSE
PAUSE請求會暫停一個或所有媒體流,后續(xù)可通過PLAY請求恢復(fù)播放。PAUSE請求中攜帶所請求媒體流的URL,若參數(shù)range存在,則指明在何處暫停,若該參數(shù)不存在,則暫停立即生效,且暫停時長不確定。
- C->S: PAUSE rtsp://example.com/media.mp4 RTSP/1.0
- CSeq: 5
- Session: 12345678
- S->C: RTSP/1.0 200 OK
- CSeq: 5
- Session: 12345678
(6) TEARDOWN
結(jié)束會話請求,該請求會停止所有媒體流,并釋放服務(wù)器上的相關(guān)會話數(shù)據(jù)。
- C->S: TEARDOWN rtsp://example.com/media.mp4 RTSP/1.0
- CSeq: 8
- Session: 12345678
- S->C: RTSP/1.0 200 OK
- CSeq: 8
(7) GET_PARAMETER
檢索指定URI數(shù)據(jù)中的參數(shù)值。不攜帶消息體的GET_PARAMETER可用來測試服務(wù)器端或客戶端是否可通(類似ping的功能)。
- S->C: GET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0
- CSeq: 9
- Content-Type: text/parameters
- Session: 12345678
- Content-Length: 15
- packets_received
- jitter
- C->S: RTSP/1.0 200 OK
- CSeq: 9
- Content-Length: 46
- Content-Type: text/parameters
- packets_received: 10
- jitter: 0.3838
(8) SET_PARAMETER
用于設(shè)置指定媒體流的參數(shù)。
- C->S: SET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0
- CSeq: 10
- Content-length: 20
- Content-type: text/parameters
- barparam: barstuff
- S->C: RTSP/1.0 451 Invalid Parameter
- CSeq: 10
- Content-length: 10
- Content-type: text/parameters
- barparam
(9) REDIRECT
重定向請求,用于服務(wù)器通知客戶端新的服務(wù)地址,客戶端需要向這個新地址重新發(fā)起請求。重定向請求中可能包含Range參數(shù),指明重定向生效的時間??蛻舳巳粜柘蛐路?wù)地址發(fā)起請求,必須先teardown當(dāng)前會話,再向指定的新主機(jī)setup一個新的會話。
- S->C: REDIRECT rtsp://example.com/media.mp4 RTSP/1.0
- CSeq: 11
- Location: rtsp://bigserver.com:8001
- Range: clock=19960213T143205
(10) ANNOUNCE
ANNOUNCE請求有兩個用途:(1)C->S:客戶端向服務(wù)器端發(fā)布URL指定的媒體信息描述;(2) S->C:實時更新對話描述。若媒體表示中新增了一個媒體流,例如在直播過程中,則整個媒體表示的description都要被重新發(fā)送,而不是只發(fā)送新增部分。
- C->S: ANNOUNCE rtsp://example.com/media.mp4 RTSP/1.0
- CSeq: 7
- Date: 23 Jan 1997 15:35:06 GMT
- Session: 12345678
- Content-Type: application/sdp
- Content-Length: 332
- v=0
- o=mhandley 2890844526 2890845468 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
- S->C: RTSP/1.0 200 OK
- CSeq: 7
(11) RECORD
請求錄制指定范圍的媒體數(shù)據(jù),請求中可指定錄制的起止時間戳;若未指定時間范圍,則使用presentation description中的開始和結(jié)束時間,這種情況下,如果會話已開始,則立即啟動錄制操作。
- C->S: RECORD rtsp://example.com/media.mp4 RTSP/1.0
- CSeq: 6
- Session: 12345678
- S->C: RTSP/1.0 200 OK
- CSeq: 6
- Session: 12345678
以上就是RTSP中常用的命令及其實例介紹。最后,來看一段實際使用的RTSP命令交互過程,該過程是通過PC對??禂z像頭視頻流的拉取和播放,并通過Wireshark抓取客戶端的數(shù)據(jù)得到的:
- OPTIONS rtsp://10.3.8.202:554 RTSP/1.0
- CSeq: 2
- User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22)
- RTSP/1.0 200 OK
- CSeq: 2
- Public: OPTIONS, DESCRIBE, PLAY, PAUSE, SETUP, TEARDOWN, SET_PARAMETER, GET_PARAMETER
- Date: Mon, Jan 29 2018 16:56:47 GMT
- DESCRIBE rtsp://10.3.8.202:554 RTSP/1.0
- CSeq: 3
- User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22)
- Accept: application/sdp
- RTSP/1.0 401 Unauthorized
- CSeq: 3
- WWW-Authenticate: Digest realm="IP Camera(10789)", nonce="6b9a455aec675b8db81a9ceb802e4eb8", stale="FALSE"
- Date: Mon, Jan 29 2018 16:56:47 GMT
- DESCRIBE rtsp://10.3.8.202:554 RTSP/1.0
- CSeq: 4
- Authorization: Digest username="admin", realm="IP Camera(10789)", nonce="6b9a455aec675b8db81a9ceb802e4eb8", uri="rtsp://10.3.8.202:554", response="3fc4b15d7a923fc36f32897e3cee69aa"
- User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22)
- Accept: application/sdp
- RTSP/1.0 200 OK
- CSeq: 4
- Content-Type: application/sdp
- Content-Base: rtsp://10.3.8.202:554/
- Content-Length: 551
- v=0
- o=- 1517245007527432 1517245007527432 IN IP4 10.3.8.202
- s=Media Presentation
- e=NONE
- b=AS:5050
- t=0 0
- a=control:rtsp://10.3.8.202:554/
- m=video 0 RTP/AVP 96
- c=IN IP4 0.0.0.0
- b=AS:5000
- a=recvonly
- a=x-dimensions:2048,1536
- a=control:rtsp://10.3.8.202:554/trackID=1
- a=rtpmap:96 H264/90000
- a=fmtp:96 profile-level-id=420029; packetization-mode=1; sprop-parameter-sets=Z00AMp2oCAAwabgICAoAAAMAAgAAAwBlCA==,aO48gA==
- a=Media_header:MEDIAINFO=494D4B48010200000400000100000000000000000000000000000000000000000000000000000000;
- a=appversion:1.0
- SETUP rtsp://10.3.8.202:554/trackID=1 RTSP/1.0
- CSeq: 5
- Authorization: Digest username="admin", realm="IP Camera(10789)", nonce="6b9a455aec675b8db81a9ceb802e4eb8", uri="rtsp://10.3.8.202:554/", response="ddfbf3e268ae954979407369a104a620"
- User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22)
- Transport: RTP/AVP;unicast;client_port=57844-57845
- RTSP/1.0 200 OK
- CSeq: 5
- Session: 1273222592;timeout=60
- Transport: RTP/AVP;unicast;client_port=57844-57845;server_port=8218-8219;ssrc=5181c73a;mode="play"
- Date: Mon, Jan 29 2018 16:56:47 GMT
- PLAY rtsp://10.3.8.202:554/ RTSP/1.0
- CSeq: 6
- Authorization: Digest username="admin", realm="IP Camera(10789)", nonce="6b9a455aec675b8db81a9ceb802e4eb8", uri="rtsp://10.3.8.202:554/", response="b5abf0b230de4b49d6c6d42569f88e91"
- User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22)
- Session: 1273222592
- Range: npt=0.000-
- RTSP/1.0 200 OK
- CSeq: 6
- Session: 1273222592
- RTP-Info: url=rtsp://10.3.8.202:554/trackID=1;seq=65373;rtptime=3566398668
- Date: Mon, Jan 29 2018 16:56:47 GMT
- GET_PARAMETER rtsp://10.3.8.202:554/ RTSP/1.0
- CSeq: 7
- Authorization: Digest username="admin", realm="IP Camera(10789)", nonce="6b9a455aec675b8db81a9ceb802e4eb8", uri="rtsp://10.3.8.202:554/", response="bb2309dcd083b25991c13e165673687b"
- User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22)
- Session: 1273222592
- RTSP/1.0 200 OK
- CSeq: 7
- Date: Mon, Jan 29 2018 16:56:47 GMT
- TEARDOWN rtsp://10.3.8.202:554/ RTSP/1.0
- CSeq: 8
- Authorization: Digest username="admin", realm="IP Camera(10789)", nonce="6b9a455aec675b8db81a9ceb802e4eb8", uri="rtsp://10.3.8.202:554/", response="e08a15c27d3daac14fd4b4bcab424a5e"
- User-Agent: LibVLC/2.2.8 (LIVE555 Streaming Media v2016.02.22)
- Session: 1273222592
- RTSP/1.0 200 OK
- CSeq: 8
- Session: 1273222592
- Date: Mon, Jan 29 2018 16:57:03 GMT