用于文本交談的RTP負載

本備忘錄的狀態
本文檔講述了一種Internet社區的Internet標準跟蹤協議，它需要進一步進行討論和建
議以得到改進。請參考最新版的“Internet正式協議標準”(STD1)來獲得本協議的標準化
程度和狀態。本備忘錄的發布不受任何限制。

版權聲明
Copyright(C)TheInternetSociety(2001).

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

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|CC=0|M|T140PT|順序號|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|時間戳(1000Hz)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|同步源(SSRC)標識符|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+T.140編碼數據+
||
++---------------+
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


這是一個攜帶冗余數據的RTP包的例子

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|CC=0|M|"RED"PT|主序號|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|原始數據時間戳|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|同步源(SSRC)標識符|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|T140PT|"R"時間戳位移|"R"塊長度|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|T140PT||
+-+-+-+-+-+-+-+-++
||
+"R"T.140編碼冗余數據+
||
++---------------+
|||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++
|"P"T.140編碼原始數據|
++
++---------------+
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
附圖：RTP文本包的例子
5．安全性考慮
既然本負載格式的目的是在文本交談中攜帶文本，加密的安全性度量就變得十分重要。
文本傳輸的數量很少，這樣我們可以選擇任何加密方法來對T.140會話或者整個RTP包進
行加密。如果數據包中包含了冗余數據，要使用同RFC2198一樣的安全性考慮。
6.MIMEMediaTypeRegistrations

本文檔描述了一種新的RTP負載名稱和相應的MIME類型，T140(text/t140).
6.1RegistrationofMIMEmediatypetext/t140
MIMEmediatypename:text
MIMEsubtypename:t140
必需參數:無
可選參數:無
編碼考慮:按RFC2793規定傳輸T140文本。
安全性考慮：無
互操作考慮:無
已發行規范:ITU-T建議T.140，RFC2793.
使用該媒體類型的應用:
文本通信終端和文本會議工具。
附加信息:無
Magicnumber(s):無
文件擴展:無
Macintosh文件類型碼:無
聯系辦法:
GunnarHellstrom
e-mail:gunnar.hellstrom@omnitor.se
預期使用:COMMON
Author/Changecontroller:
GunnarHellstrom|IETFavtWG
gunnar.hellstrom@omnitor.se|c/oSteveCasnercasner@cisco.com
鳴謝
感謝StephenCasner和ColinPerkins在本文寫作時給予的細查和建議。
感謝Ericsson公司的MickeyNasiri提供的實驗環境。
感謝MicheleMizarro驗證了負載格式的可用性。
作者地址
GunnarHellstrom
OmnitorAB
Alsnogatan7,4tr
SE-11641Stockholm
Sweden
Phone:+46708204288/+46855600203
Fax:+46855600206
EMail:gunnar.hellstrom@omnitor.se
參考
[1]ITU-TRecommendationT.140(1998)-Textconversationprotocol
formultimediaapplication,withamendment1,(2000).
[2]Schulzrinne,H.,Casner,S.,Frederick,R.andV.Jacobson,
"RTP:ATransportProtocolforReal-TimeApplications",RFC
1889,January1996.
[3]Perkins,C.,Kouvelas,I.,Hardman,V.,Handley,M.andJ.
Bolot,"RTPPayloadforRedundantAudioData",RFC2198,
September1997.
[4]Bradner,S.,"KeywordsforuseinRFCstoIndicateRequirement
Levels",BCP14,RFC2119,March1997.
[5]ISO/IEC10646-1:(1993),UniversalMultipleOctetCoded
CharacterSet.
[6]Yergeau,F.,"UTF-8,atransformationformatofISO10646",RFC
2279,January1998.
版權說明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuclearcase/" target="_blank" >ccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.
致謝
FundingfortheRFCEditorfunctioniscurrentlyprovidedbytheInternetSociety.