第一部分:RTSP協(xié)議

一等恐、RTSP協(xié)議概述

RTSP(Real-TimeStream Protocol )是一種基于文本的應用層協(xié)議塌鸯，在語法及一些消息參數(shù)等方面迹卢，RTSP協(xié)議與HTTP協(xié)議類似尉咕。

RTSP被用于建立的控制媒體流的傳輸莹弊，它為多媒體服務扮演“網(wǎng)絡遠程控制”的角色蟋恬。盡管有時可以把RTSP控制信息和媒體數(shù)據(jù)流交織在一起傳送髓介，但一般情況RTSP本身并不用于轉(zhuǎn)送媒體流數(shù)據(jù)。媒體數(shù)據(jù)的傳送可通過RTP/RTCP等協(xié)議來完成筋现。

一次基本的RTSP操作過程是:首先唐础，客戶端連接到流服務器并發(fā)送一個RTSP描述命令（DESCRIBE）。流服務器通過一個SDP描述來進行反饋矾飞，反饋信息包括流數(shù)量一膨、媒體類型等信息∪髀伲客戶端再分析該SDP描述豹绪，并為會話中的每一個流發(fā)送一個RTSP建立命令(SETUP)，RTSP建立命令告訴服務器客戶端用于接收媒體數(shù)據(jù)的端口申眼。流媒體連接建立完成后瞒津，客戶端發(fā)送一個播放命令(PLAY)，服務器就開始在UDP上傳送媒體流（RTP包）到客戶端括尸。 在播放過程中客戶端還可以向服務器發(fā)送命令來控制快進巷蚪、快退和暫停等。最后濒翻，客戶端可發(fā)送一個終止命令(TERADOWN)來結(jié)束流媒體會話

二屁柏、RTSP協(xié)議與HTTP協(xié)議區(qū)別

1.? RTSP引入了幾種新的方法，比如DESCRIBE有送、PLAY淌喻、SETUP 等，并且有不同的協(xié)議標識符雀摘，RTSP為rtsp 1.0,HTTP為http 1.1裸删；

2.? HTTP是無狀態(tài)的協(xié)議，而RTSP為每個會話保持狀態(tài)阵赠；

3.? RTSP協(xié)議的客戶端和服務器端都可以發(fā)送Request請求涯塔，而在HTTPF協(xié)議中肌稻，只有客戶端能發(fā)送Request請求。

4.? 在RTSP協(xié)議中伤塌，載荷數(shù)據(jù)一般是通過帶外方式來傳送的(除了交織的情況)灯萍，及通過RTP協(xié)議在不同的通道中來傳送載荷數(shù)據(jù)。而HTTP協(xié)議的載荷數(shù)據(jù)都是通過帶內(nèi)方式傳送的每聪，比如請求的網(wǎng)頁數(shù)據(jù)是在回應的消息體中攜帶的旦棉。

5.? 使用ISO10646(UTF-8) 而不是ISO 8859-1，以配合當前HTML的國際化药薯；

6.? RTSP使用URI請求時包含絕對URI绑洛。而由于歷史原因造成的向后兼容性問題，HTTP/1.1只在請求中包含絕對路徑童本，把主機名放入單獨的標題域中真屯；

三、RTSP重要術(shù)語

1.? 集合控制(Aggregatecontrol ):

對多個流的同時控制穷娱。對音頻/視頻來講绑蔫，客戶端僅需發(fā)送一條播放或者暫停消息就可同時控制音頻流和視頻流。

2.? 實體(Entity)：

作為請求或者回應的有效負荷傳輸?shù)男畔⒈枚睢Ｓ梢詫嶓w標題域（entity-header field）形式存在的元信息和以實體主體（entity body）形式存在的內(nèi)容組成

3.? 容器文件（Containerfile）：

可以容納多個媒體流的文件配深。RTSP服務器可以為這些容器文件提供集合控制。

4.? RTSP會話(RTSP session )：

RTSP交互的全過程嫁盲。對一個電影的觀看過程,會話(session)包括由客戶端建立媒體流傳輸機制(SETUP)篓叶，使用播放(PLAY)或錄制(RECORD)開始傳送流，用停止(TEARDOWN)關(guān)閉流羞秤。

四缸托、RTSP請求消息

1.? 消息格式：

方法 URI RTSP版本? ? ? CR LF

消息頭 CRLF? ? ? ? ? CRLF

消息體 CR LF

其中方法包括OPIONS、DESCRIBE瘾蛋、SETUP俐镐、PLAY、TEARDOWN等,URI是接受方的地址,例如:rtsp://192.168.0.1/video1.3gp瘦黑。

RTSP版本一般都是 RTSP/1.0京革。每行后面的CR LF表示回車換行，需要接受端有相應的解析幸斥，最后一個消息頭需要有兩個CR LF

消息體是可選的，有的Request消息并不帶消息體咬扇。

五甲葬、RTSP回應消息

1.? 消息格式：

RTSP版本狀態(tài)碼解釋? ? ? CR LF

消息頭 CR LF? ? ? ? ? CR LF

消息體 CR LF

其中RTSP版本一般都是RTSP/1.0,狀態(tài)碼是一個數(shù)值，用于表示Request消息的執(zhí)行結(jié)果,比如200表示成功,解釋是與狀態(tài)碼對應的文本解釋.

六懈贺、RTSP 重要方法

1.? ? ? ? OPTIONS:

用于得到服務器提供的可用方法经窖；

如:

OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0

CSeq: 1

服務器的回應信息會在Public字段列出提供的方法坡垫。如:

RTSP/1.0 200 OK

CSeq: 1? ? ? ? //每個回應消息的cseq數(shù)值和請求消息的cseq相對應

Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

2.? ? ? ? DESCRIBE：

客戶端向服務器端發(fā)送DESCRIBE，用于得到URI所指定的媒體描述信息画侣，一般是SDP信息冰悠。客戶端通過Accept頭指定客戶端可以接受的媒體述信息類型配乱。

如：

C->S: DESCRIBE rtsp://server.example.com/fizzle/fooRTSP/1.0

CSeq: 312

Accept: application/sdp, application/rtsl,application/mheg)

服務器回應URI指定媒體的描述信息:

如:

S->C: RTSP/1.0 200 OK

CSeq: 312

Date: 23 Jan 1997 15:35:06 GMT

Content-Type: application/sdp? //表示回應為SDP信息

Content-Length: 376

//這里為一個空行

//以下為具體的SDP信息

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

媒體初始化是任何基于RTSP系統(tǒng)的必要條件溉卓，但RTSP規(guī)范并沒有規(guī)定它必須通過DESCRIBE方法完成。RTSP客戶端可以通過以下方法來接收媒體描述信息：

a)? 通過DESCRIBE方法搬泥；

b)? 其它一些協(xié)議（HTTP桑寨，email附件，等）忿檩；

c)? 通過命令行或標準輸入設備

3.? ? ? ? SETUP：

用于確定轉(zhuǎn)輸機制尉尾，建立RTSP會話≡锿福客戶端能夠發(fā)出一個SETUP請求為正在播放的媒體流改變傳輸參數(shù)沙咏，服務器可能同意這些參數(shù)的改變。若是不同意班套，它必須響應錯誤"455 Method Not Valid In This State"肢藐。

Request中的Transport頭字段指定了客戶端可接受的數(shù)據(jù)傳輸參數(shù)；Response中的Transport 頭字段包含了由服務器選出的傳輸參數(shù)孽尽。

如:

C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0

CSeq: 302

Transport: RTP/AVP;unicast;client_port=4588-4589

服務器端對SETUPRequest產(chǎn)生一個Session Identifiers窖壕。

如:

S->C: RTSP/1.0 200 OK

CSeq: 302

Date: 23 Jan 1997 15:35:06 GMT

Session: 47112344 //產(chǎn)生一個SessionID

Transport: RTP/AVP;unicast;

client_port=4588-4589;server_port=6256-6257

4.? ? ? ? PLAY：

PLAY方法告知服務器通過SETUP中指定的機制開始發(fā)送數(shù)據(jù) 。在尚未收到SETUP請求的成功應答之前杉女，客戶端不可以發(fā)出PLAY請求瞻讽。

PLAY請求將正常播放時間（normal play time）定位到指定范圍的起始處，并且傳輸數(shù)據(jù)流直到播放范圍結(jié)束熏挎。PLAY請求可能被管道化（pipelined）速勇，即放入隊列中（queued）；服務器必須將PLAY請求放到隊列中有序執(zhí)行坎拐。也就是說烦磁，后一個PLAY請求需要等待前一個PLAY請求完成才能得到執(zhí)行。

比如哼勇，在下例中都伪，不管到達的兩個PLAY請求之間有多緊湊，服務器首先play第10到15秒积担，然后立即第20到25秒陨晶，最后是第30秒直到結(jié)束。

C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0

CSeq: 835

Session: 12345678

Range: npt=10-15

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頭可能包含一個時間參數(shù)帝璧。該參數(shù)以UTC格式指定了播放開始的時間先誉。如果在這個指定時間后收到消息湿刽，那么播放立即開始。時間參數(shù)可能用來幫助同步從不同數(shù)據(jù)源獲取的數(shù)據(jù)流褐耳。

不含Range頭的PLAY請求也是合法的诈闺。它從媒體流開頭開始播放，直到媒體流被暫停铃芦。如果媒體流通過PAUSE暫停雅镊，媒體流傳輸將在暫停點（the pause point）重新開始。

如果媒體流正在播放杨帽，那么這樣一個PLAY請求將不起更多的作用漓穿，只是客戶端可以用此來測試服務器是否存活。

5.? ? ? ? PAUSE：

PAUSE請求引起媒體流傳輸?shù)臅簳r中斷注盈。如果請求URL中指定了具體的媒體流晃危，那么只有該媒體流的播放和記錄被暫停（halt）。比如老客，指定暫停音頻僚饭，播放將會無聲。如果請求URL指定了一組流胧砰，那么在該組中的所有流的傳輸將被暫停鳍鸵。如：

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

PAUSE請求中可能包含一個Range頭用來指定何時媒體流暫停，我們稱這個時刻為暫停點（pause point）尉间。該頭必須包含一個精確的值偿乖，而不是一個時間范圍。媒體流的正常播放時間設置成暫停點哲嘲。當服務器遇到在任何當前掛起（pending）的PLAY請求中指定的時間點后贪薪，暫停請求生效。如果Range頭指定了一個時間超出了任何一個當前掛起的PLAY請求眠副，將返回錯誤"457 Invalid Range" 画切。如果一個媒體單元（比如一個音頻或視頻禎）正好在一個暫停點開始，那么表示將不會被播放或記錄囱怕。如果Range頭缺失霍弹，那么在收到暫停消息后媒體流傳輸立即中斷，并且暫停點設置成當前正常播放時間娃弓。

6.? ? ? ? TEARDOWN：

TEARDOWN請求終止了給定URI的媒體流傳輸典格，并釋放了與該媒體流相關(guān)的資源。如：

C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0

CSeq: 892

Session: 12345678

S->C: RTSP/1.0 200 OK

CSeq: 892

七台丛、RTSP重要頭字段參數(shù)

1.? Accept:

用于指定客戶端可以接受的媒體描述信息類型钝计。比如:

Accept: application/rtsl, application/sdp;level=2

2.? Bandwidth:

用于描述客戶端可用的帶寬值。

3.? ? ? ? CSeq：

指定了RTSP請求回應對的序列號齐佳，在每個請求或回應中都必須包括這個頭字段私恬。對每個包含一個給定序列號的請求消息，都會有一個相同序列號的回應消息炼吴。

4.? ? ? ? Rang：

用于指定一個時間范圍本鸣，可以使用SMPTE、NTP或clock時間單元硅蹦。

5.? Session:

Session頭字段標識了一個RTSP會話荣德。Session ID 是由服務器在SETUP的回應中選擇的，客戶端一當?shù)玫絊ession ID后童芹，在以后的對Session 的操作請求消息中都要包含Session ID.

6.? Transport:

Transport頭字段包含客戶端可以接受的轉(zhuǎn)輸選項列表涮瞻，包括傳輸協(xié)議，地址端口假褪，TTL等署咽。服務器端也通過這個頭字段返回實際選擇的具體選項。如:

Transport: RTP/AVP;multicast;ttl=127;mode="PLAY",

RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"

八生音、簡單的RTSP消息交互過程

C表示RTSP客戶端,S表示RTSP服務端

1.? 第一步：查詢服務器端可用方法

1.C->S:OPTIONrequest? ? ? //詢問S有哪些方法可用

1.S->C:OPTIONresponse? ? //S回應信息的public頭字段中包括提供的所有可用方法

2.? 第二步：得到媒體描述信息

2.C->S:DESCRIBE request? ? ? //要求得到S提供的媒體描述信息

2.S->C:DESCRIBE response? ? //S回應媒體描述信息宁否，一般是sdp信息

3.? 第三步：建立RTSP會話

3.C->S:SETUPrequest? ? ? ? ? ? //通過Transport頭字段列出可接受的傳輸選項，請求S建立會話

3.S->C:SETUPresponse? ? ? ? ? //S建立會話缀遍，通過Transport頭字段返回選擇的具體轉(zhuǎn)輸選項慕匠，并返回建立的Session ID;

4.? 第四步：請求開始傳送數(shù)據(jù)

4.C->S:PLAY request? ? ? ? //C請求S開始發(fā)送數(shù)據(jù)

4.S->C:PLAYresponse? ? ? ? ? ? //S回應該請求的信息

5.? 第五步： 數(shù)據(jù)傳送播放中

S->C:發(fā)送流媒體數(shù)據(jù)? ? // 通過RTP協(xié)議傳送數(shù)據(jù)

6.? 第六步：關(guān)閉會話，退出

6.C->S:TEARDOWN request? ? ? //C請求關(guān)閉會話

6.S->C:TEARDOWN response //S回應該請求

上述的過程只是標準的域醇、友好的rtsp流程台谊，但實際的需求中并不一定按此過程。

其中第三和第四步是必需的譬挚！第一步锅铅，只要服務器客戶端約定好，有哪些方法可用殴瘦，則option請求可以不要狠角。第二步，如果我們有其他途徑得到媒體初始化描述信息（比如http請求等等）蚪腋，則我們也不需要通過rtsp中的describe請求來完成丰歌。

第二部分:SDP協(xié)議

一、SDP協(xié)議概述SDP(SessionDescription Protocol )會話描述協(xié)議屉凯，用于描述多媒體會話立帖，它為會話通知、會話初始和其它形式的多媒體會話初始等操作提供服務悠砚。SDP的設計宗旨是通用性協(xié)議晓勇，所有它可以應用于很大范圍的網(wǎng)絡環(huán)境和應用程序，但 SDP 不支持會話內(nèi)容或媒體編碼的協(xié)商操作。SDP信息包括：會話名稱和目標绑咱；會話活動時間绰筛；構(gòu)成會話的媒體；有關(guān)接收媒體的信息描融、地址等铝噩。

二、SDP格式SDP 信息是文本信息窿克，UTF-8 編碼采用 ISO 10646 字符設置骏庸。SDP 會話描述如下（標注*符號的表示可選字段）：v= （協(xié)議版本）o= （所有者/創(chuàng)建者和會話標識符）s= （會話名稱）i=* （會話信息）u=* （URI 描述）e=* （Email 地址）p=* （電話號碼）c=* （連接信息 ― 如果包含在所有媒體中，則不需要該字段）b=* （帶寬信息）　　一個或更多時間描述（如下所示）：z=* （時間區(qū)域調(diào)整）k=* （加密密鑰）a=* （0個或多個會話屬性線路）0個或多個媒體描述（如下所示）　　時間描述t= （會話活動時間）r=* （0或多次重復次數(shù)）　　媒體描述m= （媒體名稱和傳輸?shù)刂罚﹊=* （媒體標題）c=* （連接信息 — 如果包含在會話層則該字段可選）b=* （帶寬信息）k=* （加密密鑰）a=* （0個或多個會話屬性線路）

三年叮、SDP示例v=0o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4s=SDP Seminari=A Seminar on the session description protocolu=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.pse=mjh@isi.edu (Mark Handley)c=IN IP4 224.2.17.12/127t=2873397496 2873404696a=recvonlym=audio 49170 RTP/AVP 0m=video 51372 RTP/AVP 31m=application 32416 udp wba=orient:portrait //字段解釋V=0? ? ;Version 給定了SDP協(xié)議的版本o=具被； Origin ,給定了會話的發(fā)起者信息s=;給定了Session Namei=; Information 關(guān)于Session的一些信息u=; URIe=;Emailc=;Connect Data包含連接數(shù)據(jù)t=;Timea=; Attributea=:m=; MediaAnnouncements