1、.產(chǎn)品名稱Product name密級Confidentiality level產(chǎn)品版本Product versionTotal pages 共 頁RTSP簡介(僅供內(nèi)部使用)擬制:日期：yyyy-mm-dd審核:日期：yyyy-mm-dd審核:日期：yyyy-mm-dd批準(zhǔn):日期：yyyy-mm-dd版權(quán)所有 侵權(quán)必究修訂記錄日期修訂版本描述作者目 錄1概要72流媒體基本業(yè)務(wù)組網(wǎng)圖73RTSP 介紹83.1RTSP是什么？83.2RTSP URL的語法結(jié)構(gòu)83.3RTSP 消息83.3.1消息83.3.2請求消息83.3.3響應(yīng)消息103.4信令113.4.1OPTIONS113.4.2DE

2、SCRIBE123.4.3SETUP133.4.4PLAY133.4.5PAUSE143.4.6TEARDOWN143.5Header Field 解析153.5.1Accept163.5.2Cseq163.5.3Range173.5.4RTP-Info173.5.5Session173.5.6Transport183.5.7User-Agent184移動流媒體與RTSP184.1點(diǎn)播流程194.2SDP204.3數(shù)據(jù)傳送214.4消息流程22表目錄 List of Tables表1：信令簡要描述11表2：RTSP頭字段簡述16圖目錄 List of Figures圖1 流媒體業(yè)務(wù)基本組網(wǎng)圖7

3、圖2 RTSP消息交互19圖3 協(xié)議棧的簡單描述22測試方案關(guān)鍵詞： RTSP, Streaming, ethereal, TCP, HMS摘 要：本文主要介紹RTSP的基本消息信令及手機(jī)與HMS的RTSP的消息交互過程縮略語清單： 對本文所用縮略語進(jìn)行說明，要求提供每個縮略語的英文全名和中文解釋。3GP3GPP file formatCODECCOder / DECoderIPInternet ProtocolMP4MPEG-4 file formatPSSPacket-switched Streaming ServiceRFCIETF Request For CommentsRTCPRTP

4、 Control ProtocolRTPReal-time Transport ProtocolRTSPReal-Time Streaming Protocol SDPSession Description ProtocolTCPTransport Control ProtocolUDPUser Datagram ProtocolURIUniversal Resource IdentifierWAPWireless Application Protocol1 概要RTSP（Real Time Streaming Protocol）實時流協(xié)議：一種流媒體控制協(xié)議，可對流媒體進(jìn)行暫停、快進(jìn)、快倒等

5、操作。流媒體就是實時在線點(diǎn)播。而流媒體與普通媒體的差別在于：對于普通媒體，在訪問它之前要得到全部的內(nèi)容；對于流媒體，則在完全接收到全部內(nèi)容之前就開始訪問。本文主要介紹RTSP的基本消息信令及手機(jī)與HMS的RTSP的消息交互過程。2 流媒體基本業(yè)務(wù)組網(wǎng)圖圖1 流媒體業(yè)務(wù)基本組網(wǎng)圖3 RTSP 介紹3.1 RTSP是什么？RTSP（Real Time Streaming Protocol），實時流協(xié)議，是一種應(yīng)用層的協(xié)議，用于實時的控制數(shù)據(jù)的傳輸。RTSP提供一個可擴(kuò)展的架構(gòu)來實現(xiàn)控制實時媒體的在線點(diǎn)播，如音頻或是視頻內(nèi)容。數(shù)據(jù)源可以是直播信號也可以是制作好的媒體文件。RTSP能夠同時控制多個數(shù)據(jù)

6、傳輸會話過程，3.2 RTSP URL統(tǒng)一資源定位符（Uniform Resource Locator，縮寫為URL）。的語法結(jié)構(gòu)一個終端用戶是通過在播放器中輸入URL地址開始進(jìn)行觀看流媒體業(yè)務(wù)的第一步，而對于使用RTSP協(xié)議的移動流媒體點(diǎn)播而言，URL的一般寫法如下：一個以“rtsp”或是“rtspu”開始的URL鏈接用于指定當(dāng)前使用的是RTSP 協(xié)議。RTSP URL的語法結(jié)構(gòu)如下：rtsp_URL=(“rtsp:”| “rtspu:”) “/” host “:”port” /abs_path/content_namehost：可以是一個有效的域名或是IP地址。port：端口號，對于RTS

7、P協(xié)議來說，缺省的端口號為554，即如HTTP的缺省端口號是80一樣。當(dāng)我們在確認(rèn)流媒體服務(wù)器提供的端口號為554時，此項可以省略說明：當(dāng)HMS服務(wù)器使用的端口號為554時，我們在寫點(diǎn)播鏈接時，可以不用寫明端口號，但當(dāng)使用非554端口時，在RTSP URL中一定要指定相應(yīng)的端口。注：我們在點(diǎn)播時使用的都是rtsp，而沒有使用到rtspu。3.3 RTSP 消息3.3.1 消息RTSP是一種基于文本的協(xié)議，用CRLFCRLF - Carriage-Return Line-Feed 回車換行。作為一行的結(jié)束符。使用基于文本協(xié)議的好處在于我們可以隨時在使用過程中的增加自定義的參數(shù)，也可以隨便將協(xié)議包

8、抓住很直觀的進(jìn)行分析。RTSP從傳輸方向上有兩種消息，即“請求消息”及“回應(yīng)消息”。一個消息一般由頭和內(nèi)容組成，不過也有很多的消息是只有消息頭（message head or header）而沒有消息體（message body）的。3.3.2 請求消息一個請求消息（a request message）即可以由客戶端向服務(wù)端發(fā)起也可以由服務(wù)端向客戶端發(fā)起。請求消息的語法結(jié)構(gòu)如下：Request=Request-Line*(general-header | request-header | entity-header)CRLFmessage-body1. Request Line請求消息的第一行

9、的語法結(jié)構(gòu)如下：Request-Line=Method 空格 Request-URI 空格 RTSP-Version CRLF其中在消息行中出現(xiàn)的第一個單詞即是所使用的信令標(biāo)志。目前已經(jīng)有的信息標(biāo)志如下：Method =“DESCRIBE” |“ANNOUNCE”|“GET_PARAMETER”|“OPTIONS”|“PAUSE”|“PLAY”|“RECORD”|“REDIRECT”|“SETUP”|“SET_PARAMETER”|“TEARDOWN”|extension-methodextension-method= 標(biāo)志我們可以使用自己定義的信令標(biāo)示符Request-URI = “*” |

10、 absolute_URI請使用請求媒體存放的絕對路徑RTSP-Version = “RTSP” “/” 1*DIGIT “.” 1*DIGITRTSP的版本號例子：DESCRIBE rtsp:/27/3.3gp RTSP/1.02. Request Header Fields在消息頭中除了第一行的內(nèi)容外，還有一些需求提供附加信息。其中有些是一定要的，后續(xù)我們會詳細(xì)介紹經(jīng)常用到的幾個域的含義。Request-header=Accept|Accept-Encoding|Accept-Language|Authorization|From|If-Modified-Since

11、|Range|Referer|User-Agent3.3.3 響應(yīng)消息客戶端或是服務(wù)端在接收并解釋一個請求消息后，會回復(fù)一個消息（response message）給請求方。響應(yīng)消息的語法結(jié)構(gòu)如下：Response=Status-Line*(general-header |response-header|entity-header)CRLFmessage-body1. Status-Line響應(yīng)消息的第一行是狀態(tài)行（status-line），每個元素之間用空格分開。除了最后的CRLF之外，在此行的中間不得有CR或是LF的出現(xiàn)。它的語法格式如下，Status-Line = RTSP-Versio

12、n 空格 Status-Code 空格 Reason-Phrase CRLFStatus-Code 是一個三位數(shù)的整數(shù)，用于描述接收方對所收到請求消息的執(zhí)行結(jié)果，而Reason-Phrase是對Status-Code給出一個簡短的文字描述，便于我們在收到一個消息后，不用每次都去查看code的解釋，而只需要看Reason-Phrase就可以大概了解當(dāng)前請求的執(zhí)行狀態(tài)。Status-Code的第一位數(shù)字指定了這個回復(fù)消息的種類，一共有5類：n 1XX: Informational 請求被接收到，繼續(xù)處理n 2XX: Success 請求被成功的接收，解析并接受n 3XX: Redirection

13、為完成請求需要更多的操作n 4XX: Client Error 請求消息中包含語法錯誤或是不能夠被有效執(zhí)行n 5XX: Server Error 服務(wù)器響應(yīng)失敗，無法處理正確的有效的請求消息我們在處理問題時經(jīng)常會遇到的狀態(tài)碼有如下：Status-Code =“200”:OK|“400”:Bad Request|“404”:Not Found|“500”Internal Server ErrorRTSP的狀態(tài)碼也是可以擴(kuò)展的。服務(wù)器可以根據(jù)實際情況定義相應(yīng)的狀態(tài)碼及描述信息。2. Response Header Fields在響應(yīng)消息的域中存放的是無法放在Status-Line中,而又需要傳送給

14、請求者的一些附加信息。Response-header =Location|Proxy-Authenticate|Public|Retry-After|Server|Vary|WWW-Authenticate3.4 信令信令指的是在Request-URI中指定的需要被接收者完成的操作。信令（The method）大小寫敏感，不能以字符”$”開始，并且一定要是一個標(biāo)記符。概要描述如下：信令發(fā)送方向是否一定需要DESCRIBEC-S建議ANNOUNCEC-S, S-C可選擇的GET_PARAMETERC-S, S-C可選擇的OPTIONSC-S, S-C必需 (S-C: 可選擇的)PAUSEC-S建

15、議PLAYC-S必需RECORDC-S可選擇的REDIRECTS-C可選擇的SETUPC-S必需SET_PARAMETERC-S, S-C可選擇的TEARDOWNC-S必需表1：信令簡要描述C：客戶端S：服務(wù)端下面介紹幾個常用的信令3.4.1 OPTIONS （查詢功能）例子：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, PAUS

16、E OPTIONS消息可以在任何時間被發(fā)起，如MOTO835手機(jī)就會每隔60秒左右向服務(wù)器端發(fā)送一個OPTIONS的消息，而HMS服務(wù)器在檢查MOTO835是否仍在線時，也是通過來檢查服務(wù)器端是否定時收到OPTIONS的消息來實現(xiàn)的。但需注意的是，并不是所有的手機(jī)和播放器會定時發(fā)送OPTIONS消息到服務(wù)器端，即使有發(fā)送，發(fā)送OPTIONS的消息的時間間隔也是不盡相同的。3.4.2 DESCRIBEDESCRIBE消息是由客戶端發(fā)送到服務(wù)器端，用于客戶端得到請求鏈接（request URL）中指定的媒體文件的相關(guān)描述。DESCRIBE的這一對交互消息完成了RTSP的媒體初始化。例子：C-S:

17、DESCRIBE rtsp://fizzle/foo RTSP/1.0 CSeq: 312 Accept: application/sdp, application/rtsl, application/mheg S-C: RTSP/1.0 200 OK CSeq: 312 Date: 23 Jan 1997 15:35:06 GMT Content-Type: application/sdp Content-Length: 376 v=0 （這里就是MESSAGE BODY，它的長度由Content_Length來指定）o=mhandley 28908445

18、26 2890842807 IN IP4 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= (Mark Handley) c=IN IP4 2/127 t=2873397496 2873404696 a=recvonly m=audio 3456 RTP/AVP 0 m=video 2232 RTP/AVP 31 m=whiteboard 32416

19、UDP WB a=orient:portrait DESCRIBE的響應(yīng)消息必須包含所有的媒體初始化信息。對于基于RTSP的系統(tǒng)，媒體初始化是必須的，但是并不一定要通過DESCRIBE消息來得到，這里是一個RTSP的客戶端得到初始化信息的三種方式：n 通過RTSP的DESCRIBEn 一些其它的協(xié)議，如HTTP，email attachment等n 命令行方式3.4.3 SETUPSETUP請求用于指定流媒體使用的傳輸機(jī)置。在請求消息中會指定客戶端在數(shù)據(jù)傳輸時相關(guān)的傳送參數(shù)，而在響應(yīng)消息中將包含由服務(wù)器端所指定的傳輸參數(shù)。服務(wù)器端在回復(fù)SETUP消息時將會生成一個session ID. 例子：

20、C-S: SETUP rtsp://foo/bar/baz.3gp RTSP/1.0 CSeq: 302 Transport: RTP/AVP;unicast;client_port=4588-4589 S-C: RTSP/1.0 200 OK CSeq: 302 Date: 23 Jan 1997 15:35:06 GMT Session: 47112344 Transport: RTP/AVP;unicast; client_port=4588-4589;server_port=6256-6257 服務(wù)器端在回復(fù)SETUP消息時將會生成一個session ID. 3.

21、4.4 PLAYPLAY消息是告訴服務(wù)器端可以使用在SETUP消息中所指定的傳輸機(jī)置開始傳送數(shù)據(jù)。需要指出的是，客戶端不應(yīng)該發(fā)送任何PLAY請求直到所有的SETUP消息被成功解析。PLAY消息會在range中指定媒體的播放時間，服務(wù)器在接到PLAY消息后會由range中指定的開始點(diǎn)開始發(fā)送媒體數(shù)據(jù)直到range中指定的結(jié)束點(diǎn)。所有的PLAY消息都是必須按順序被處理的，即當(dāng)一個PLAY的請求到達(dá)時，而上一個PLAY請求還未完成，后面的PLAY請求將被延時，直到第一個PLAY處理完成時才會被處理。例子：C-S: PLAY rtsp://audio RTSP/1.0

22、 CSeq: 835 Session: 12345678 Range: npt=10-153.4.5 PAUSEPAUSE消息是用于暫時中斷流媒體的傳送。當(dāng)暫停的時間過長（這個值應(yīng)在SETUP消息中由timeout參數(shù)指定），服務(wù)器可以自動斷開這個會話，釋放所占用的資源。例子: C-S: PAUSE rtsp://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 服務(wù)器不是必須要支持PAUSE信令的，例如

23、，對于直播的節(jié)目，就可以不支持暫停。當(dāng)一個服務(wù)器不支持某一個信令時，必須要返回給客戶端以“501 Not Implemented”的響應(yīng)消息，并且客戶端應(yīng)該不再嘗試向服務(wù)器端發(fā)送這個請求。3.4.6 TEARDOWNTEARDOWN消息是用于停止媒體數(shù)據(jù)的傳送，并釋放所占用的資源。例子： C-S: TEARDOWN rtsp://fizzle/foo RTSP/1.0 CSeq: 892 Session: 12345678 S-C: RTSP/1.0 200 OK CSeq: 892 3.5 Header Field 解析在每個消息中都會包含一定的字段用于描述一些信息。T

24、ype ”g” 指通用，在請求消息和響應(yīng)消息中都可能出現(xiàn)Type “R” 指請求消息Type “r” 指響應(yīng)消息Type “e” 指實體頭字段頭類型支持信令A(yù)cceptRopt.entityAccept-EncodingRoptentityAccept-LanguageRoptallAllowropt.allAuthorizationRopt.allBandwidthRoptallBlocksizeRopt.all but OPTIONS, TEARDOWNCache-Controlgopt.SETUPConferenceRoptSETUPConnectiongreqallContent-Ba

25、seeopt.entityContent-Encodingereq.SET_PARAMETERContent-Encodingereq.DESCRIBE, ANNOUNCEContent-LanguageereqDESCRIBE, ANNOUNCEContent-Lengthereq.SET_PARAMETER, ANNOUNCEContent-Lengthereq.entityContent-LocationeoptentityContent-Typeereq.SET_PARAMETER, ANNOUNCEContent-Typerreq.entityCSeqgreqAllDategopt.

26、AllExpireseopt.DESCRIBE, ANNOUNCEFromRopt.AllIf-Modified-SinceRopt.DESCRIBE, SETUPLast-Modifiedeopt.EntityProxy-Authenticate Proxy-RequireRreq.AllPublicropt.AllRangeRoptPLAY, PAUSE, RECORDRangeropt.PLAY, PAUSE, RECORDRefererRopt.AllRequireRreq.AllRetry-Afterropt.AllRTP-Inforreq.PLAYScaleRropt.PLAY,

27、RECORDSessionRrreq.all but SETUP, OPTIONSServerropt.AllSpeedRropt.PLAYTransportRrreq.SETUPUnsupportedrreq.AllUser-AgentRopt.AllViagopt.AllWWW-Authenticateropt.All 表2：RTSP頭字段簡述下面簡要介紹一些在RTSP中常用到的頭字段，詳細(xì)的信息請查看RFC 2326。3.5.1 AcceptAccept字段可用于指定可被接受的描述類型例子: Accept: application/rtsl, application/sdp;level=

28、23.5.2 CseqCseq域指定一對RTSP請求-響應(yīng)消息的序列號。在請求消息及響應(yīng)消息中一定要指定這個域。對于請求消息，會有一個具有相同Cseq域內(nèi)容的響應(yīng)消息與之對應(yīng)。例子：C-S: SETUP rtsp://foo/bar/baz.3gp RTSP/1.0 CSeq: 302 Transport: RTP/AVP;unicast;client_port=4588-4589 S-C: RTSP/1.0 200 OK CSeq: 302 Date: 23 Jan 1997 15:35:06 GMT Session: 47112344 Transport: RTP/A

29、VP;unicast; client_port=4588-4589;server_port=6256-6257 3.5.3 RangeRange用于在請求消息和響應(yīng)消息中指定播放的時間段。例子：: Range: clock=19960213T143205Z-;time=19970123T143720Z3.5.4 RTP-Info這個域用于在回復(fù)PLAY消息中指定RTP特殊的參數(shù)url:與設(shè)置的RTP參數(shù)對應(yīng)的流媒體鏈接seq:流媒體第一個包的序列號rtptime:用于回復(fù)range域?qū)?yīng)的RTP時間戳RTP-Info語法結(jié)構(gòu)： RTP-Info = RTP-Info : 1#stream-ur

30、l 1*parameter stream-url = url = url parameter = ; seq = 1*DIGIT | ; rtptime = 1*DIGIT例子：RTP-Info:url=rtsp://bar.avi/streamid=0;seq=45102,url=rtsp://bar.avi/streamid=1;seq=30211 3.5.5 SessionSession域在請求與響應(yīng)消息中用于識別一個RTSP會話（RTSP session即一個完整的RTSP交互過程。例如：在點(diǎn)播流媒體時，一個典型的會話過程包括一個客戶建立一個傳輸通道（SET

31、UP），用PLAY開始傳輸流，最后用TEARDOWN來斷開這個連接）。一旦客戶端接收到Session標(biāo)識，在這個會話中的任何請求都需要附加這個域。Session語法結(jié)構(gòu)：Session = Session : session-id ; timeout = delta-seconds 例子：Session: 123456783.5.6 Transport這個域在請求消息中是標(biāo)識哪一種傳輸協(xié)議將被使用，并指定一些在描述說明中沒有指定的參數(shù)的值。使用的傳輸協(xié)議之間用逗號分隔，參數(shù)之間用分號分隔常用參數(shù)：unicast | multicast:單播還是組播（缺省值為multicast）.destina

32、tion:指定流將被傳送到到哪個地址port: (RTP協(xié)議):指定RTP/RTCP端口號（multicast）。一般為一個范圍。e.g., port=3456-3457.Client_port: 客戶端選擇的用于接收媒體數(shù)據(jù)及控制信息的單播 RTP/RTCP端口號。e.g., port=3456-3457Server_port: 服務(wù)器端用于接收媒體數(shù)據(jù)和控制信息的單播 RTP/RTCP端口號。e.g., port=3456-3457例子: Transport:RTP/AVP;multicast;ttl=127;mode=PLAY, RTP/AVP;unicast;client_port=3

33、456-3457;mode=PLAY3.5.7 User-Agent這個域用于用戶標(biāo)識，不同公司或是型號的手機(jī)發(fā)出的消息中的這個域的內(nèi)容都不大相同。有時會指出手機(jī)的版本號，播放器的型號等等。在HMS中的terminal.xml文件就是根據(jù)這個域中的內(nèi)容來完成簡單的終端適配的功能。例子：User-Agent:01056SS68001117616022101802836055;14;41;4578;327;13824;0;1;0x0202;0x00000B;0x0280104 移動流媒體與RTSP移動流媒體技術(shù)就是把連續(xù)的影像和聲音信息經(jīng)過壓縮處理后放到網(wǎng)絡(luò)服務(wù)器上，讓移動終端用戶能夠一邊下載一邊

34、觀看、收聽，而不需要等到整個多媒體文件下載完成就可以即時觀看的技術(shù)。實際上移動流媒體技術(shù)是網(wǎng)絡(luò)音視頻技術(shù)和移動通訊技術(shù)發(fā)展到一定階段的產(chǎn)物，它是融合很多網(wǎng)絡(luò)技術(shù)之后所產(chǎn)生的技術(shù)，它會涉及到流媒體數(shù)據(jù)的采集、壓縮、存輸以及網(wǎng)絡(luò)通信等多項技術(shù)。它大致分為下面兩大類業(yè)務(wù)類型： 流媒體點(diǎn)播(VOD)內(nèi)容提供商將預(yù)先錄制好的多媒體內(nèi)容編碼壓縮成相應(yīng)格式，存放在內(nèi)容服務(wù)器上并把內(nèi)容的描述信息以及鏈接放置在流媒體的portal上。最終用戶就可以通過訪問portal，發(fā)現(xiàn)感興趣的內(nèi)容，有選擇的進(jìn)行播放。 流媒體直播流媒體編碼服務(wù)器將實時信號編碼壓縮成相應(yīng)的格式，并經(jīng)由流媒體服務(wù)器分發(fā)到用戶的終端播放器。根據(jù)實

35、時內(nèi)容信號源的不同，又可以分為電視直播、遠(yuǎn)程監(jiān)控等。對于點(diǎn)播和直播，都是使用的RTSP協(xié)議。下面我們介紹在實際應(yīng)用中RTSP消息是如何交互來完成點(diǎn)播或是直播功能。4.1 點(diǎn)播流程一個移動用戶使用手機(jī)通過訪問網(wǎng)頁得到URI，在URI中指定了流媒體服務(wù)器的地址及想要訪問的媒體內(nèi)容。通過RTSP SETUP消息來建立客戶端與流媒體服務(wù)器之間的連接，然后客戶端通過發(fā)送一個RTSP PLAY的消息來通知服務(wù)器開始傳送一個或多個媒體流。具體消息交互過程如下：UESGSNMedia ServerWAP/Web serverGet Web/WAP Page with URIRTSP:DESCRIBE ( ge

36、t content description file)RTSP:SETUPRTSP:SETUPRTSP:PLAYRTSP:PAUSERTSP:TEARDOWNIP/UDP/RTP content圖2 RTSP消息交互每次客戶端發(fā)送一個請求消息，服務(wù)器端都會回一個相應(yīng)的響應(yīng)消息。1. 手機(jī)通過上網(wǎng)得到帶有流媒體地址的網(wǎng)頁，并點(diǎn)播一個節(jié)目2. 手機(jī)上發(fā)RTSP：DESCRIBE的消息給服務(wù)器，服務(wù)器處理其中的URL鏈接，得到相應(yīng)文件的SDP信息，附加在響應(yīng)消息中返回給手機(jī)。如果此時服務(wù)器找不到手機(jī)想要點(diǎn)播的文件，就會回應(yīng)400的錯誤給手機(jī)，顯示文件不存在。3. 手機(jī)根據(jù)收到的SDP的信息向服務(wù)器發(fā)

37、送RTSP:SETUP消息，與服務(wù)器建立連接。如果媒體文件包含音頻和視頻，就會有兩次SETUP的交互消息。一個是音頻的信息，一個是視頻的信息。如果交互成功，服務(wù)器會發(fā)送200的OK消息給手機(jī)4. 手機(jī)在SETUP消息執(zhí)行成功后，會向服務(wù)器發(fā)送RTSP：PLAY的消息，要求服務(wù)器開始發(fā)送數(shù)據(jù)。服務(wù)器在收到PLAY消息后，即會開始傳送UDP/RTP包。5. 如果在播放過程中需要暫停，手機(jī)會發(fā)送RTSP：PAUSE的消息給服務(wù)器，服務(wù)器在收到暫停消息后，即會停止發(fā)數(shù)據(jù)包，手機(jī)停止播放。如果需要繼續(xù)播放，手機(jī)只需要再發(fā)送RTSP：PLAY的消息給服務(wù)器，服務(wù)器根據(jù)暫停的位置繼續(xù)開始播放。6. 當(dāng)播放完

38、成后，手機(jī)會自動向服務(wù)器發(fā)送RTSP：TEARDOWN消息，當(dāng)服務(wù)器收到下線消息后，就會斷開與手機(jī)的連接，釋放所占用的資源。7. 點(diǎn)播過程結(jié)束。4.2 SDP在播放過程中，手機(jī)得到內(nèi)容的相關(guān)信息是很重要的，如果這些內(nèi)容不正確，也會影響播放的正確性，下面簡要介紹一下SDP。SDP文件（Session Description Protocol）包含了會話的描述，媒體類型，媒體的碼率?？蛻舳送ㄟ^RTSP DESCRIBE來得到SDP文件。RTSP需要一個內(nèi)容的描述。而SDP就被用于客戶端與服務(wù)端的一種內(nèi)容描述的格式。在傳送給客戶的SDP內(nèi)容應(yīng)該聲明了這個對話所要訪問的媒體內(nèi)容的媒體編碼類型。對于流媒

39、體服務(wù)而言，以下幾個域是在SDP中一定要包含的。“a=control:”“a=range:”“a=rtpmap:”“a=fmtp:”例子：v=0o=ghost 2890844526 2890842807 IN IP4 0s=3GPP Unicast SDP Examplei=Example of Unicast SDP fileu=/ae600e=c=IN IP4 b=AS:128t=0 0a=range:npt=0-45.678m=video 1024 RTP/AVP

40、96b=AS:128a=rtpmap:96 H263-2000/90000a=fmtp:96 profile=3;level=10a=control:rtsp;//moviea=recvonly就如我們以前所了解的，對于直播，我們在建立了直播源后，就會將生成的SDP文件broadcast.sdp放在服務(wù)器上，而用戶使用rtsp:/ip:port/broadcast.sdp就可以進(jìn)行直播節(jié)目的播放，這里的sdp文件里的內(nèi)容就是上面所提到的這些。它將我們在建立直播源時所設(shè)置的音、視頻編碼，及相應(yīng)的碼率記錄下來存在broadcast.sdp文件中，這樣手機(jī)在進(jìn)行進(jìn)播時，

41、得到了相關(guān)的SDP信息，然后根據(jù)這些信息與服務(wù)器建立連接。4.3 數(shù)據(jù)傳送控制及媒體數(shù)據(jù)的傳送是通過TCP/IP和UPD/IP上完成的，下圖是一個協(xié)議棧的簡單描述。媒體數(shù)據(jù)被打包成RTP包進(jìn)行傳送。圖3 協(xié)議棧的簡單描述4.4 消息流程下面讓我們來看一個具體的消息交互過程。我們可以通過ETHEREAL或是TCPDUMP這些抓包工具來獲得這些信息。c-s【向服務(wù)器請求SDP信息】【DESCRIBE】DESCRIBE rtsp:/27/3.3gp RTSP/1.0【交互標(biāo)識】CSeq: 1【請求內(nèi)容】Accept: application/sdp【用戶標(biāo)識】User-Age

42、nt:01056SS68001117616022101802836055;14;41;4578;327;13824;0;1;0x0202;0x00000B;0x028010s-c 【服務(wù)端返回SDP信息】【成功響應(yīng)】RTSP/1.0 200 OK【服務(wù)器版本號】Server: HMS Mobile V100R001B08D023【交互標(biāo)識】CSeq: 1【SDP長度】Content-Length: 625【包含內(nèi)容類型】Content-Type: application/sdp【包含內(nèi)容信息】Content-Base: rtsp:/27/3.3gp/【以下為SDP內(nèi)容】

43、【SDP版本號】v=0【服務(wù)器信息】o=StreamingServer 3276474929 1067418948000 IN IP4 08【文件名】s=3.3gp【URL】u=rtsp:/27/3.3gp【e-mail】e=admin【IPv4】c=IN IP4 t=0 0【控制屬性】a=control:rtsp:/27/3.3gp【視頻信息】m=video 0 RTP/AVP 96【媒體類型】【視頻帶寬】b=AS:16【視頻格式】a=rtpmap:96 MP4V-ES【格式】/90000【采樣率】【視頻格式】a=fmtp:96 profile-level-id=8; config=000001B008000001B50EA020202F000001000000012000C788BA9850584121463Fa=mpeg4-esid:201【廠家信息】a=x-envivio-verid:00011118【視頻軌道】a=control:trackID=65737【音頻信息】m=audio 0 RTP/AVP 97【媒體類型