組織：中國(guó)互動(dòng)出版網(wǎng)（http://www.china-pub.com/）
RFC文檔中文翻譯計(jì)劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：孟巖（dreamwords   dreamwords@sina.com）李超（licc_li@sina.com）
譯文發(fā)布時(shí)間：2001-6-26
版權(quán)：本中文翻譯文檔版權(quán)歸中國(guó)互動(dòng)出版網(wǎng)所有。可以用于非商業(yè)用途自由轉(zhuǎn)載，但必須保留本文檔的翻譯及版權(quán)信息。



Network Working Group                                       G. Hellstrom
Request for Comments: 2793                                    Omnitor AB
Category: Standards Track                                       May 2000


用于文本交談的RTP負(fù)載
（RTP Payload for Text Conversation）


本備忘錄的狀態(tài)
本文檔講述了一種Internet社區(qū)的Internet標(biāo)準(zhǔn)跟蹤協(xié)議，它需要進(jìn)一步進(jìn)行討論和建
議以得到改進(jìn)。請(qǐng)參考最新版的“Internet正式協(xié)議標(biāo)準(zhǔn)” (STD1)來獲得本協(xié)議的標(biāo)準(zhǔn)化
程度和狀態(tài)。本備忘錄的發(fā)布不受任何限制。

版權(quán)聲明
Copyright (C) The Internet Society (2001).

摘要
本文描述了在RTP包中傳輸文本交談內(nèi)容的方法，關(guān)于文本交談會(huì)話內(nèi)容在ITU-T建議
（T.140[1]）中有詳細(xì)說明。
文本交談可以用來單獨(dú)傳輸或與音視頻等交談工具一起構(gòu)成多媒體交談服務(wù)。
本RTP負(fù)載包含可選的已傳輸數(shù)據(jù)包的冗余文本來降低包丟失的風(fēng)險(xiǎn)。冗余碼參照RFC 
2198。
									目錄
1．簡(jiǎn)介	2
1.1 術(shù)語(yǔ)	3
2. RTP用法	3
2.1 RTP包頭	3
2.2 附加頭	4
2.3 T.140 文本結(jié)構(gòu)	4
3. 推薦過程	4
3.1  基本推薦過程	5
3.2  補(bǔ)償丟包的推薦過程	5
3.3  補(bǔ)償亂序包的推薦過程	5
3.4  使用冗余時(shí)的“靜音期”傳輸	5
4. 范例	6
5．安全性考慮	7
6.  MIME MEDIA TYPE REGISTRATIONS	7
6.1  Registration of MIME media type text/t140	7
鳴謝	8
作者地址	8
參考	8
版權(quán)說明	9
致謝	9
1．簡(jiǎn)介
本文定義了一種用于在RTP包中傳輸文本交談會(huì)話內(nèi)容的負(fù)載格式，文本交談會(huì)話內(nèi)容
在ITU-T建議（T.140[1]）中有詳細(xì)說明。文本交談可單獨(dú)傳輸或與音視頻等交談工具共同
構(gòu)成多媒體交談服務(wù)。文本交談中的文本應(yīng)盡快傳輸，或者經(jīng)過一個(gè)小的緩沖延遲。
文本的輸入通常是以鍵盤、手寫識(shí)別、語(yǔ)音識(shí)別或是其它輸入方法。字符的輸入率通常
為每秒幾個(gè)字符。這樣，期望的字符傳輸率也較低。通常每個(gè)包中只有很少的新字符需要傳
輸。
在T.140中指定文本和其它T.140元素必須以經(jīng)過UTF-8變換的ISO 10 646-1 碼來傳送。
這些有助于實(shí)現(xiàn)國(guó)際化應(yīng)用，并且易于處理現(xiàn)代信息技術(shù)環(huán)境中的文本。本文RTP負(fù)載中
的文本編碼嚴(yán)格遵守T.140，沒有任何附加幀。通常是UTF-8編碼的ISO 10646單字符。
	T.140要求字符按照原始順序，沒有重復(fù)的傳輸。文本交談的使用者希望文本傳輸沒有
或盡可能少丟失。當(dāng)然，如果能標(biāo)識(shí)出丟失的信息，則丟失的可接受程度會(huì)高些。
	因此，這里介紹了一個(gè)基于RTP的機(jī)制。它將按照原始順序，無重復(fù)傳輸，并且提供
丟失檢測(cè)和指示。它同時(shí)也提供一個(gè)可選方案，利用重復(fù)的冗余數(shù)據(jù)來降低丟失文本風(fēng)險(xiǎn)。
考慮到包開銷通常遠(yuǎn)遠(yuǎn)大于T.140內(nèi)容，傳輸通道中增加冗余數(shù)據(jù)造成的負(fù)擔(dān)很小。
1.1 術(shù)語(yǔ)
本文中的關(guān)鍵字“必須”，“必須不”，“要求的”，“應(yīng)該”，“不應(yīng)該”，“會(huì)”，“不會(huì)”，
“建議”，“或許”，“可選的”在 RFC 2119 [4]中解釋。
2. RTP用法
當(dāng)RTP傳輸中需要傳輸T.140文本交談，應(yīng)該使用本文所述的負(fù)載。
這種負(fù)載格式的文本交談RTP包的格式包括：一個(gè)RTP頭（在RFC 1889 [2] 中有定義），
其后緊接著是一個(gè)T.140數(shù)據(jù)塊（這里被定義為“T140block”）。該負(fù)載格式?jīng)]有附加頭。
T140塊包括 [1] 中定義的一個(gè)或多個(gè)T.140碼元素。大部分T.140碼元素為ISO 10645 [5] 單
字符，但是也有一些是多字符序列。其中每個(gè)字符均為UTF-8編碼[6]的一個(gè)或多個(gè)字節(jié)。
這說明不管單個(gè)字符中有幾個(gè)字節(jié)，每一塊必須包含UTF-8碼的整數(shù)倍。這也說明任何組
合的字符序列（CCS）應(yīng)該被放到同一塊中。
T140塊可能會(huì)根據(jù)RFC 2198 [3] 所定義的負(fù)載格式傳輸冗余數(shù)據(jù)。這樣，RTP頭后將
是一或多個(gè)冗余數(shù)據(jù)塊頭，個(gè)數(shù)與從攜帶的冗余T140塊數(shù)相同，最后是此包的新T140塊。
2.1 RTP包頭
每個(gè)RTP包開始于一個(gè)固定的RTP頭。下面列出了用于T.140文本流的幾個(gè)RTP頭字
段。
負(fù)載類型（PT）：RTP負(fù)載類型的分配是使用該負(fù)載格式的RTP框架特定的。對(duì)于利用
動(dòng)態(tài)負(fù)載類型號(hào)的協(xié)議子集，這種負(fù)載格式被命名為"T140"（參照第六節(jié)）。如果按照RFC 
2198使用冗余數(shù)據(jù)，負(fù)載類型中必須指定負(fù)載格式（"RED"）。
順序號(hào)：順序號(hào)必須嚴(yán)格按照每個(gè)新傳送包以一遞增。它用于包丟失和亂序檢測(cè)，同時(shí)
也可以用于獲取冗余文本，重組文本和標(biāo)記丟失文本。
	時(shí)間戳：RTP時(shí)間戳記錄了包中主文本塊采樣時(shí)間的近似值。必須使用1000赫茲的時(shí)
鐘頻率。連續(xù)包不能使用相同的時(shí)間戳。由于包不按固定間隔發(fā)送，所以時(shí)間戳不能直接被
用于指示包丟失。
2.2 附加頭
本負(fù)載格式?jīng)]有定義專門的附加頭。
當(dāng)要按RFC 2198傳輸冗余數(shù)據(jù)時(shí)，RTP頭后緊跟者一個(gè)或多個(gè)冗余數(shù)據(jù)塊頭，每個(gè)冗
余數(shù)據(jù)塊都要有一個(gè)對(duì)應(yīng)的冗余數(shù)據(jù)塊頭。這些頭部均提供了時(shí)間戳位移和相應(yīng)的數(shù)據(jù)塊長(zhǎng)
度，以及指示了這種負(fù)載格式("T140")的負(fù)載類型號(hào)。
2.3 T.140 文本結(jié)構(gòu)
T.140文本是按T.140協(xié)議規(guī)定經(jīng)過UTF-8編碼的，沒有額外組幀。當(dāng)用該格式傳輸冗
余數(shù)據(jù)時(shí)，發(fā)送者會(huì)選擇每個(gè)包中要傳輸?shù)腡140block數(shù)。數(shù)越高則將丟包保護(hù)性越好，但
同時(shí)也會(huì)增加數(shù)據(jù)傳輸率。
由于數(shù)據(jù)包并非按一定的時(shí)間間隔產(chǎn)生，如果不提供附加信息，時(shí)間戳在包丟失時(shí)就無
法標(biāo)識(shí)出該包。冗余數(shù)據(jù)頭并沒有提供順序號(hào)，所以必須遵循附加規(guī)則才能將丟失主數(shù)據(jù)所
對(duì)應(yīng)的冗余數(shù)據(jù)正確的插入T140blocks主數(shù)據(jù)流中：
1.	每個(gè)冗余數(shù)據(jù)塊必須與先前傳輸原始數(shù)據(jù)的T140塊數(shù)據(jù)相同，并標(biāo)識(shí)為相同的時(shí)
間戳位移。
2.	冗余數(shù)據(jù)必須按照時(shí)間順序放置，最近的冗余T140塊位于冗余區(qū)的最后。
3.	必須包括從最早的T140blocks到新數(shù)據(jù)塊前的T140blocks所有的T140塊，。
通過這些規(guī)則，冗余T140塊的順序號(hào)可以從當(dāng)前RTP頭的序號(hào)反向推算得到。結(jié)果就
是負(fù)載中的所有文本都是連續(xù)且順序的。
3. 推薦過程
這部分描述了負(fù)載格式使用的推薦過程，根據(jù)接受包的信息，接收者可以：
1.	把錯(cuò)亂文本重新排序。
2.	標(biāo)識(shí)丟失文本。
3.	用冗余數(shù)據(jù)補(bǔ)償丟失包。
3.1  基本推薦過程
	只有合法的T.140格式的數(shù)據(jù)包才被傳輸， T.140數(shù)據(jù)的排序要使用順序號(hào)。
	在接收端，將RTP順序號(hào)與最后一次正確接收包的序號(hào)相比較，如果是連續(xù)的，就從
中取出T140block。
3.2  補(bǔ)償丟包的推薦過程
	為了減少包丟失時(shí)的數(shù)據(jù)丟失，可以根據(jù)RFC2198在包中使用冗余數(shù)據(jù)。如果無法得
知網(wǎng)絡(luò)條件，建議每一包中只使用一個(gè)冗余T140塊。如果RTP序號(hào)出現(xiàn)空隙，且后續(xù)包中
的冗余T140塊可用，則可以通過包中RTP頭的序號(hào)逆向推算出冗余T140塊的序號(hào)。如果
該冗余T140塊的序號(hào)與丟失的相吻合，就用冗余T140塊來替換丟失T140塊。
	無論是否使用冗余數(shù)據(jù)，都應(yīng)該在T140塊的接收流中插入一個(gè)丟失文本標(biāo)記來標(biāo)志丟
失的數(shù)據(jù)，見ITU-T T.140附錄。
3.3  補(bǔ)償亂序包的推薦過程
	對(duì)于亂序包的檢測(cè)，接收端應(yīng)該采取下屬程序。如果接收包序號(hào)有空隙，但沒有可用的
冗余數(shù)據(jù)來填充那個(gè)空隙，則接收包將被存儲(chǔ)在緩存中來等待丟失包的到達(dá)。建議等待時(shí)間
限于0.5秒。如果使用了冗余，并且冗余數(shù)乘以T.140緩沖時(shí)間比0.5秒長(zhǎng)，則等待時(shí)間應(yīng)
延長(zhǎng)到該乘積。
	如果空隙數(shù)據(jù)包在限制時(shí)間內(nèi)到達(dá)，則將它被插入到空隙中，這樣從空隙前沿開始的
T140塊就恢復(fù)連續(xù)了。任何沒有在限制時(shí)間內(nèi)到達(dá)的T140塊將被視為丟失。
3.4  使用冗余時(shí)的“靜音期”傳輸
	當(dāng)使用冗余傳輸模式且T.140沒有數(shù)據(jù)要傳輸時(shí)，最后傳輸?shù)囊粋€(gè)T140塊有可能在作
冗余數(shù)據(jù)傳送之前就失效。這樣就不能對(duì)文本輸入序列的末尾提供有效的丟包保護(hù)。為了要
避免這種情況，應(yīng)該傳送一個(gè)0長(zhǎng)度的攜帶冗余數(shù)據(jù)的原始T140塊。
	根據(jù)2.3節(jié)，為了能正確推算冗余T140塊的序號(hào)，任何被當(dāng)作原始數(shù)據(jù)為0長(zhǎng)度的T140
塊必須如同正常文本塊一樣在接下來的包中當(dāng)作冗余傳輸。
	最后一個(gè)T140塊的冗余不應(yīng)該由重復(fù)傳送同一個(gè)包（相同序號(hào)）來解決，因?yàn)檫@樣會(huì)
造成RTCP報(bào)告的包丟失數(shù)量減少。
4. 范例