[互聯(lián)網(wǎng)]RTSP協(xié)議介紹ppt課件

1、RTSP協(xié)議介紹Page 2第第2 2章章 SDPSDP介紹介紹第第3 3章章 RTP/RTCPRTP/RTCP介紹介紹 實時流媒體協(xié)議：RTSP 一般作為媒體信道的遠(yuǎn)程控制使用,不參與媒體數(shù)據(jù)傳輸,也不做媒體的解析. 實時協(xié)議：RTP/RTCPRTP:按照RTP分組的方式傳輸媒體數(shù)據(jù)，協(xié)議規(guī)定了排序/丟包檢查/以及媒體重建信息。媒體特定信息說明，包括其重建、解釋有應(yīng)用文檔規(guī)定。 RTCP:作為質(zhì)量控制，成員控制等功能。 會話描繪協(xié)議：SDP在會話級別、媒體級別來描繪傳輸媒體的詳細(xì)信息，不參與傳輸 媒體凈荷應(yīng)用文檔 規(guī)定了特定的媒體的處理信息根本概念協(xié)議棧層次 一種控制媒體流的應(yīng)用層協(xié)議 RT

2、SP 本身不負(fù)責(zé)媒體流傳送,只負(fù)責(zé)客戶端與效勞端之間的控制CS 414 - Spring 2020SERVERCLIENTRTPRTPRTSPRTSPSession ControlAudiovideoCoderAudioVideoDecoder例如CS 414 - Spring 2020RTSP Presentation by H. Schulzrinne, 2001Streaming Media: RTSPPage 7協(xié)議的方法介紹Page 8協(xié)議的方法介紹CS 414 - Spring 2020RTSP Presentation by H. Schulzrinne, 2001RTSP 消息

3、流程Page 10 RTSP消息由懇求和響應(yīng)組成。 懇求消息=懇求頭+頭域+消息體 響應(yīng)消息=狀態(tài)頭+頭域+消息體 消息體和頭域之間用空行0d0a分隔 懇求/狀態(tài)頭以及每個頭域都占據(jù)一行，以0d0a完畢消息語法Page 11當(dāng)客戶端想進展非標(biāo)準(zhǔn)懇求，可以通過OPTIONS懇求，懇求獲得效勞器的才能。OPTIONS在任何時候都可以向效勞器懇求，而且不會改變效勞器的狀態(tài)。下面是一個OPTIONS懇求的例子，客戶端懇求效勞器的才能?？蛻舳藨┣螅篛PTIONS * RTSP/1.0CSeq:1Require:implicit-playProxy-Require:gzipped-messages效勞器響

4、應(yīng)：RTSP/1.0 200 OKServer: MDN_HWPSSCSeq: 0Session: 1729556035Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, ANNOUNCE, RECORD該效勞器是Huawei Technologies Co., Ltd. IPTV系統(tǒng)中的HMS流媒體效勞器。OPTIONPage 12DESCRIBE方法懇求得到URI對應(yīng)的對象或表示的描繪，客戶端可以使用Accept頭域聲明它可以承受的格式。效勞器返回被懇求資源的描繪，DESCRIBE和響應(yīng)構(gòu)成了RTSP的媒體初始化階段。下面例子說明DESCRIBE

5、的使用?？蛻舳藨┣笮谄髅枥L某個URI對應(yīng)的資源?？蛻舳藨┣螅篋ESCRIBE rtsp 1.0.7.93:18554/2/asdf/movies/hory_poter.mp4?accounttype=1&accountinfo=0 RTSP/1.0CSeq:1Require:implicit-play Accept:application/sdp, application/rtsl, application/mheg效勞器在成功響應(yīng)描繪懇求時，必須包含所有的媒體初始化信息。DESCRIBEPage 13懇求效勞器給流分配資源，啟動RTSP會話。SETUP懇求包含所有的傳輸初始化信息。

6、在Transport頭域指定了客戶端可以承受的數(shù)據(jù)傳輸參數(shù)，而效勞器的響應(yīng)會包含效勞器選擇的傳輸參數(shù)。如客戶端懇求：SETUP rtsp 192.168.1.100:554/powered_by_100.wmv/video RTSP/1.0CSeq:0Transport:RTP/AVP/TCP;unicast;interleaved=4-5;ssrc=9440ecec;mode=PLAYSupported:com.microsoft.wm.srvppair, com.microsoft.wm.sswitch, com.microsoft.wm.eosmsg, com.microsoft.wm.

7、fastcache, com.microsoft.wm.packetpairssrc在該懇求的響應(yīng)中，效勞器產(chǎn)生會話id，在Session頭域攜帶該信息，而假如SETUP懇求已經(jīng)攜帶Session id，效勞器必須處理這個Session id，參加已經(jīng)存在的Session里面 SETUPPage 14與SIP的SDP交互不同，一般來說RTSP在SETUP的懇求響應(yīng)過程中，通過Transport字段交換效勞器、客戶端的媒體IP地址、端口Transport指示使用的傳輸協(xié)議，以及配置相關(guān)參數(shù)，如目的地址，壓縮方式、端口等；transport/profile框架定義/lower-transport；

8、destination目的地址client_port目的端口source流的源地址interleaved媒體流和控制流混合發(fā)送，指定要交織的通道數(shù)，交織格式：媒體數(shù)據(jù)被封裝以$符號0 x24，后跟一字節(jié)的通道標(biāo)識，兩字節(jié)的長度網(wǎng)絡(luò)字節(jié)序，媒體流SETUP補充Page 15PLAY方法懇求效勞器使用SETUP建立的機制開場發(fā)送數(shù)據(jù)，客戶端不能在SETUP成功之前發(fā)送PLAY懇求，因為RTSP是一個有狀態(tài)協(xié)議。PLAY懇求通過Range頭域設(shè)置了正常播放時間NPT，播放從Range指定的開場位置開場播放，直到Range指定的完畢位置完畢播放。不帶Range頭也是正常的懇求，表示從內(nèi)容開場處開場播放

9、，直到遇到暫停。如客戶端懇求：PLAY rtsp audio.example /audio RTSP/1.0CSeq: 835Session: 12345678Range: npt=10-15該例子使用npt來指定播放范圍。此外還可以使用SMPTE相對時間戳 、clock 絕對時間PLAYPage 16PAUSE懇求暫停播放內(nèi)容，PAUSE可以攜帶Range頭域，但是不能是一個范圍，而是一個時間點，也就是一個準(zhǔn)確的值。假如Range頭域不存在，那么立即停頓播放，把停頓點設(shè)置成當(dāng)前時間。如下是一個PAUSE懇求的例子：客戶端懇求：PAUSE rtsp example /fizzle/foo RT

10、SP/1.0 CSeq: 834 Session: 12345678效勞器響應(yīng)：RTSP/1.0 200 OK CSeq: 834 Date: 23 Jan 1997 15:35:06 GMTPAUSEPage 17TEARDOWN懇求完畢播放，效勞器釋放已經(jīng)分配的資源。完畢之后，session id不再有效。如下面例子所示：客戶端懇求：TEARDOWN rtsp 192.168.1.100:554/pinball.wmv RTSP/1.0User-Agent: WMPlayer/9.0.0.2991 guid/3300AD50-2C39-46C0-AE0A-79C1934B364DAccep

11、t-Charset: UTF-8, *;q=0.1X-Accept-Authentication: Negotiate, NTLM, Digest, BasicAccept-Language: en-us, *;q=0.1Session: 4301725529333472257CSeq: 9X-Playlist-Gen-Id: 16TEARDOWNPage 18REDIRECT效勞器通過這個懇求，告訴客戶端應(yīng)該懇求另外一個位置的媒體。REDIRECT懇求攜帶Location頭域，以便告訴客戶端新的位置。同時還攜帶Range頭域，告訴客戶端什么時候開場重定向。如下例子是效勞器給客戶端發(fā)REDIR

12、ECT懇求：REDIRECT rtsp example /fizzle/foo RTSP/1.0 CSeq: 732 Location: rtsp bigserver :8001 Range: clock=19960213T143205Z-這個懇求讓客戶端于1996年2月13日14：32：05開場重定向到效勞器bigserver :8001。Page 19RECORDRECORD懇求效勞器錄播一段內(nèi)容，時間戳反映了開場時間和完畢時間，格式是UTC。RECORD懇求可以沒有時間范圍，默認(rèn)使用內(nèi)容開場時間和完畢時間。效勞器決定是否使用懇求的URI或者另外一個URI來存儲內(nèi)容。假如效勞器沒有使用懇求

13、URI，效勞器返回201已產(chǎn)生，攜帶Location頭域指定位置，而且在實體中描繪新資源。如客戶端懇求效勞器：RECORD rtsp example /meeting/audio.en RTSP/1.0 CSeq: 954 Session: 12345678 Conference: 128.16.64.19/32492374Page 20第第1 1章章 RTSPRTSP協(xié)議介紹協(xié)議介紹第第3 3章章 RTP/RTCPRTP/RTCP介紹介紹 RTSP中的SDP與SIP不同，一般是單向的 由效勞器在客戶端的Describe消息的200響應(yīng)中協(xié)議帶 因此SDP一般不能描繪效勞器、客戶端的媒體地址和

14、端口，只能描繪媒體的類型以及Profile-Level等詳細(xì)信息RTSP-SDPv=0 /以下都是sdp信息o=OnewaveUServerNG 1451516402 1025358037 IN IP4 192.168.20.136s=/xxx666u= /e=adminc=IN IP4 0.0.0.0t=0 0a=isma-compliance:1,1.0,1a=range:npt=0-m=video 0 RTP/AVP 96 /m表示媒體描繪，下面是對會話中視頻通道的媒體描繪a=rtpmap:96 MP4V-ES/90000a=fmtp:96 profile-level-id=245;co

15、nfig=000001B0F5000001B509000001000000012000C888B0E0E0FA62D089028307a=control:trackID=0/trackID0表示視頻流用的是通道0CS 414 - Spring 2020SDP實例Page 23第第1 1章章 RTSPRTSP協(xié)議介紹協(xié)議介紹第第2 2章章 SDPSDP介紹介紹 RTPReal-time Transport Protocol是用于同步傳輸實時多媒體數(shù)據(jù)流的一種傳輸協(xié)議。 RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現(xiàn)流同步。 RTP通常使用UDP來傳送數(shù)據(jù)，但RTP也可

16、以在TCP或ATM等其他協(xié)議之上工作。 當(dāng)應(yīng)用程序開場一個RTP會話時將使用兩個端口：一個給RTP，一個給RTCP。 RTP本身并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些效勞。實時傳輸協(xié)議RTPn前12個字節(jié)是必須的。CSRC標(biāo)識符列表只有在混合器mixer插入時才存在RTP報文頭格式 Vversion：RTP版本，現(xiàn)為2。 Ppadding：填充標(biāo)志。假設(shè)設(shè)置那么報文包含一個填充的八位字節(jié)集，用于某些加密算法。 Xextension：擴展位標(biāo)志。假設(shè)設(shè)置那么在固定報文頭后跟一個報文頭擴展。 CSRC計數(shù)：指出固定報文頭后跟的作用源標(biāo)識符的數(shù)

17、量。 Mmaker：允許標(biāo)記幀邊界報文流中的重要事件。 載荷類型：規(guī)定RTP報文中載荷的格式。 序號：被接收方用來恢復(fù)報文序列和檢測報文喪失。 時間戳：表示抽樣載荷數(shù)據(jù)時的時間。 SSRCsynchronization source標(biāo)識符：同步源標(biāo)識符是為一個RTP主機隨機選擇的標(biāo)識符，一樣源的所有報文具有一樣的SSRC標(biāo)識符，同一個RTP會話中的每個設(shè)備必須有一個惟一的SSRC標(biāo)識符。 CSRCcontributing source標(biāo)識符：作用源標(biāo)識符包含一個當(dāng)前報文中載荷源的列表，用于接收方標(biāo)識源發(fā)送方。該字段只有當(dāng)使用混合器組合不同的報文流時才使用。RTP報文說明 常見的載荷類型pt值大

18、部分視頻是動態(tài)協(xié)商a=rtpmap:0 pcmu/8000a=rtpmap:8 pcma/8000a=rtpmap:3 gsm/8000a=rtpmap:18 G729/8000a=rtpmap:18 G729a/8000 復(fù)雜的音視頻編碼，并不是把編碼后的內(nèi)容直接負(fù)載在RTP上的，一般還有中間一層的封包層如H.263就有RFC2190、RFC2429、RFC4629三種格式 RTP不僅支持音/視頻流，任何連續(xù)數(shù)據(jù)流的應(yīng)用都可使用RTP效勞。RTP載荷類型 RTCPReal-time Transport Control Protocol和RTP一起提供流量控制和擁塞控制效勞。 在RTP會話期間，各參與者周期性地傳送RTCP包。RTCP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、喪失的數(shù)據(jù)包的數(shù)量等統(tǒng)計資料，效勞器利用這些信息動態(tài)地改變傳輸速率，甚至改變有效載荷類型。 RTCP也使用UDP進展通信，它和 RTP配合使用，能以有效的反響和最小的開銷使傳輸效率最正確化，因此特別合適傳送網(wǎng)上的實時數(shù)據(jù)。實時傳輸控制協(xié)議RTCP 發(fā)送方報告Sender Report：由RTP數(shù)據(jù)流的源通過組播發(fā)送，提供發(fā)送方觀察到的傳輸和接收統(tǒng)計信息。 接收方報告Receiver Report：提供非主動發(fā)送方的參與者的接收統(tǒng)計信息。 源描繪報告Source DEScription：被RTP發(fā)