本備忘錄的狀態(tài)
本文檔講述了一種Internet社區(qū)的Internet標準跟蹤協(xié)議，它需要進一步進行討論和建議以
得到改進。請參考最新版的“Internet正式協(xié)議標準”(STD1)來獲得本協(xié)議的標準化程度
和狀態(tài)。本備忘錄的發(fā)布不受任何限制。
摘要
本文描述了一種在使用實時傳輸協(xié)議（RTP版本2）時對冗余音頻數(shù)據(jù)進行編碼的負載格
式。在此提出這套機制的主要目的是為了開發(fā)針對包易丟失網(wǎng)絡(luò)（如InternetMBone）的音
頻會議工具。盡管如此，該機制并不局限于此類應(yīng)用。
目錄
本備忘錄的狀態(tài) 1
摘要 1
1.介紹 2
2.需求與動機 2
3.負載格式說明 3
4.局限性 4
5.同SDP的關(guān)系 5
6.安全性考慮 5
7.示例 6
8.作者地址 7
9.參考文獻 7
1.介紹
隨著InternetMbong團體間多媒體會議得到更廣泛的應(yīng)用，用戶必定會進一步熟悉到，
大多數(shù)應(yīng)用都要求服務(wù)提供相當好的質(zhì)量。我們知道有很多因素都會影響到會議的質(zhì)量，其
中最明顯的就是包丟失問題。這個問題已經(jīng)持續(xù)多年，并隨著Internet的普及以及由此帶來
的負載增加而變得更加尖銳。即便是丟包率很低的情況下對語音理解性的破壞也會導(dǎo)致人們
對Internet多媒體會議的可行性產(chǎn)生懷疑。數(shù)據(jù)流冗余就是作為該問題的解決方案之一而提
出的[1]。在平均連續(xù)丟包率很低的情況下，假如一個包丟失了，則接收方還可通過后續(xù)包
中的冗余數(shù)據(jù)對失去的信息進行重組和恢復(fù)[2]。最近的工作[4][5]顯示，針對當前Internet
上的若干種包丟失模型，該機制都可以很好地工作。
本文描述了用于對冗余編碼的音頻數(shù)據(jù)進行傳輸?shù)腞TP負載格式。第二節(jié)說明了定義這
種負載格式的需求和動機，并未定義其具體形式。第三節(jié)定義了冗余音頻數(shù)據(jù)的RTP負載格
式。
2.需求與動機
RTP應(yīng)用中對冗余編碼機制有如下需求：
? 每個包必須攜帶一個主編碼和一個或多個冗余編碼。
? 由于對冗余信息可以采用多種編碼形式，每個冗余編碼塊都必須有一個編碼類型標
識符。
? 由于可能采用變長編碼，每個編碼后的塊都必須有長度指示符。
? RTP頭提供時間戳字段表示編碼數(shù)據(jù)的創(chuàng)建時間。當使用冗余編碼時該字段可以參
考主編碼數(shù)據(jù)的創(chuàng)建時間。冗余數(shù)據(jù)塊與主數(shù)據(jù)可能在時間上會有一定間隔，因此
每個冗余編碼塊都要有自己的時間戳。為了減少時間戳字段占用的字節(jié)數(shù)，可用冗
余編碼和主編碼時間戳的差值來進行編碼。
為標準RTP規(guī)范增加冗余音頻擴展有兩個基本的方法：一個包含有冗余的擴展頭，或者定
義一個或多個額外的負載類型。
通過將所有的冗余信息放在擴展頭中，那些不需要實現(xiàn)冗余的應(yīng)用程序就可以輕松地丟
棄該頭而專注于處理主編碼數(shù)據(jù)。
不過，這套機制也有一些弊端：
? 大量的額外負擔(dān)，擴展頭占用的4個字節(jié)和可能多達3個字節(jié)的擴展尾填充（為滿足
4字節(jié)邊界的要求）。對很多應(yīng)用都無法接受這么大的負擔(dān)。
? 使用擴展頭限制應(yīng)用程序只能使用一種冗余編碼，除非引入更多的結(jié)構(gòu)。這同樣也
會造成更多的負擔(dān)。
基于上述原因，我們放棄了使用RTP擴展頭的方式來實現(xiàn)音頻冗余編碼的方法。
RTP音視頻會議框架列出了一系列的負載類型并為會議控制協(xié)議定義新的編碼類型提供
了一個可容納32種編碼的動態(tài)范圍。因此，冗余音頻應(yīng)用可以采用下面兩種方法來分配額外
的RTP負載類型：
1. 定義一個動態(tài)的編碼機制,對每個主/冗組合的負載類型均應(yīng)用RTP動態(tài)負載類型
范圍。
2. 定義一個固定的負載類型來表示有冗余的包。它既可以分配給一個靜態(tài)RTP負載類
型也可以進行動態(tài)分配。
可以為所提供的32個動態(tài)負載類型中的每種類型都定義一個可標識特定編碼組合的負載
類型集合。這樣做可能造成一些限制，對那些只有一個冗余塊的包是可行的，因為這樣的包
的組合數(shù)并不多。而多冗余塊的需求使得編碼組合數(shù)大大增加，這種方法就無法適用了。
對上面方法的一個改進版本就是，在會議開始前從32種編碼組合的集合中選擇決定會議
期間使用那種方法。會議中的所有工具都可以用這套編碼組合工作集來進行初始化。工作集
之間的通信通過使用外部的，帶外機制來實現(xiàn)。由于用同樣的參數(shù)來啟動工具時要格外小心，
所以安裝設(shè)置的過程十分復(fù)雜。這個方案只用一個字節(jié)來鑒別編碼組合，因此比前者更有效。
然而，在將負載類型映射到冗余數(shù)據(jù)組合的分配過程中所固有的復(fù)雜性可能會導(dǎo)致人們
放棄使用這種機制。
此外還有一種更靈活的方法，就是以一個負載類型來表示有冗余的包。于是該包就成為
一個容器，在其中可封裝多個負載。這樣的方法可以把任意數(shù)量的冗余數(shù)據(jù)封裝到一個包中，
因此使用十分靈活。當然，每個封裝后的負載都要有一個頭來表示所包含的數(shù)據(jù)類型，這也
會帶來一點小小的負擔(dān)。但總之這還是一個比較好的方案，它兼具靈活性和擴展性，同時負
擔(dān)也相對較小。本文的剩余部分就將著重描述這種方法。
3.負載格式說明
本文中的要害字“必須”，“必須不”，“要求的”，“應(yīng)該”，“不應(yīng)該”，“會”，“不會”，
“建議”，“或許”，“可選的”在RFC2119中解釋。
為新的包格式分配RTP負載類型已超出本文范疇，不在此贅述。特定類型應(yīng)用程序的
RTP框架應(yīng)該負責(zé)為編碼分配負載類型，如若不能則應(yīng)在動態(tài)范圍內(nèi)選擇一個負載類型。
一個承載了冗余數(shù)據(jù)的RTP包應(yīng)該有一個標準RTP頭，同時要在負載類型中表示其中含有
冗余信息。頭中其它字段與主數(shù)據(jù)塊相關(guān)。
緊接著RTP頭是一些附加頭，定義于下圖中，它們規(guī)定了包所攜帶的每個編碼的內(nèi)容。此
后是數(shù)據(jù)塊，其中包括了這些編碼的標準RTP負載數(shù)據(jù)。注重到所有的頭都要同32位邊界對
齊，但負載數(shù)據(jù)卻往往不能對齊。假如一個包中攜帶了多個冗余編碼，則它們應(yīng)對應(yīng)不同的
時間段：沒必要為包的一個時間段制作多個數(shù)據(jù)拷貝。
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F塊負載類型時間戳偏移塊長度
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
頭中的各位定義如下:
標志位（F）:1位，頭中的第一位，表示后面是否還有另一個頭塊。假如該位為1表示后
面還有頭塊，假如該位為0表示這是最后一個頭塊。
塊負載類型（blockPT）:7位，表示該塊的RTP負載類型。
時間戳偏移（timestampoffset）:14位，本塊相對于RTP頭時間戳的無符號時間戳偏移
量。使用無符號偏移則說明冗余數(shù)據(jù)的發(fā)送必須在主數(shù)據(jù)已經(jīng)發(fā)送之后，因此要從當前時間
中減去主數(shù)據(jù)的發(fā)送時間來決定冗余數(shù)據(jù)所在塊的時間戳。
塊長度（blocklength）:10位，表示對應(yīng)數(shù)據(jù)塊的字節(jié)長度，其中不包括頭的長度。
我們注重到采用無符號偏移對使用冗余數(shù)據(jù)起了一定的限制：即不可能在發(fā)送主編碼前
發(fā)送冗余信息。這將對某些方法產(chǎn)生影響，因為一些適于冗余的低帶寬編碼可在編碼過程的
早期產(chǎn)生，從而可以提前發(fā)送。但是，額外的符號位會造成時間戳偏移范圍減少，這點是不
可接受的。同時增加字段長度超過14位也限制了塊長度字段。由此看來，限制冗余數(shù)據(jù)必須
在主數(shù)據(jù)之后發(fā)送所帶來的問題比起限制其它字段的長度而言要少一些。
冗余塊的時間戳偏移是由同一單元中的主數(shù)據(jù)時間戳來度量的（如：音頻采樣，與主數(shù)
據(jù)保持同樣的時鐘頻率）。這點說明冗余編碼和主編碼的采樣頻率必須相同。
我們還要注重到，塊長度和時間戳偏移分別為10位和14位，而不是常見的8位和16位。這
樣的編碼有時使對包頭的解析變得比較復(fù)雜，也造成了一些額外的處理負擔(dān)，但使用通常的
方式會造成很多問題：一個8位塊長度字段對大多數(shù)情況下的編碼都是足夠的，但并非全部，
例如：一段80ms的PCM和DVI音頻包長度超過256字節(jié)，不能編碼到單字節(jié)長度字段。當然也
可以在塊長度字段中增加額外的結(jié)構(gòu)（例如可以用高位為1表示低7位為按字長度編碼而非字
節(jié)），但這樣處理方式上十分復(fù)雜。而使用10位塊長度字段在犧牲了時間戳值范圍的情況下
既保留了處理簡單性，也提供了更大的長度范圍。
主編碼塊頭位于包的最后。我們可以忽略本塊頭中的時間戳和塊長度字段，因為他們可
以通過RTP頭和整個包的長度來判定。主數(shù)據(jù)塊的頭由一個零F位和一個塊負載類型組成，總
共8位。如下圖所示：
01234567
+-+-+-+-+-+-+-+-+
0BlockPT
+-+-+-+-+-+-+-+-+
最后一個頭之后就是數(shù)據(jù)塊，存儲順序和頭的排列順序相同。數(shù)據(jù)塊之間不需要填充或
者使用其它分隔，一般不需要32位對齊。如此選擇仍是為了在損失一定額外解碼時間的情況
下降低帶寬負擔(dān)。
編碼的選擇應(yīng)該反映其對帶寬的需求。冗余編碼所占帶寬應(yīng)遠遠小于主編碼所占帶寬：
然而該原則也有些例外，即假如主編碼本身帶寬就很小，且需要很高的處理能力，則往往使
用主編碼的拷貝來作為冗余。即便如此，冗余編碼絕不能比主編碼的所占帶寬高。
一般情況下沒必要使用多級冗余。在某些需要多級冗余情況下，每層的帶寬需求都要明
顯低于前一級。
4.局限性
RTP標志位并非是為冗余數(shù)據(jù)塊而保留的。因此，假如主數(shù)據(jù)丟失（其中包括標志位），
則標志位也會同時丟失。但我們認為它并不會造成什么大麻煩：因為即使標志位同冗余信息
一起傳輸也有丟失的可能，所以在編寫應(yīng)用程序時應(yīng)該充分考慮到這些。
另外，CSRC信息也不是為冗余數(shù)據(jù)保留的。冗余音頻包RTP頭中CSRC數(shù)據(jù)只同主數(shù)據(jù)有關(guān)。
由于CSRC數(shù)據(jù)相對較少發(fā)生變化，因此我們建議需要此信息的應(yīng)用程序可假定RTP頭中的
CSRC數(shù)據(jù)能夠用于重建冗余數(shù)據(jù)。
5.同SDP的關(guān)系
使用冗余負載時必須將其綁定到一個動態(tài)負載類型。這一過程可以通過帶外機制來實現(xiàn)，
不過更通用一些的辦法就是利用SDP[6]協(xié)議來進行關(guān)于綁定的通信。SDP定義了一套機制用
于將動態(tài)負載類型綁定到特定的編解碼器、采樣率、和多個使用"rtpmap"屬性的通道。下面
就是一個使用RTP視聽框架[3]的例子：
m=audio12345RTP/AVP12105
a=rtpmap:121red/8000/1
上例說明一個RTP音頻流正在使用負載類型121（一個動態(tài)負載類型）,0（PCMu-law）和
5(DVI)。“rtpmap”屬性用于將負載類型121綁定到編解碼器"red"，表示該編解碼器是一個
冗余幀，采樣率8KHz，且是單聲道的。當與SDP一同使用時，術(shù)語"red"表示本文中所討論的
冗余格式。
為此我們規(guī)定了PCM和DVI的附加格式。因此接收端必須為使用這些格式做好預(yù)備。這一
規(guī)定意味著在缺省情況下發(fā)送方可以發(fā)送冗余，也可以發(fā)送PCM或DVI。但對于冗余負載，我
們順帶提出這點意味著只能使用PCM或DVI作為冗余編解碼。注重到"m="字段中的定義的附加
負載格式本身也可能是動態(tài)負載類型，而一旦如此，就需要一些附加屬性"a="來描述這些動
態(tài)負載類型。
接收一個冗余流所需的一切就是如此。不過要發(fā)送一個冗余流，發(fā)送方得知道建議使用
的主編碼和第二編碼（如tertiary）。該信息對于冗余格式是明確的，并通過使用附加屬
性"fmtp"來指定,該屬性傳達了格式特定的信息。一個會話目錄并不解析fmtp屬性的值，而
僅僅是將它轉(zhuǎn)交給媒體工具。為了冗余性，我們定義了RTP負載格式的格式參數(shù)列表，通過
斜線"/"分隔開。
完整的例子如下：
m=audio12345RTP/AVP12105
a=rtpmap:121red/8000/1
a=fmtp:1210/5
上例說明發(fā)送方缺省模式為冗余，其中PCM作為主編碼，而DVI作為第二編碼。除非該編
碼已在媒體行("m=")中指定為有效，否則不能在fmtp屬性中指定編碼。
6.安全性考慮
包含冗余數(shù)據(jù)的RTP包從屬于RTP規(guī)范[2]以及任何適用的RTP框架（如[3]）所討論的安
全性考慮。這意味著媒體流的安全性要通過加密來達到。對冗余數(shù)據(jù)進行加密可通過下面兩
種方法實現(xiàn)：
1.對整個流進行加密，所有的參與者都必須擁有密鑰才可進行解密。在這種情況下，
加密采用通常的方式來進行，無須什么非凡的操作。
2.流的一部分和其余部分以不同的密鑰進行加密。采用這種方式，最后一個包的冗余
拷貝就無法進行發(fā)送，因為已經(jīng)沒有后續(xù)包能采用正確的密鑰進行加密。類似的限制也出現(xiàn)
于使能和禁止加密的過程中。
從兩者中具體選擇哪種方式進行加密是編碼者的問題，而解碼者應(yīng)可以無須修改而對任
何一種形式進行解密。
音頻流的低帶寬冗余對于解決包丟失的保護問題是一種很有效的方法，與此同時，應(yīng)用
設(shè)計者也應(yīng)該注重到，大量冗余數(shù)據(jù)會造成網(wǎng)絡(luò)擁塞的增加和加劇包丟失現(xiàn)象，這將使采用
冗余數(shù)據(jù)試圖解決的包丟失問題變得更糟。在最極端的情況下，還會導(dǎo)致網(wǎng)絡(luò)擁塞過度，甚
至形成拒絕服務(wù)攻擊。
7.示例
一個RTP音頻數(shù)據(jù)包，包括一個DVI4(8KHz)主編碼塊和一個單獨的8KHzLPC編碼的冗余
塊，兩者長度均為20ms。參照RTP視聽框架[3]所定義，如下所示：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V=2PXCC=0MPT主數(shù)據(jù)順序號
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
主編碼時間戳
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
同步源標識(SSRC)符
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1blockPT=7時間戳偏移塊長度
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0blockPT=5
+-+-+-+-+-+-+-+-++

+LPC編碼冗余數(shù)據(jù)(PT=7)+
(14bytes)
++---------------+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++

++

++

++
DVI4編碼主數(shù)據(jù)(PT=5)
+(84bytes,nottoscale)+
//
++

++

++---------------+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.作者地址
ColinPerkins/IsidorKouvelas/OrionHodson/VickyHardman
DepartmentofComputerScience
UniversityCollegeLondon
LondonWC1E6BT
UnitedKingdom
EMail:{c.perkinsi.kouvelaso.hodsonv.hardman}@cs.UCl.ac.uk
MarkHandley
USCInformationSciencesInstitute
c/oMITLaboratoryforComputerScience
545TechnologySquare
Cambridge,MA02139,USA
EMail:mjh@isi.edu
Jean-ChrysostomeBolot/AndresVega-Garcia/SachaFosse-Parisis
INRIASophiaAntipolis
2004RoutedesLucioles,BP93
06902SophiaAntipolis
France
EMail:{bolotavegasfosse}@sophia.inria.fr
9.參考文獻
[1]V.J.Hardman,M.A.Sasse,M.HandleyandA.Watson;Reliable
AudioforUSEOvertheInternet;Hawaii,September1995.http://www.isoc.org/in95prc/
[2]Schulzrinne,H.,Casner,S.,FrederickR.,andV.Jacobson,"RTP:
ATransportProtocolforReal-Timeapplications",RFC1889,January
1996.
[3]Schulzrinne,H.,"RTPProfileforAudioandVideoConferences
withMinimalControl",RFC1890,January1996.
[4]M.Yajnik,J.KuroseandD.Towsley;Packetlosscorrelationin
theMBonemulticastnetwork;IEEEGlobecomInternetworkshop,London,
November1996
[5]J.-C.BolotandA.Vega-Garcia;ThecaseforFEC-basederror
controlforpacketaudiointheInternet;ACMMultimediaSystems,
1997
[6]Handley,M.,andV.Jacobson,"SDP:sessionDescriptionProtocol
(draft03.2)",WorkinProgress.
[7]Bradner,S.,"KeyWordsforuseinRFCstoindicaterequirement
levels",RFC2119,March1997.