|
rtp，實時協(xié)議被用來為應(yīng)用程序如音頻，視頻等的實時數(shù)據(jù)的傳輸提供端到端（end to end）的網(wǎng)絡(luò)傳輸功能。傳輸?shù)哪Ｐ涂梢允菃吸c傳送或是多點傳送。數(shù)據(jù)傳輸被一個姐妹協(xié)議——實時控制協(xié)議（rtcp）來監(jiān)控，后者允許在一個大的多點傳送網(wǎng)絡(luò)上監(jiān)視數(shù)據(jù)傳送，并且提供最小限度的控制和識別功能。 rtp是被ietf在rfc1889中提出來的。順帶提及，rtp已經(jīng)被接受為實時多媒體傳送的通用標(biāo)準(zhǔn)。itu-t跟ietf都在各自的系統(tǒng)中將這一協(xié)議標(biāo)準(zhǔn)化。 1.1 為何需要rtp? tcp不能支持像交互視頻，會議等的實時服務(wù)，這一原因是由于tcp只是一個“慢”協(xié)議，需要三次握手。就此在ip層上udp是一個比tcp更好的選擇。但是udp是本質(zhì)上是一個不可靠協(xié)議，不支持在包丟情況下的重傳機制。誠然，udp有一些特性，比如多路復(fù)用跟校驗和服務(wù)，這些都是對實時服務(wù)很有利的。為了消除udp的缺點，rtp是作為應(yīng)用層而被提出來的。 rtp提供的各種服務(wù)包括有效負載識別，序列編號，時間戳和投遞監(jiān)聽。rtp能夠序列化包，當(dāng)這些包在收端不是按順序到達的時。序列號也能被用來識別包丟失。時間戳被用于媒體有效的播放。到達的數(shù)據(jù)一直被rtcp監(jiān)聽，以通知rtp層來校正其編碼和傳輸?shù)膮?shù)。例如，如果rtcp層檢測到包丟失，它會通知rtp層減緩發(fā)送速率。 盡管rtp有助于實時媒體的有效的播放 ，但是要注意的是rtp自身并不提供任何機制來確保及時傳遞或提供其他服務(wù)質(zhì)量（qos）的保證，而是依靠低層服務(wù)來完成這些。同樣，rtp也不保證投遞或防止無序投遞。rtp被設(shè)計出來主要是為了滿足有多個參加者的多媒體會議的需要。rtp也同樣適合于象持續(xù)數(shù)據(jù)的儲存，分布式應(yīng)用 交互仿真，主動標(biāo)記以及應(yīng)用程序的控制和測量。 1.2 rtp特性一覽 rtp提供有效負荷類型識別，亂序重排和利用時間戳的媒體有效播放。 rtcp監(jiān)控服務(wù)質(zhì)量，也提供在一個當(dāng)前進行的會話中傳送關(guān)于參加者的信息作用。 rtp對于下層協(xié)議是獨立的，它能夠工作在像tcp/ip，atm，幀時延等類型的網(wǎng)絡(luò)上。 如果被下層網(wǎng)絡(luò)支持，rtp支持利用多路技術(shù)的對于多點的數(shù)據(jù)傳輸。 rtp序列號也能被用來確定包的合適位置。例如在視頻解碼，包無需按序解碼。 2.0 技術(shù)概覽 2.1 rtp rtp頭具有如下的格式。開始的12個八位字節(jié)在每一個rtp包中都會出現(xiàn)；而csrc標(biāo)識符列表只在通過混合器的包中出現(xiàn)。這些域含有以下意義：
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |v=2|p|x| cc |m| pt | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (ssrc) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (csrc) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
version (v) （版本號）: 這個域長度為2比特，標(biāo)出了rtp的最近版本。當(dāng)前的版本為2.0 padding (p) （填充）: 這個域長度為1比特，如果p被
此文來自: 馬開東博客 轉(zhuǎn)載請注明出處 網(wǎng)址： http://www. 置位，包在結(jié)尾處包含有一個或多個附加的填充字節(jié)，這些填充字節(jié)不是有效負荷的一部分。填充是一些需要固定塊大小的加密算法所要求的，或是為了在低層pdu搬運rtp包。extension (x): 這個域長度為1比特，如果被置位，固定的頭后面緊跟了一個頭的擴展。 csrc count (cc): 這個域長度為4比特。這個域表示了跟在固定頭后面的csrc標(biāo)識符的數(shù)目。 如前所述，這個域只有在通過一個混合器才有非零值。 marker bit (m): 這個域長度為1比特，如果m被置位，表示一些重要的項目如幀邊界在包中被標(biāo)記。例如，如果包中有幾個比特的當(dāng)前幀，連同前一幀，那么rtp的這一位就被置位。 payload type (pt) （有效負荷類型）: 這個域長度為7比特，pt指示的是有rtp包中的有效負荷的類型。rtp音頻視頻簡介(avp)包含了一個默認的有效負荷類型碼到有效負荷格式的映射。附加的有效負荷類型可以向iana注冊。 sequence number（序列號）： 這個域長度為16個比特，每送一個rtp包數(shù)目就增加一，初始值被設(shè)為一個隨機數(shù)。接收方不僅可以用這個序列號檢測包丟失，也可以重組包序列。 time stamp（時間戳）: 這個域長度為32個比特，時間戳反映了rtp數(shù)據(jù)包的頭一個字節(jié)的采樣時刻。 采樣時刻必須是由一個單調(diào)線性增加的時鐘產(chǎn)生，這樣做是為了接收方的同步和抖動計算。初始值必須為隨機數(shù)，這是為了避免對原碼的攻擊。例如，如果rtp源使用了一個編碼器， 緩沖20ms的音頻數(shù)據(jù)，那么rtp時間戳必須每個包增加160，無論包是被傳遞了還是被丟失了。 ssrc: 這個域長度為32比特，這個域表示了正在為會話產(chǎn)生rtp包的源。這個標(biāo)識符是隨機選中的，目的是為了避免同一個rtp會話中兩個源有相同的標(biāo)識符。 csrc list: 這個列表標(biāo)識了在這個包中對有效負荷起作用的所有源。標(biāo)識符的最大數(shù)目限定為15，這是由cc域所限定的（全零在cc域中是被禁止的）。如果有超過15個的分配源，只有前15個被標(biāo)識。 仔細觀察rtp可以注意到它不像更低層的協(xié)議比如pdu一樣，包含一個“定邊界”的域。 這一原因是rtp的有效負荷是跟ip的有效負荷相同，因此也就不需要了。 如果相同的用戶在一個會話中使用多個媒體，比如說視頻跟音頻，每個媒體都會打開單獨的rtp會話。因此在rtp層面上不存在多路復(fù)用。多路復(fù)用由更低層來決定。但是rtcp保留了一個叫cname的標(biāo)識符，這個標(biāo)識符對于由同一用戶初始化的媒體是相同的。因此cname是在rtp層面上能識別從一個用戶產(chǎn)生的不同媒體的唯一的標(biāo)識符。 從上可以看出，rtp頭的開銷是相當(dāng)大的，為了減少這一開銷，rtp頭壓縮被提了出來。 2.2 rtcp rtp接收者利用rtcp報告包，提供接收質(zhì)量的反饋。這個報告包可以是發(fā)送者類型也 此文來自: 馬開東博客 轉(zhuǎn)載請注明出處 網(wǎng)址： http://www. 可以是接收者類型。如果接收者主動參加到一個會話中，那么它就送sr（sender report），否則它將送rr（receiver report）。除sr跟rr包以外，rtcp還有其他的包類型：sdes （source description）, bye 和app（application defined）,rtcp和sdes包的有效負荷類型值在表1和表2中相應(yīng)給出。packet type payload type sr (發(fā)送者報告) 200 rr (接收者報告) 201 sdes (源描述) 202 bye 203 app (應(yīng)用程序定義) 204
rtcp sdes item value end (sdes列表結(jié)尾) 0 cname (規(guī)范名) 1 name (用戶名) 2 email 3 phone 4 loc 5 tool 6 note 7 priv 8
2.2.1 rtcp sr 包 rtcp發(fā)送者報告包在圖2中顯示，各域含有下列意義。 version (v): 與rtp中同 padding (p): 與rtp中同 reception report count (rc): 該域長度為5比特，rc表示接收報告塊的大小。 packet type (pt): 該域長度8比特，sr報告包的包類型是200。 ssrc: 與rtp中同 ntp time stamp: 該域長度64比特，ntp表示了該包發(fā)送時的最大執(zhí)行時間 (wall clock time)，這個信息是被用來測量鏈路網(wǎng)絡(luò)（round-trip）傳播延時。 rtp time stamp: 與rtp中同，這些時間戳被用于媒體內(nèi)／外的同步。 sender’s packet count: 該域長度為32比特，該域指示了從會話開始直到本sr被發(fā)送過程中發(fā)送者發(fā)出的rtp數(shù)據(jù)包的數(shù)目。 sender’s octet count: 該域長度為32比特，表示從會話開始發(fā)送的有效負荷字節(jié)的總數(shù)目。 ssrc_n (源標(biāo)識符): 該域長度為32比特，用于標(biāo)識在此次阻塞報告中信息源 fraction lost: 自前一個sr或rr包發(fā)送后丟失的rtp包的份額。 cumulative number of packet lost: 該域長度為24比特，表示從會話開始，丟失的rtp數(shù)據(jù)包的總數(shù)目。 extended highest sequence number received: 該域長度32比特，低16位包含從ssrc_n收到的rtp包中的最高序列號，最高16位用于擴展相應(yīng)的序列號的循環(huán)周期的計數(shù)值。 值得注意的是在同一會話的不同接收這來說，如果他們的起始時間差別比較大的話，接收者將產(chǎn)生不同的擴展位。 inter-arrival jitter: 該域長度32比特，表示了以時間戳為單位估計的rtp數(shù)據(jù)包到達時間的統(tǒng)計方差，用無符號的整數(shù)表示。 last sr timestamp: 該域長度32比特，它把收到的ntp時間戳64位中間的32位作為最近的rtcp sr的一部分。 delay since last sr (dlsr): 該域長度為32比特，延遲的單位是65536分之1秒，表示最近的sr包和本rr包之間的時間。 2.2.2 rtcp rr 包 rr包的結(jié)構(gòu)與sr包相同，只是它沒有包含發(fā)送者相關(guān)項（ntp, rtp 時間戳， 包數(shù)目跟字節(jié)數(shù)目）。 只有被動參加者才發(fā)rr包。 2.2.3 rtcp sdes 包 sdes包在圖3中給出，不同類型的源描述包如下列出: cname： 這是規(guī)范終端標(biāo)識符。cname在sdes包中是必須出現(xiàn)的項目，其余的都是可選的。cname可以被接收者用來識別同一個特定用戶產(chǎn)生的不同的媒體流。 其他被支持的sdes項是name, email,phone, loc, tool, note 和 priv 涉及到大量的參加者時，在一個會話過程中有可能rtcp的流量超過rtp的流量，這是由于，在時間的任何一個點上，只有一個人在說而其他的人都在聽。為了減少rtcp的流量，rtcp的包傳輸率，作為參加者數(shù)目，rtcp包大小，rtcp帶寬等的一個函數(shù)做動態(tài)變化。根據(jù)標(biāo)準(zhǔn)，會話帶寬的20％分配給rtcp并且rtcp帶寬的5％分配給cname。換句話說，每發(fā)送五個rtp包才發(fā)送一個rtcp的rr跟sr包。對于小型會話（參加者數(shù)目比較?。?，每5秒中會有一個rtcp的傳輸，每隔15秒鐘，一個附加項會被包括在sdes包中。 2.2.4 rtcp bye 包 rtcp bye包在rtp會話的結(jié)尾被送出，包的結(jié)構(gòu)如圖4所示： 2.2.5 rtcp app 包 app包是為了新的應(yīng)用程序和新的特性的實驗用途，其結(jié)構(gòu)如圖5所示 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |v=2|p| subtype | pt=app=204 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ssrc/csrc | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | name (ascii) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | application-dependent data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.0 sip中的rtp ietf已經(jīng)提議會話初始協(xié)議（sip）作為因特網(wǎng)上多媒體調(diào)用的建立，修改和終結(jié)。rtp/rtcp被媒體用來作為在他們系統(tǒng)中傳輸?shù)膮f(xié)議。sip的流圖結(jié)構(gòu)如圖6所示 4.0 h.323中的rtp itu-t已經(jīng)提出了h.323，這是另一個著名的多媒體通信系統(tǒng)。rtp/rtcp再次被用作媒體傳輸。h.323的流圖結(jié)構(gòu)在圖7中給出。 5.0 結(jié)論 rtp是應(yīng)用層級別的協(xié)議，它提供了在單點傳送或多點傳送基礎(chǔ)上，適合媒體傳輸如視頻，音頻，仿真數(shù)據(jù)等實時數(shù)據(jù)的，端到端的網(wǎng)絡(luò)傳輸功能。rtp以序列化，有效負載識別和媒體實時播放為目標(biāo)。數(shù)據(jù)傳輸增加了一個控制協(xié)議rtcp，這個協(xié)議監(jiān)聽了數(shù)據(jù)傳送并且提供了最小限度的控制和識別功能。rtp和rtcp被設(shè)計成獨立于下層網(wǎng)絡(luò)傳輸網(wǎng)絡(luò)，并且不提供源保留，也不保證實時服務(wù)的服務(wù)質(zhì)量（qos）。 rtp 術(shù)語表 rtp 有效負載： 在一個rtp包中被傳輸?shù)臄?shù)據(jù)。例如，音頻樣本或壓縮視頻數(shù)據(jù)。 rtp 媒體類型： rtp 媒體類型是有效負載類型的一個集合，這個集合在單一的rtp會話中被運載。有效負載類型是在音頻視頻協(xié)議（avp）中被定義的【rfc 1890】。 rtp 會話：在一個使用rtp進行通訊的參加者集合中的聯(lián)絡(luò)。 synchronizing source（ssrc）：rtp包的源，由在rtp頭中的一個32位數(shù)值ssrc標(biāo)識符來表示。為了跟網(wǎng)絡(luò)地址區(qū)別開來。 contributing source (csrc)：rtp包的一個流的源，這個源是通過一個rtp混合器來產(chǎn)生一個混合的新流。 mixer： 一個媒體間系統(tǒng)，它從一個或多個源發(fā)出的rtp包中提取內(nèi)容，并把它們通過某種方式混合，然后從一個新的rtp包中送出。在此過程中數(shù)據(jù)格式可能被改變。 translator： 一個媒體間系統(tǒng)，它把rtp包向前傳送，并不改變它們的synchronizing 此文來自: 馬開東博客 網(wǎng)址:http://www. 站長QQ |
|
|
