流媒體傳輸協(xié)議-

1、流媒體傳輸協(xié)議在基于IP的網(wǎng)絡(luò)中,用于多媒體數(shù)據(jù)實(shí)時(shí)傳輸?shù)膮f(xié)議通常有四種,即資源預(yù)留協(xié)議(Resource Reservation Protocol , RSVP、實(shí)時(shí)流協(xié)議(Real-TimeStreaming Protocol, RTSP和實(shí)時(shí)傳輸協(xié)議(Real-Time Transport Protocol, RTP及實(shí)時(shí)控制協(xié)議(Real-Time Control Protocol, RTCP 。RSVP被主機(jī)用來為特定應(yīng)用流向網(wǎng)絡(luò)請(qǐng)求一定的服務(wù)質(zhì)量(QoS5,它也被路由器用來在節(jié)點(diǎn)間傳送這種服務(wù)質(zhì)量請(qǐng)求,從而建立能提供特定服務(wù)質(zhì)量的狀態(tài),并維護(hù)這種狀態(tài)。資源預(yù)留協(xié)議最終將在數(shù)據(jù)流的路

2、徑上預(yù)留相應(yīng)的資源(主要包括內(nèi)存資源和CPU資源。實(shí)時(shí)流協(xié)議RTSP是由Real Networks和Netscape共同提出的,該協(xié)議定義了一對(duì)多應(yīng)用程序如何有效地通過IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù)。RTSP在體系結(jié)構(gòu)上位于RTP和RTCP之上,它使用TCP或RTP完成數(shù)據(jù)傳輸。與HTTP相比,HTTP傳送HTML,而RTP傳送的是多媒體數(shù)據(jù)。HTTP請(qǐng)求由客戶機(jī)發(fā)出,服務(wù)器響應(yīng)請(qǐng)求;使用RTSP時(shí),客戶機(jī)和服務(wù)器都可以發(fā)出請(qǐng)求,即RTSP可以是雙向的。RTP被定義為在一對(duì)一或一對(duì)多傳輸?shù)那闆r下工作,其目的是提供時(shí)間信息和實(shí)現(xiàn)流同步。RTP通常使用UDP來傳送數(shù)據(jù),它本身并不能為按順序傳送數(shù)據(jù)包提供可

3、靠的傳送機(jī)制,也不提供流量控制或擁塞控制,它依靠RTCP提供這些服務(wù)。RTCP和RTP一起提供流量控制和擁塞控制服務(wù),它們配合使用,能夠以有效的反饋和最小的開銷使傳輸效率最佳化,因而特別適合傳送網(wǎng)上的實(shí)時(shí)數(shù)據(jù)。流媒體協(xié)議棧如下圖所示: 圖1流媒體協(xié)議棧”Fig. 1 Streaming video protocol stack在發(fā)送方的數(shù)據(jù)面,壓縮且經(jīng)過ASF編碼的視頻數(shù)據(jù)被讀出并在RTP/RTCP/RTSP層上打包,提供定時(shí)和同步信息以及包的序列號(hào)。然后把這些打包的RTP數(shù)據(jù)流發(fā)送到UDP/TCP 層和IP層,得到的IP包在網(wǎng)絡(luò)上傳輸。在接收方則按照相反的方向處理。在控制面,RTCP 包和R

4、TSP包在UDP/TCP層上復(fù)用,并且被送到IP層,以便通過網(wǎng)絡(luò)傳輸41. 1、RTP協(xié)議 圖2 RTP頭格式5Fig. 2 RTP head format頭12個(gè)字節(jié)在每個(gè)RTP包中都有,而CSRC標(biāo)識(shí)列表僅在有混合器插入的時(shí)候才有。各段具體意義如下:1.版本(V: 2bitRTP版本信息。目前版本是2。 (RTP第一版草案是版本1,最初應(yīng)用在“vat"音頻工具中的是第0版2.填充位(P: l bit如果填充位置1,末尾有一個(gè)或者多個(gè)附加的非有效載荷的填充字節(jié)。填充的最后一個(gè)字節(jié)是該忽略的填充數(shù)目,包括本身所占一個(gè)字節(jié)。填充在按照固定塊大小加密的加密算法中或者在低層的協(xié)議數(shù)據(jù)單元中

5、裝載幾個(gè)RTP包時(shí)可能需要。3.擴(kuò)展位(X: lbit如果擴(kuò)展位置1,固定頭后必須跟了一個(gè)頭擴(kuò)展。4. CSRC計(jì)數(shù)(CO: ObitCSRC計(jì)數(shù)包含了緊跟在固定頭后的CSRC標(biāo)識(shí)符的個(gè)數(shù)。5.標(biāo)記(M : 1 bit在序言中定義了該標(biāo)記的具體解釋,目的是允許重要事件在包流中標(biāo)記l止來。序言可以定義附加的標(biāo)記位,或者通過改變有效載荷類型域中的數(shù)據(jù)位來指示沒有標(biāo)記位。6.有效載荷類型(PT : 7bit定義RTP有效載荷的格式,通過應(yīng)用程序定義具體的說明。序言可以指定和有效載荷格式相對(duì)應(yīng)的有效載荷碼的默認(rèn)靜態(tài)影像碼。附加的有效載荷碼可以通過非RTP方式動(dòng)態(tài)定義。在RFC 3551中定義了一系列音

6、頻和視頻的默認(rèn)映射初集。會(huì)話中,RTP元可以修改有效載荷的類型,但是該域不能用于復(fù)用單獨(dú)的媒體流。對(duì)于有效載荷類型無法識(shí)別的數(shù)據(jù)包,接收方一律忽略。7.序列號(hào)(Sequence Number : 16bit每發(fā)送一個(gè)RTP數(shù)據(jù)包序列號(hào)就增加1,這樣接收方可以檢測到數(shù)據(jù)包的丟失重新保存包序列。序列號(hào)的初始值是隨機(jī)的,這樣可以加大被人竊取攻擊的難度。8.時(shí)間戳(Timestamp : 32bit時(shí)間戳反映了RTP數(shù)據(jù)包的第一個(gè)字節(jié)的采樣信息。采樣信息由單調(diào)、線性的時(shí)鐘導(dǎo)出,允許同步與抖動(dòng)時(shí)間計(jì)算。時(shí)鐘必須有足夠分辨率,滿足所需同步和測定包到達(dá)抖動(dòng)精度。時(shí)鐘頻率依靠有效載荷中裝載的數(shù)據(jù)的格式,在序言

7、中或者定義格式的有效載荷格式說明中靜態(tài)定義,或者也可以通過非RTP方式動(dòng)態(tài)定義有效載荷的格式。如果RTP包是周期生成的,名義上的采樣信息就通過采樣時(shí)鐘決定,而不是讀一次系統(tǒng)時(shí)鐘。例如,對(duì)于固定速率的音頻每個(gè)采樣周期時(shí)間戳就增加一。如果音頻應(yīng)用程序讀一次覆蓋了輸入設(shè)備的160個(gè)采樣周期,每讀一塊這樣的數(shù)據(jù)塊,時(shí)間戳就增加160,而不管這一塊是在一個(gè)包中傳輸還是被丟棄了。像序列號(hào)一樣,時(shí)間戳的初始值也應(yīng)該是隨機(jī)的。如果幾個(gè)連續(xù)的RTP包在邏輯上是同時(shí)生成的就具有相同的時(shí)間戳,比如同一個(gè)視頻幀。如果數(shù)據(jù)不是以采集順序發(fā)送,像MPEG插入的視頻幀,連續(xù)RTP包包含的時(shí)間戳可能不是單調(diào)的。源自不同的媒體

8、流的RTP時(shí)間戳可能以不同的速率,單獨(dú)的隨機(jī)的偏移步進(jìn)。因此,盡管由這些時(shí)間戳就足以重建一個(gè)單獨(dú)流的時(shí)間,直接比較從不同的媒體源的RTP時(shí)間戮對(duì)于同步來說效率不高。相反,對(duì)于每個(gè)媒體RTP時(shí)間戮和采樣間隔是通過參考的時(shí)鐘配對(duì)關(guān)聯(lián)起來的,這個(gè)參考時(shí)鐘代表了和RTP時(shí)間戮相對(duì)應(yīng)的數(shù)據(jù)的采樣時(shí)間。所有的媒體都共享參考時(shí)鐘來達(dá)到同步。不是每個(gè)數(shù)據(jù)包中都傳輸了時(shí)間戮配對(duì)信息,而是在更低速率的RTCP SR包中傳輸。采樣間隔(instant的選擇目的是RTP時(shí)間戳的參考,因?yàn)橐阎獋鬏敹它c(diǎn)對(duì)于所有的媒體信息是一個(gè)通常的定義,獨(dú)立于編碼延遲或者其他處理。目的是允許所有的媒體的同步描述都在同一時(shí)刻采樣。9. S

9、SRC: 32bitSSRC段定義了同步源。標(biāo)識(shí)應(yīng)該是隨機(jī)選擇的,防止在同一個(gè)RTP會(huì)話中有兩個(gè)同名的同步源。盡管多個(gè)源選擇相同的標(biāo)識(shí)的可能性是很低的,所有的RTP實(shí)現(xiàn)都必須具有檢測和防止碰撞機(jī)制。如果源改變了源傳輸?shù)刂?就必須選擇一個(gè)新的SSRC標(biāo)識(shí)防止被解釋為循環(huán)源。10. CSRC列表:0到15項(xiàng),每個(gè)項(xiàng)都32bitCSRC列表定義了該包中的有效載荷的所有源的標(biāo)識(shí)。CC域給出標(biāo)識(shí)的數(shù)量。如果有多于15個(gè)作用源(contributing source,只能標(biāo)識(shí)出其中的15個(gè)。CSRC標(biāo)識(shí)由混合器(mixer加入,使用作用源的SSRC標(biāo)識(shí)。例如,對(duì)于音頻包來說所有的被混合生成一個(gè)包的SSRC

10、 都被列出來了。為了使協(xié)議有效運(yùn)行,應(yīng)該降低復(fù)用點(diǎn)的數(shù)量,正像集合層處理設(shè)計(jì)規(guī)則(10描述的那樣。在RTP中,復(fù)用是由多個(gè)目標(biāo)傳輸?shù)刂诽峁?網(wǎng)址和端口號(hào),每個(gè)RTP會(huì)話都有不同的傳輸?shù)刂?。例?有單獨(dú)編碼的音頻和視頻媒體組成的遠(yuǎn)程電信會(huì)議中,每個(gè)媒體都用單獨(dú)的RTP會(huì)話來攜帶,而且有自己的目標(biāo)傳輸?shù)刂贰为?dú)的音頻和視頻數(shù)據(jù)流不能用相同的RTP會(huì)話攜帶,分解復(fù)用是基于有效載荷類型或者SSRC載荷類型的?，F(xiàn)在的RTP數(shù)據(jù)包的頭完全符合所有的RTP可能支持的應(yīng)用程序類型的通用功能。然而,為了和ALF設(shè)計(jì)規(guī)則相一致,頭可以在允許序言獨(dú)立監(jiān)視和記錄工具的情況下,通過修改或者在序言說明中適當(dāng)?shù)母郊有畔⑦M(jìn)行

11、功能裁減。標(biāo)記位和有效載荷類型域含有序言說明信息,但是它們是放在固定頭里的,因?yàn)楹芏鄳?yīng)用程序都要用著它們,不然的話就不得不為了裝載它們而附加另外32bit字。含有這些域的字節(jié)可以在序言中重新定義來滿足不同的需要,例如更多或者更少的標(biāo)記位。如果有標(biāo)識(shí)位,其中的一位必須放到這個(gè)字節(jié)的最高位,因?yàn)楠?dú)立于序言的監(jiān)視器可能能夠檢測出包損失格式和標(biāo)識(shí)位的關(guān)系。特定有效載荷格式的附加信息,例如編碼,應(yīng)該放在包的有效載荷段中?？梢苑旁谟行лd荷段起始的頭里,也可以用數(shù)據(jù)格式的一個(gè)保留值來指示。如果特定類型的應(yīng)用程序需要獨(dú)立于有效載荷格式的附加功能,那些應(yīng)用程序運(yùn)行所符合的序言應(yīng)該在現(xiàn)存的頭的緊跟SSRC域后附加

12、固定域。這些程序能夠迅速直接訪問附加域,而獨(dú)立于序言的監(jiān)視器或者記錄器也能通過解析頭12個(gè)字節(jié)信息就處理RTP包。如果在所有的序言中都附加了相同的附加功能,就要定義一個(gè)新版本的RTP,在固定頭域中作永久性修改。1. 1. 4 RTP頭擴(kuò)展注意只在有限的使用范圍內(nèi)要求頭擴(kuò)展。使用這個(gè)機(jī)制最好通過另外的方式實(shí)現(xiàn),使用前段描述的方法。例如,給固定頭的序言說明擴(kuò)展處理起來就更加廉價(jià),因?yàn)榧炔皇怯袟l件的也不是可變的位置。特定有效載荷格式的附加信息不應(yīng)該使用頭擴(kuò)展,但是應(yīng)該在包的有效載荷段中攜帶。如果RTP頭的X位為1,在RTP頭中必須追加可變長度的頭擴(kuò)展,如果CSRC列表存在就緊跟其后。頭擴(kuò)展中包含了1

13、6bit長度域,存放的是擴(kuò)展中的32bit長度字的數(shù)量,不包括四字節(jié)的擴(kuò)展頭(因此0也是有效長度。只有一個(gè)單獨(dú)的擴(kuò)展能夠追加到RTP數(shù)據(jù)頭后。為了允許每個(gè)協(xié)調(diào)工作的多個(gè)互相作用的實(shí)現(xiàn)和不同的頭擴(kuò)展相獨(dú)立,或者允許某一特定執(zhí)行能夠和多于一個(gè)類型的頭擴(kuò)展協(xié)調(diào)工作,頭擴(kuò)展的頭16bit數(shù)據(jù)用于區(qū)分標(biāo)識(shí)或者參數(shù)。這16bit數(shù)據(jù)的格式定義符合實(shí)現(xiàn)所遵守的序言說明。RTP說明不定義任何頭擴(kuò)展本身。 圖3 RTP頭擴(kuò)展Fig. 3 RTP head extension1.2、RTP控制協(xié)議一RTCPRTP控制協(xié)議(RTCP將控制包周期發(fā)送給所有連接者,應(yīng)用與數(shù)據(jù)包相同的分布機(jī)制。下層的協(xié)議必須提供數(shù)據(jù)包和

14、控制包的復(fù)用,例如使用單獨(dú)的UDP端口號(hào)。RTCP具有四個(gè)功能:第一個(gè)功能是提供數(shù)據(jù)發(fā)布的質(zhì)量反饋aRTCP是作為RTP傳輸協(xié)議的一部分,與其他傳輸協(xié)議的流和阻塞控制有關(guān)。反饋對(duì)自適應(yīng)編碼控制直接起作用,但I(xiàn)P多播經(jīng)驗(yàn)表明,從發(fā)送者收到反饋對(duì)診斷發(fā)送錯(cuò)誤是至關(guān)重要的。給所有參與者發(fā)送接收反饋報(bào)告允許問題觀察者估計(jì)哪些問題是局部的,哪些是全局的。諸如IP多播等發(fā)布機(jī)制使網(wǎng)絡(luò)服務(wù)提供商類團(tuán)體可能接收反饋信息,充當(dāng)?shù)谌奖O(jiān)控者來診斷網(wǎng)絡(luò)問題。反饋功能由RTCP發(fā)送者和接收者報(bào)告執(zhí)行。第二個(gè)功能是RTCP攜帶了一個(gè)RTP源永久傳輸層標(biāo)識(shí),即規(guī)范名字或者CNAME。如果發(fā)現(xiàn)了沖突或者程序重新啟動(dòng)SSRC

15、就會(huì)改變,接收方需要CNAME跟蹤每個(gè)參與者。接收方也需要有CNAME來從一系列相關(guān)的RTP會(huì)話中把多個(gè)給定的參與者的多個(gè)數(shù)據(jù)流聯(lián)合起來,例如把音頻和視頻數(shù)據(jù)同步起來。媒體內(nèi)部的同步也要求數(shù)據(jù)發(fā)送方的RTCP包中包含的NTP和RTP時(shí)間戳。前兩個(gè)功能要求所有的參與者都發(fā)送RTCP數(shù)據(jù)包,因此必須控制速率來適應(yīng)大量的參與者。通過每個(gè)參與者都把自己的控制包發(fā)送給所有的參與者,每個(gè)都能獨(dú)立的觀察參與者的數(shù)目。這個(gè)數(shù)目用于計(jì)算數(shù)據(jù)包發(fā)送的速率。第4個(gè)可選功能是傳達(dá)最小的會(huì)話控制信息,例如在用戶接口處顯示參與者身份。這在“松控制”會(huì)話中最有用,這類會(huì)話中參與者進(jìn)入或離開而不需要成員控制或者參數(shù)信息。RT

16、CP提供到達(dá)所有參與者的一個(gè)方便的渠道,但是并不要求支持應(yīng)用程序的所有控制通信要求。可能需要更高層的會(huì)話控制協(xié)議,但是已經(jīng)超過了本文探討的范圍。頭三個(gè)功能應(yīng)該用于所有的環(huán)境中,尤其在IP多播的情況下。RTP應(yīng)用程序設(shè)計(jì)者應(yīng)該避免只能在單播的情況下工作的機(jī)制,也不能適應(yīng)更大的數(shù)量。RTCP傳輸可以為發(fā)送方和接收方單獨(dú)控制,例如接收方無法接收到反饋的單向連接中。1 .2. 1、RTCP包格式下面定義了幾個(gè)攜帶變化的控制信息的RTCP包類型:SR:發(fā)送方報(bào)告,源于活動(dòng)發(fā)送方參與者的用于傳輸和接收統(tǒng)計(jì)。RR:接收方報(bào)告,源于非活動(dòng)發(fā)送方的參與者用于接收統(tǒng)計(jì),和SR組合起來用于活動(dòng)發(fā)送者報(bào)告多于31個(gè)源

17、。SDES:源描述項(xiàng),包括CNAME。BYE:顯示參與中止。APP:應(yīng)用程序特定功能。和RTP數(shù)據(jù)包中的內(nèi)容類似,每個(gè)RTCP包都以固定的部分開頭,之后緊跟和包類型有關(guān)的長度可能變化的結(jié)構(gòu)化的元素,但是必須以32bit為邊界結(jié)束。包含了排列要求和每個(gè)包中的固定部分內(nèi)的長度域使RTCP包“可堆疊的”。多個(gè)RTCP包不用插入分隔部分就可直接連接到一起形成一個(gè)復(fù)合RTCP包,這個(gè)復(fù)合的RTCP包在低層的協(xié)議中用一個(gè)單獨(dú)的包發(fā)送出去,如UDP。在復(fù)合包中沒有精確的RTCP包的數(shù)量,因?yàn)楦蛯訁f(xié)議只要提供整個(gè)長度就可以決定復(fù)合包的結(jié)束。復(fù)合包中的每個(gè)單獨(dú)的RTCP包都可以單獨(dú)處理而不依賴于組合包的順序或

18、者組合。然而,為了執(zhí)行協(xié)議的這些功能,必須滿足如下限制:*接收統(tǒng)計(jì)(SR或者RR中應(yīng)該經(jīng)常發(fā)送,只要帶寬允許,因此每個(gè)周期性的傳輸?shù)膹?fù)合RTCP包中必須包含有報(bào)告包。*新的接收者需要接收CNAME,并盡快識(shí)別源,并開始連接媒體進(jìn)行同步,所以每個(gè)復(fù)合RTCP包都必須包括SDES CNAME,除非復(fù)合RTCP包分割開用于部分加密。*出現(xiàn)在組合包前面的是包類型數(shù)量,其增長應(yīng)該受到限制,以提高常數(shù)位數(shù)量。因此,所有的RTCP包必須用至少有兩個(gè)單獨(dú)包的復(fù)合包傳輸,用如下格式:(1加密前綴(Encryption Prefix僅當(dāng)復(fù)合包被加密,才加上一個(gè)32位隨機(jī)數(shù)用于每個(gè)復(fù)合包發(fā)送。(2SR或RR:復(fù)合包

19、中的第一個(gè)RTCP包必須總是一個(gè)報(bào)告包,方便頭的確認(rèn)。即使沒有數(shù)據(jù)發(fā)送或者接收,也必須發(fā)送空的RR,哪怕復(fù)合包中的另一個(gè)RTCP包是BYE.(3附加RR:如果接收統(tǒng)計(jì)報(bào)告的源的數(shù)量超過了31,在初始報(bào)告包后面應(yīng)該附加RR包。(4SDES:每個(gè)復(fù)合RTCP包必須包含CNAME項(xiàng)的SDES包。其他源描述項(xiàng)可選,但受到帶寬制。(5BYE或者APP:其他的RTCP包類型可以任意順序排列,但是BYE應(yīng)作為最后一個(gè)包發(fā)送,包類型出現(xiàn)可以不止一次。建議轉(zhuǎn)換器(translator或者混合器(mixer從多個(gè)組合單個(gè)的RTCP包。如復(fù)合包整體長度超過了網(wǎng)絡(luò)路徑最大傳輸單元,可以分成多個(gè)較短組合包用低層協(xié)議以單

20、個(gè)包形式發(fā)送。注意,每個(gè)復(fù)合包必須以SR或者RR包開始。附加RTCP包類型可在Internet Assigned Numbers Authority (IANA處注冊。注意每個(gè)復(fù)合包都必須用SR或者RR包開始。程序要能夠忽略接收到的RTCP包中無法識(shí)別類型的包。RTP接收方使用RTCP報(bào)告包提供接收質(zhì)量反饋,報(bào)告包根據(jù)接收方是否是發(fā)送者而采用兩種格式中的一種。除包類型代碼外,發(fā)送者報(bào)告與接收方報(bào)告間唯一的差別是發(fā)送方報(bào)告包含一個(gè)20個(gè)字節(jié)發(fā)送方信息段。如某地址在發(fā)出最后或前一個(gè)報(bào)告間隔期間發(fā)送數(shù)據(jù)包,就發(fā)布SR;否則,就發(fā)出RR; SR和RR都可沒有或包括多個(gè)接收?qǐng)?bào)告塊。發(fā)布報(bào)告不是為列在CS

21、RC列表上的起作用的源,每個(gè)接收?qǐng)?bào)告塊提供從特殊源接收數(shù)據(jù)的統(tǒng)計(jì)。既然最大可有31個(gè)接收?qǐng)?bào)告塊嵌入在SR或RR包中,附加RR包可堆疊在初始SR或RR包之后。發(fā)送方報(bào)告包由3部分組成,也可能還有第四個(gè)特定設(shè)置擴(kuò)展部分。第一部分為頭,8個(gè)字節(jié)長,包括了版本(V、填充位(P、接收?qǐng)?bào)告計(jì)數(shù)(RC,包類型(PT、長度、同步源標(biāo)識(shí)(SSRC等信息。第二部分為發(fā)送方信息,20個(gè)字節(jié),出現(xiàn)在每個(gè)發(fā)送方報(bào)告包中。包括了NTP時(shí)間戳、RTP時(shí)間戳、發(fā)送方包計(jì)數(shù)、發(fā)送方字節(jié)計(jì)數(shù)等信息。第三部分包括接收?qǐng)?bào)告塊,大小與自最后一個(gè)報(bào)告來發(fā)送方監(jiān)聽的其他源數(shù)量有關(guān)。每個(gè)接收?qǐng)?bào)告塊傳輸單個(gè)同步源接收RTP包的統(tǒng)計(jì)。發(fā)生沖突,

22、當(dāng)源改變SSRC標(biāo)識(shí)時(shí),接收方并不繼續(xù)統(tǒng)計(jì)。這些統(tǒng)計(jì)包括:SSRC n(源標(biāo)識(shí)、丟失部分、丟失包累積數(shù)、收到已擴(kuò)展的最高系列號(hào)、時(shí)間抖動(dòng)、最后SR時(shí)間戳(LSR ,自最后一個(gè)SR來的延遲(DLSR統(tǒng)計(jì)。SDES包為三層結(jié)構(gòu),由頭與數(shù)據(jù)塊組成,數(shù)據(jù)塊可以沒有,也可以有多個(gè),組成項(xiàng)描述塊所表明的源。項(xiàng)描述如下:1.版本(V、填充(P、長度:如SR包中所描述。2.包類型(PT :8bit,包含常數(shù)202,區(qū)別RTCP SDES包。3.源計(jì)數(shù)(SC:Sbit,包含在SDES包中的SSRC/CSRC塊數(shù)量,零值有效,但沒有意義。4.源描述項(xiàng)內(nèi)容包括:CNAME, NAME, E-mail, PHONE,

23、 LOC, TOOL,NOTE, PRIV。1 CNAME:規(guī)范終端標(biāo)識(shí)SDES項(xiàng)。2 NAME:用戶名稱SDES項(xiàng)。3 E-mail:電子郵件地址SDES項(xiàng)。4 PHONE:電話號(hào)碼SDES項(xiàng)。5 LOC:用戶地理位置SDES項(xiàng)。6 TOOL:應(yīng)用或工具名稱SDES項(xiàng)。7 NOTE:通知/狀態(tài)SDES項(xiàng)。8 PRIV:專用擴(kuò)展SDES項(xiàng)。1. 2. 4、 BYE:斷開RTCP包如混合器接收到一個(gè)BYE包,混合器轉(zhuǎn)發(fā)BYE包,而不改變SSRC/CSRC標(biāo)識(shí)。如混合器關(guān)閉,它也應(yīng)該發(fā)出一個(gè)BYE包,列出它所處理的所有源,而不只是自己的SSRC標(biāo)識(shí)。作為可選項(xiàng),BYE包可包括一個(gè)8bit的字節(jié)計(jì)數(shù)

24、,后跟很多字節(jié)文本,標(biāo)識(shí)離開原因,如:"camera malfunction”或“RTP loop detected".字符串具有同樣的編碼,如在SDES中所描述的。如字符串填充包至下32bit邊界,字符串就不以空結(jié)尾;否則,BYE包以空字節(jié)填充。1. 2. 5、APP:定義應(yīng)用的RTCP包APP包用于開發(fā)新應(yīng)用和新特征的實(shí)驗(yàn),不要求注冊包類型值。帶有不可識(shí)別名稱的APP包應(yīng)被忽略掉。測試后,如確定應(yīng)用廣泛,推薦重新定義每個(gè)APP包,而不用向IANA 注冊子類型和名稱段。1.3、RTSP協(xié)議61.目的:實(shí)時(shí)流協(xié)議(RTSP建立并控制一個(gè)或者多個(gè)時(shí)間同步連續(xù)媒體流,如視頻和音

25、頻。盡管連續(xù)媒體流與控制流可以交叉,通常它不直接傳輸連續(xù)流本身。換句話說,RTSP是多媒體服務(wù)器的“網(wǎng)絡(luò)遠(yuǎn)程控制”。TCP可以綁定到傳輸層連接上,而RTSP會(huì)話無法綁定到傳輸層連接上。RTSP會(huì)話期間,RTSP用戶可以打開和關(guān)閉很多連接到服務(wù)器的可靠傳輸來發(fā)出RTSP請(qǐng)求。此外,它可以使用無連接傳輸協(xié)議,比如UDP 。RTSP流控制的流可能使用到RTP協(xié)議,但是RTSP操作不依賴于用來傳輸連續(xù)媒體的傳輸機(jī)制。這個(gè)協(xié)議在語法和操作方面類似于HTTP/1.1,以至于擴(kuò)展的HTTP機(jī)制也可以被加入到RTSP中。這個(gè)協(xié)議支持如下操作:從媒體服務(wù)器恢復(fù)媒體:用戶可以通過HTTP或者別的方式請(qǐng)求一個(gè)演示描

26、述。如果演示正在多播,演示描述符包含了多播地址和傳輸連續(xù)媒體的端口。如果演示是通過單播傳輸給用戶的,用戶提供安全目的地地址。邀請(qǐng)媒體服務(wù)器加入到會(huì)議中:媒體服務(wù)器可以被“邀請(qǐng)”來參加正進(jìn)行的會(huì)議,或回放媒體,或記錄其中一部分或全部。這個(gè)模式對(duì)分布式的教學(xué)應(yīng)用方面很有用。會(huì)議中的幾個(gè)組可以輪流“按下遠(yuǎn)程控制按鈕”。把媒體加入到現(xiàn)成的講座中:如果服務(wù)器可以告訴用戶可以獲得的附加媒體內(nèi)容,在直播講座方面尤其有用。RTSP 請(qǐng)求可以用代理,管道,緩存處理,正像HTTP/ 1.1中那樣。2. RTSP特性RTSP有如下特性:可擴(kuò)展性、解析簡單、安全、傳輸獨(dú)立、流控制和會(huì)議初始化分離、適合專業(yè)應(yīng)用、友好的

27、代理和防火墻、友好的HTTP等。更早一點(diǎn)的RTSP要求可以多用戶。然而后來人們決定最好的辦法是協(xié)議能夠很容易地?cái)U(kuò)展到多用戶。流標(biāo)識(shí)符可以被幾個(gè)控制流共同使用,以至于“通過遠(yuǎn)程”可以成為可能。協(xié)議不能指定幾個(gè)用戶怎樣互相訪問。3.和其他協(xié)議的關(guān)系RTSP在性能方面和HTTP有些重疊。和HTTP相互作用體現(xiàn)在與流內(nèi)容的初始接觸是通過web頁的。目前的協(xié)議說明目的在于允許在WEB服務(wù)器和媒體服務(wù)器之間存在不同傳輸點(diǎn)。比如,演示描述符可以用HTTP或者RTSP獲得,這降低了瀏覽器的往返傳遞,也允許獨(dú)立RTSP服務(wù)器與用戶不全依靠HTTP 。然而,RTSP在另一種協(xié)議下數(shù)據(jù)傳輸超過帶寬方面和HTTP有基

28、礎(chǔ)性的不同。HTTP 是一個(gè)不對(duì)稱協(xié)議,用戶發(fā)出請(qǐng)求,服務(wù)器響應(yīng)。在RTSP中,媒體用戶和服務(wù)器都能夠發(fā)出請(qǐng)求,RTSP請(qǐng)求是無序的,請(qǐng)求收到之后還可以設(shè)置參數(shù)和控制媒體流。重新使用HTTP功能在至少兩個(gè)方面有優(yōu)勢,即安全和代理。請(qǐng)求很類似,所以使HTTP 能夠工作在緩存、代理和鑒權(quán)方面是很有價(jià)值的。很多實(shí)時(shí)媒體傳輸協(xié)議使用RTP,但是RTSP不是綁到RTP上的。RTP假設(shè)演示描述符格式存在包括幾個(gè)媒體流,這些演示描述符格式能表達(dá)靜態(tài)和暫時(shí)的演示特性。1.RTSP版本(H3.1采用,用RTSP代替HTTP o2. RTSP URLrtsp命令通過可靠協(xié)議(Internet中用TCP處理,而rt

29、spu命令使用不可靠協(xié)議處理(Internet網(wǎng)中使用UDP o如果端口554沒有被使用,默認(rèn)情況下使用端口554。服務(wù)器端在主機(jī)的這個(gè)端口監(jiān)聽TCP (rtsp或者UDP(rtspu來控制唯一的資源用RTSP協(xié)議,資源的請(qǐng)求URI是rtsp URL a 在URL中應(yīng)該避免直接使用IP。3.會(huì)議標(biāo)識(shí)會(huì)議標(biāo)識(shí)對(duì)RTSP來說是模糊的,采用標(biāo)準(zhǔn)URI編碼方法編碼,可包含任何字節(jié)數(shù)值。會(huì)議標(biāo)識(shí)必須全局唯一。4.連接標(biāo)識(shí)連接標(biāo)識(shí)是長度不確定的字符串,必須隨機(jī)選擇,至少要8個(gè)字節(jié)長,使它很難能被猜測出。5. SMPTE相關(guān)時(shí)間戳SMPTE相關(guān)時(shí)間戳標(biāo)識(shí)相對(duì)剪輯開始的時(shí)間,相關(guān)時(shí)間戳表示成SMPTE時(shí)間代碼

30、,精確到幀級(jí)。時(shí)間代碼格式為小時(shí):分鐘:秒:幀。缺省SMPTE格式是"SMPTE 30",幀速率為每秒29.97幀。其他SMPTE代碼可選擇使用SMPTE時(shí)間獲得支持(如“SMPTE 25"。時(shí)間數(shù)值中幀段值可從0到29。順便指出30幀每秒和29.97幀每秒的區(qū)別:30幀每秒的視頻幀序列中丟棄每分鐘的起始兩幀,除了時(shí)間是10分鐘的整數(shù)倍的那些分鐘,就變成了29.97幀每秒了。6.正常播放時(shí)間正常播放時(shí)間(NPT標(biāo)識(shí)相對(duì)演示開始的流絕對(duì)位置。時(shí)間戳由十進(jìn)制分?jǐn)?shù)組成。左邊部分用秒或小時(shí)、分鐘、秒表示;小數(shù)點(diǎn)右邊部分表示秒的部分。演示的開始對(duì)應(yīng)0.0上, NPT是聯(lián)系觀

31、看者與程序的時(shí)鐘,通常以數(shù)字式顯示在VCR上。7.絕對(duì)時(shí)間絕對(duì)時(shí)間表示成IS08601時(shí)間戳,采用UTC (GMT.8.可選標(biāo)簽可選標(biāo)簽是用于指定RTSP新可選項(xiàng)的唯一標(biāo)記。這些標(biāo)記用在請(qǐng)求和代理一請(qǐng)求頭段。當(dāng)?shù)怯浶翿TSP選項(xiàng)時(shí),需提供下列信息:(1名稱和描述選項(xiàng)。名稱長度不限,但應(yīng)該不多于20個(gè)字符。名稱不能包括空格、控制字符。(2表明誰改變選項(xiàng)的控制。如IETF, ISO, ITU-T,或其他的國際標(biāo)準(zhǔn)團(tuán)體、聯(lián)盟或公司。(3深入描述的參考,如RFC、論文、專利、技術(shù)報(bào)告、文檔源碼和計(jì)算機(jī)手冊。(4對(duì)專用選項(xiàng),附上聯(lián)系方式。RTSP是基于文本的協(xié)議,使用ISO 10646字符集UTF-8編

32、碼(RFC 2279方案。RTCP 也使用ISO 10646編碼方式。如果消息中有消息體,消息體的長度按照如下方法確定(按照優(yōu)先權(quán)順序:1.沒有消息體的任何回應(yīng)信息(如lxx, 204和304回應(yīng)信息,總是在頭域后緊跟一個(gè)空行來結(jié)束消息,不管消息中的實(shí)體頭域。(注意:空行僅僅包含CRLF回車換行。2.如果內(nèi)容長度頭域存在,以字節(jié)為單位的數(shù)值代表消息體的長度。如果頭域不存在,這個(gè)數(shù)值為Oo3.服務(wù)器關(guān)閉連接的時(shí)候。(關(guān)閉連接不意味著請(qǐng)求體的結(jié)束,因?yàn)槟菢拥脑挿?wù)器將不可能發(fā)回一個(gè)回應(yīng)信息。如果合適長度的演示描述符返回,服務(wù)器應(yīng)該能夠知道它的長度,盡管它是動(dòng)態(tài)生成的,使大塊傳輸編碼不必要。盡管如果

33、有實(shí)體內(nèi)容長度必須存在,盡管長度沒有明確給出,這個(gè)規(guī)則保證了合理的行為。如不受請(qǐng)求方法或響應(yīng)狀態(tài)編碼限制,請(qǐng)求和響應(yīng)信息可傳輸實(shí)體,實(shí)體由實(shí)體頭文件和實(shí)體體組成,有些響應(yīng)僅包括實(shí)體頭。在此,根據(jù)誰發(fā)送實(shí)體、誰接收實(shí)體,發(fā)送者和接收者可分別指用戶和服務(wù)器。實(shí)體頭定義實(shí)體體可選元信息,如沒有實(shí)體體,指請(qǐng)求標(biāo)識(shí)的資源。擴(kuò)展頭機(jī)制允許定義附加實(shí)體頭段,而不用改變協(xié)議,但這些段不能假定。RTSP請(qǐng)求可以用幾種不同的方式傳輸出去:幾個(gè)請(qǐng)求一一回應(yīng)模式的永久的傳輸連接每個(gè)請(qǐng)求/回應(yīng)模式的連接無連接模式傳輸連接的類型用RTSP的URI定義。對(duì)于“rtsp",就假設(shè)永久連接,然而“rtspu”請(qǐng)求在發(fā)

34、送數(shù)據(jù)的時(shí)候就不建立連接。不像HTTP, RTSP允許媒體服務(wù)器給媒體用戶發(fā)送請(qǐng)求。然而,只是在永久連接的情況下才支持,因?yàn)椴蝗坏脑捗襟w服務(wù)器就沒有可靠的到達(dá)用戶的方式。而且,這是從媒體服務(wù)器發(fā)給用戶的請(qǐng)求穿過防火墻的唯一方式。如果可靠傳輸協(xié)議用于攜帶RTSP,請(qǐng)求必須不能重新傳輸;RTSP應(yīng)用必須依靠下層的傳輸來提供可靠性。如果下層的可靠傳輸(如TCP和RTSP應(yīng)用程序重新傳輸請(qǐng)求,可能每個(gè)包丟了兩次重新傳輸?shù)慕Y(jié)果。接收者不能典型的應(yīng)用層重傳,因?yàn)閭鬏敹褩２荒茉诘谝淮握?qǐng)求到達(dá)接收者之前重新傳輸。如果丟包是由于擁塞引起,不同層的多重傳會(huì)加劇擁塞。如果RTSP用在小RTT局域網(wǎng)中,標(biāo)準(zhǔn)的程序?qū)?yōu)化初始TCP RTT估值是很有用的。時(shí)間戳頭用于防止重傳含糊問題,排除了Karn的算法的需要。每個(gè)請(qǐng)求都有一個(gè)序列號(hào)在Cseq頭中,每個(gè)不同的請(qǐng)求傳輸后都自動(dòng)加1。如果請(qǐng)求由于缺少確認(rèn)信息而重復(fù),請(qǐng)求必須使用的一直都是最初的序列號(hào)(也就是序列號(hào)不遞增。采用RTSP的系統(tǒng)必須支持在TCP上傳輸RTSP,也可能支持UDP