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

版權(quán)聲明
Copyright(C)TheInternetSociety(2001).

摘要
本備忘錄描述了在RTP數(shù)據(jù)包中傳送雙音多頻(DTMF)信號、其它電話信號音和電話事
件的方法。
目錄
1介紹 2
1．1術(shù)語 3
2．語音與事件 3
3．用于命名電話事件的RTP負(fù)載格式 4
3．1介紹 4
3．2同時(shí)產(chǎn)生音頻和事件 4
3．3事件類型 4
3．4RTP頭用法 5
3．5負(fù)載格式 5
3．6發(fā)送事件數(shù)據(jù)包 6
3．7可靠性 6
3．8舉例 7
3．9接收端使用SDP性能的表述 7
3．10DTMF事件 8
3．11數(shù)據(jù)調(diào)制解調(diào)器和傳真事件 8
3．12線路事件 10
3．13擴(kuò)展線路事件 12
3．14信息通路事件 12
4．用于電話話音的RTP負(fù)載格式 13
4．1介紹 13
4．2公共電話話音信號實(shí)例 14
4．3RTP頭字段的使用 15
4．4負(fù)載格式 15
4．5可靠性 16
5．信號音合并和命名事件 16
6．MIME注冊 16
6．1audio/telephone-event 16
6．2audio/tone 17
7．安全考慮 18
8.IANA考慮 18
鳴謝 18
作者地址 18
參考書目 19
版權(quán)說明 20
致謝 21

1介紹
本備忘錄定義了兩種負(fù)載格式，一種用于在RTP包中傳送雙音多頻數(shù)字信號、其它線
路和干線信號（第三節(jié)），第二種則用于RTP包中普通多頻電話音的傳輸（第四節(jié)）。由于
低速率聲音編解碼器無法保證能完全正確地自動識別重現(xiàn)的電話音信號，所以需要單獨(dú)定義
RTP負(fù)載格式。定義獨(dú)立負(fù)載格式也使得在保持低比特率的同時(shí)系統(tǒng)能有更高的冗余性。
這里描述的負(fù)載格式將至少可應(yīng)用于以下三種場合的DTMF處理：網(wǎng)關(guān)、終端系統(tǒng)和
“RTP干線”。在第一種應(yīng)用中，因特網(wǎng)電話網(wǎng)關(guān)檢測引入網(wǎng)路的DTMF并發(fā)送描述該內(nèi)容
的RTP負(fù)載而不是通常的音頻數(shù)據(jù)包。網(wǎng)關(guān)一般必須得有數(shù)字信號處理器和相應(yīng)的算法，
因?yàn)樗?jīng)常要檢測DTMF，例如在雙階段撥號中。由網(wǎng)關(guān)檢測話音可減輕Internet終端系統(tǒng)
的工作負(fù)擔(dān)，同時(shí)也避免諸如G.723.1等低比特率編解碼器誤解DTMF音。第二，如“因特
網(wǎng)電話”等因特網(wǎng)終端系統(tǒng)能夠仿真DTMF的功能性，而不考慮自身產(chǎn)生精確的電話音對，
也不影響接收端的語音識別負(fù)擔(dān)能力。
在“RTP干線”應(yīng)用中，RTP常用于取代兩點(diǎn)間通常的電路開關(guān)干線，這在仍然以電
路開關(guān)為主的電話網(wǎng)絡(luò)中猶為重要。這時(shí)，RTP干線端點(diǎn)將對音頻通道中信號進(jìn)行適當(dāng)?shù)木?br />碼，如按G.723.1或G.729。然而，這種編碼過程破壞了通過最低位攜帶的帶內(nèi)信令信息，
也會干擾MF數(shù)字語音等段內(nèi)信令話音。另外，如ANSam音中的相位反轉(zhuǎn)等語音屬性不支
持語音編碼。因而，網(wǎng)關(guān)需要從比特流中除去這些帶內(nèi)信令信息。它可以以帶外方式通過待
定義的信令傳輸機(jī)制傳送，也可以使用本備忘錄描述的機(jī)制進(jìn)行傳送。（假如兩個(gè)干線端點(diǎn)
在同一個(gè)媒體網(wǎng)關(guān)控制器可控范圍內(nèi)，媒體網(wǎng)關(guān)控制器也可處理該信令。）帶內(nèi)傳送可以簡
化音頻數(shù)據(jù)包和電話音或信號信息之間的時(shí)間同步。這在具有持續(xù)性和計(jì)時(shí)的事件中尤其重
要，如DTMF信號傳送。
1．1術(shù)語
本文中的要害字“必須”，“必須不”，“要求的”，“應(yīng)該”，“不應(yīng)該”，“會”，“不會”，“建
議”，“或許”，“可選的”在RFC2119中解釋。
2．語音與事件
網(wǎng)關(guān)處理DTMF數(shù)字信號和事件的方式有兩種。第一種，它可以簡單測量聲音波段信
號的頻率成分并將這些信息傳送到RTP接收端（第四節(jié)）。在這種模式下，網(wǎng)關(guān)僅從語音信
號中簡單辨別話音，無需鑒別話音的含義。用于PSTN且人可感知的所有話音信號都是一系
列簡單正弦波的組合，經(jīng)過疊加或調(diào)制。（至少有一種話音使用了周期性相位反轉(zhuǎn)，如在話
音線路上指示數(shù)據(jù)傳輸?shù)腁NSamtone[3]。）
第二種，網(wǎng)關(guān)可以識別電話音并將它們譯為名稱，如振鈴或忙音。接收端即產(chǎn)生電話音
信號或其它相應(yīng)的信號描述。通常，由于信號識別依靠開/關(guān)模式或個(gè)別電話音序列，這種
識別會花幾秒鐘。另一方面，網(wǎng)關(guān)可以訪問產(chǎn)生電話音的真實(shí)信令信息，因此能夠馬上生成
RTP包，無需繞開聲音信號。
在電話網(wǎng)絡(luò)中，電話音產(chǎn)生于不同的地方，取決于開關(guān)技術(shù)和音調(diào)特性。這就決定了當(dāng)
一個(gè)人給國外打電話時(shí)所聽見的是她所熟悉的本地音調(diào)還是被叫國使用的音調(diào)。
對于模擬線路而言，撥號音通常是通過本地開關(guān)產(chǎn)生的。ISDN終端可以在本地產(chǎn)生撥
號音，然后發(fā)送包含所撥數(shù)字的Q.931SETUP消息。假如終端只發(fā)送SETUP消息而沒有任
何被叫方號碼，開關(guān)收集由終端KEYPAD提供的數(shù)字，并由B通道發(fā)出撥號音。終端可在B
通道使用音頻信號，或是用Q.931消息觸發(fā)本地產(chǎn)生撥號音。
振鈴聲（也稱為回響音）由被呼叫方的本地開關(guān)產(chǎn)生，被呼叫方電話一響就打開一個(gè)
單向聲音通道。（這減少了修剪被呼叫當(dāng)事人應(yīng)答后響應(yīng)的機(jī)會。它也答應(yīng)預(yù)應(yīng)答通告或帶
內(nèi)呼叫過程指示在振鈴前/中到達(dá)呼叫者。）擁塞音及非凡信息音可由通路中任何開關(guān)產(chǎn)生，
也可由呼叫者開關(guān)根據(jù)接收到的ISUP消息產(chǎn)生。在模擬設(shè)備或ISDN終端中，忙音由呼叫
者開關(guān)產(chǎn)生，并由相應(yīng)ISUP消息觸發(fā)。
通過RTP發(fā)送信號事件的網(wǎng)關(guān)在一次單獨(dú)RTP會話中會發(fā)送命名信號（第三節(jié)）以
及話音表述（第四節(jié)），使用3.7節(jié)中定義的冗余機(jī)制插入這兩項(xiàng)表述。因?yàn)樗饝?yīng)接收端
自由選擇合適的表述，所以這種方法也是一種比較通用的好辦法。
假如網(wǎng)關(guān)不能給出電話音表述，除命名信號外，它還應(yīng)該在常規(guī)RTP音頻數(shù)據(jù)包中（如
在PCMU負(fù)載中）發(fā)送音頻音。
3．用于命名電話事件的RTP負(fù)載格式
3．1介紹
下面描述的命名電話事件的負(fù)載格式適合于網(wǎng)關(guān)和終端到終端的場合。在網(wǎng)關(guān)中，將語
音包網(wǎng)絡(luò)連接到PSTN網(wǎng)絡(luò)上的Internet電話網(wǎng)關(guān)重新生成DTMF音或其它電話事件并將它
們插入到PSTN。由于識別DTMF數(shù)字等操作會占用幾十毫秒，則最開始的數(shù)毫秒內(nèi)數(shù)字將
作為常規(guī)音頻數(shù)據(jù)包到達(dá)。因此，為了避免在接收端產(chǎn)生虛假數(shù)字信號，必須注重音頻樣本
及事件間的時(shí)間及功率（音量）隊(duì)列。
DTMF數(shù)字信號及命名電話事件作為音頻流的一部分進(jìn)行發(fā)送，且為了簡化網(wǎng)關(guān)中音頻
波形的產(chǎn)生必須使用以相同序號和時(shí)間戳為基礎(chǔ)的常規(guī)音頻信道。默認(rèn)的時(shí)鐘頻率為8000
赫茲，但時(shí)鐘頻率可在動態(tài)分配負(fù)載類型時(shí)重定義。
這里描述的負(fù)載格式與VoiceoverFrameRelayImplementationAgreement[4]所提出
的方式相比，即使在連續(xù)數(shù)據(jù)包丟失的情況下也可達(dá)到更高的冗余性。
若終端系統(tǒng)直接與Internet相連且不必再產(chǎn)生電話音信號，那么時(shí)間隊(duì)列和功率標(biāo)準(zhǔn)就
不相關(guān)了。這些系統(tǒng)依靠PSTN網(wǎng)關(guān)或Internet端系統(tǒng)產(chǎn)生DTMF事件，并且不執(zhí)行自己的
音頻波形分析。例如Internet交互式聲音應(yīng)答系統(tǒng)（IVR）就是這樣一種系統(tǒng)。
在某些環(huán)境中，音頻流和DTMF數(shù)字信號或其它事件間的時(shí)間對齊并不重要，假如象
前面提到的IVR一樣，數(shù)據(jù)采用單播方式發(fā)送，最好采用比RTP更可靠的控制協(xié)議。這時(shí)
就不能再使用本文定義的負(fù)載格式。
3．2同時(shí)產(chǎn)生音頻和事件
使用事件作為音頻流的冗余編碼，信號源可以同時(shí)發(fā)送事件和已編碼的音頻數(shù)據(jù)包，或
者它會在事件音活動時(shí)阻塞發(fā)出的音頻，只發(fā)送作為主編碼和冗余編碼的命名事件。
值得注重的是，一種已編碼音的周期在時(shí)間上會與用其它方式編碼的音產(chǎn)生周期交疊。
這在該信號音開始時(shí)就會發(fā)生，因此對遠(yuǎn)程終端重現(xiàn)信號音譯碼時(shí)必須避免此類錯誤。支持
這種負(fù)載格式的實(shí)現(xiàn)應(yīng)能處理這種交疊。由于音頻中會包含音頻壓縮算法產(chǎn)生的假話音，建
議網(wǎng)關(guān)只處理已譯碼的音。不過，一般而言這些額外音通常并不會干擾遠(yuǎn)端的識別。
3．3事件類型
這種負(fù)載格式用于5種不同的信號格式：
? DTMF音（3。10小節(jié)）
? 傳真相關(guān)音（3。11小節(jié)）
? 標(biāo)準(zhǔn)用戶線路音（3。12小節(jié)）
? 特定國家用戶線路音（3。13小節(jié)）
? 干線事件（3。14小節(jié)）

本文檔兼容的實(shí)現(xiàn)必須支持表1中除“Flash”外的所有事件。假如使用其它方式，如
帶外機(jī)制實(shí)現(xiàn)信令線路條件，就不必實(shí)現(xiàn)其它事件。
在某些情況下，具體實(shí)現(xiàn)時(shí)有些事件可以簡單忽略掉，例如傳真音，在特定環(huán)境下它
可能沒什么意義。3.9小節(jié)指出了實(shí)現(xiàn)中如何使用SDP描述的"fmtp"參數(shù)以表示它無法理解
某一事件或一定范圍內(nèi)的事件。
依靠可用的用戶接口，實(shí)現(xiàn)可以翻譯表5中的所有電話音，更適合的方式是使用在并發(fā)
“tone”負(fù)載或其它RTP音頻負(fù)載所傳送的電話音。作為可選項(xiàng)，它可以提供文本表述。
注重到由于MF主干也攜帶了大部分"line"信令，仿真電話的終端系統(tǒng)只需支持3.10小
節(jié)和3.12小節(jié)中提到的事件，而接收主干信令的系統(tǒng)需要實(shí)現(xiàn)3.10、3.11、3.12和3.14小
節(jié)提到的事件。不支持傳真和調(diào)制解調(diào)器功能的系統(tǒng)不用支持3.11描述的和傳真相關(guān)的事
件。
RTP的負(fù)載格式定為“telephone-event”，MIME類型為“audio/telephone-event”。
默認(rèn)的時(shí)間戳頻率為8000赫茲，當(dāng)然也可以定義其它頻率。為了同現(xiàn)有的實(shí)現(xiàn)一致，這種
負(fù)載格式?jīng)]有靜態(tài)負(fù)載類型號，而使用動態(tài)帶外方式建立的RTP負(fù)載類型號。
3．4RTP頭用法
時(shí)間戳：RTP時(shí)間戳反映了當(dāng)前數(shù)據(jù)包的測量點(diǎn)。3.5小節(jié)描述的事件持續(xù)時(shí)間就從該
點(diǎn)算起。接收方根據(jù)所有數(shù)據(jù)包的時(shí)間戳計(jì)算RTCP接收報(bào)告中需要的波動。注重：波動值
應(yīng)主要用來比較兩個(gè)用戶或是兩個(gè)時(shí)間段內(nèi)的接收質(zhì)量，并非是絕對的度量。

標(biāo)志位：RTP標(biāo)志位指示一個(gè)新事件的開始。
3．5負(fù)載格式
圖一所示為負(fù)載格式。

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
eventERvolumeduration
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
圖一：命名事件的負(fù)載格式

事件：事件按照3.10到3.14小節(jié)所示編碼。
volume：音量，對于DTMF數(shù)字信號及其它可表示為音頻的事件，本字段描述音頻
的功率級，以dBm0標(biāo)記。功率級范圍從0到-63dBm0。有效的DTMF范圍是從0到-36dBm0
（必須做到）；低于-55dBm0則必須丟棄（TR-TSY-000181,ITU-TQ.24A）。因而，值越大表
明音量越小。這里的值只為DTMF數(shù)字定義。對于其它事件，發(fā)送端設(shè)置為零且接收端將
忽略該值。
duration：數(shù)字信號的寬度以時(shí)間戳單元表示。這樣，事件從RTP時(shí)間戳表示的瞬間
開始，并一直持續(xù)到該參數(shù)表示的長度。事件可以已經(jīng)結(jié)束也可以沒有結(jié)束。以8000赫茲
取樣來說，本字段最長可以表示8秒。
E：結(jié)束位若設(shè)置為1表明數(shù)據(jù)包中含有事件的結(jié)束。因此上述的duration參數(shù)即測定
了事件的完整寬度。
發(fā)送方重發(fā)電話音的最后一個(gè)數(shù)據(jù)包才設(shè)置結(jié)束位，而不是第一次傳送時(shí)就發(fā)送。這
就避免了不斷等待測定話音是否真正結(jié)束。接收端的實(shí)現(xiàn)可以使用不同算法產(chǎn)生話音，下面
列出了兩種。第一種，接收端簡單地在音頻播放緩沖區(qū)中時(shí)間戳描述的位置上放置給定寬度
的話音。接收到擴(kuò)充同一音頻的附加數(shù)據(jù)時(shí)，播放緩沖區(qū)中的波形相應(yīng)擴(kuò)展。（但要非凡注
意，播放緩沖區(qū)中的音頻可能要經(jīng)過混合，例如疊加，而不是簡單拷貝。）所以，假如一個(gè)
數(shù)據(jù)包話音持續(xù)時(shí)間長于丟失的間隔時(shí)間且播放延遲很短，則會出現(xiàn)話音間隙。另外一種方
法，接收端可以開始一段音頻并一直播放至接收到有結(jié)束位的數(shù)據(jù)包，下一個(gè)話音可通過不
同的時(shí)間戳值或給定的流失周期區(qū)分。此舉提高了數(shù)據(jù)丟失時(shí)的魯棒性，但假如事件的最后
數(shù)據(jù)包在所有重發(fā)中都丟失了，則會造成話音擴(kuò)展。為了避免話音“粘滯”，必須限制擴(kuò)展
音頻的時(shí)間周期。無論使用哪種算法，話音不應(yīng)該擴(kuò)展到三個(gè)以上數(shù)據(jù)包間隔時(shí)間。稍微的
擴(kuò)展和短暫的暫停一般都是無害的。
R：本字段為以后使用而保留。發(fā)送方必須將它設(shè)為0，接收端則應(yīng)忽略它。
3．6發(fā)送事件數(shù)據(jù)包
音源一識別到事件就應(yīng)開始發(fā)送事件數(shù)據(jù)包，之后按每50毫秒或根據(jù)會話中使用的音
頻編解碼器的時(shí)間間隔連續(xù)發(fā)送。（由于時(shí)間戳中包含了時(shí)間信息，發(fā)送方無須為了保持精
確的inter-event次數(shù)而維持精確的事件數(shù)據(jù)包間隔）
Q.24[5]，表A-1，指出了所有測量治理使用40毫秒的最小信號寬度，和不低于93毫
秒的信令速率（話音及中止）。
若一個(gè)事件延續(xù)了一個(gè)周期以上，信號源產(chǎn)生事件將發(fā)送一個(gè)新的事件數(shù)據(jù)包，其RTP
時(shí)間戳值為事件開始時(shí)刻加上事件已經(jīng)持續(xù)的時(shí)間。（RTP序列號按每個(gè)數(shù)據(jù)包依次增一。）
假如最后間隔中沒有新事件發(fā)生，那么事件應(yīng)重發(fā)3次或直到下個(gè)事件被識別。這確保了即
使最后一個(gè)數(shù)據(jù)包丟失，也能正確識別事件的寬度。
為了避免接收端等待事件的完成，DTMF數(shù)字信號及事件按遞增形式發(fā)送。由于一些音
頻長達(dá)2秒，將造成實(shí)際延遲。發(fā)送方并不知道事件長度是否重要，因而需要立即且遞增式
地傳送。假如接收端應(yīng)用不在乎事件持續(xù)時(shí)間，那么這樣的遞增傳輸機(jī)制就避免了延遲。而
有些應(yīng)用則同時(shí)要關(guān)心延遲和事件持續(xù)時(shí)間，如PSTN網(wǎng)關(guān)等。
3．7可靠性
在一個(gè)事件中，RTP事件負(fù)載格式提供了事件的遞增更新。錯誤恢復(fù)性取決于接收端的
播放延遲。例如，假如播放延遲為120毫秒，包間隙為50毫秒，一行丟失兩個(gè)數(shù)據(jù)包不會
造成接收端產(chǎn)生音頻間隙。
RFC2198[6]中描述的音頻冗余機(jī)制可以用于恢復(fù)數(shù)據(jù)包中丟失的事件。有效的數(shù)據(jù)速
率是每50毫秒r個(gè)64位（32位作為冗余頭，32位作為電話事件負(fù)載）或每秒r個(gè)1280位，
其中r是每個(gè)數(shù)據(jù)包中攜帶的冗余事件數(shù)。r值可在具體實(shí)現(xiàn)時(shí)確定，建議可以使用5。
冗余設(shè)計(jì)中時(shí)間戳的偏移量有14位，在采樣頻率8000Hz下，它可以攜帶2.048秒的電
話事件。網(wǎng)關(guān)能利用其中包含的前一事件的開始時(shí)間精確地重建音頻序列。該機(jī)制可更具彈
性地處理2.048秒或r個(gè)信號的連續(xù)數(shù)據(jù)包丟失。對于前一數(shù)字信號只表示其平均響度。
解碼器將事件負(fù)載視為當(dāng)前音頻幀的高壓縮版。在那種模式下，事件中每個(gè)RTP數(shù)據(jù)
包都會包含當(dāng)前音頻編解碼器對這些數(shù)字信號的翻譯（在G.723.1或G.729提到）以及3.5
小節(jié)提到的表述，加上更早的事件。
這種方法使得那些不理解該格式的啞網(wǎng)關(guān)也能運(yùn)行。參見第1節(jié)。
3．8舉例
一個(gè)典型的RTP數(shù)據(jù)包，用戶正在撥DTMF序列的最后數(shù)字“911”。第一個(gè)數(shù)字信號
200毫秒長（1600個(gè)時(shí)間戳單元）且在0時(shí)間開始，第二個(gè)數(shù)字信號持續(xù)了250毫秒（2000
個(gè)時(shí)間戳單元）且在800毫秒時(shí)開始（6400個(gè)時(shí)間戳單元），第三個(gè)數(shù)字信號在1.4秒處（11200
個(gè)時(shí)間戳單元）被壓縮且數(shù)據(jù)包顯示出是在1.45秒時(shí)（11600個(gè)時(shí)間戳單元）發(fā)出。整個(gè)幀
寬度為50毫秒。為能看清各部分，以下整體上忽視字節(jié)對齊。假定時(shí)間戳和順序號在第一
個(gè)數(shù)字開始設(shè)為0。冗余機(jī)制和電話事件負(fù)載的動態(tài)負(fù)載類型分別為96和97。
3．9接收端使用SDP性能的表述
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V=2PXCCMPTsequencenumber
200009628
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
timestamp
11200
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
synchronizationsource(SSRC)identifier
0x5234a8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FblockPTtimestampoffsetblocklength
197112004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FblockPTtimestampoffsetblocklength
19711200-6400=48004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FBlockPT
097
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
digitERvolumeduration
91071600
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
digitERvolumeduration
110102000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
digitERvolumeduration
10020400
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
圖2：撥“911”之后的RTP數(shù)據(jù)包示例

接收端會指出它可以處理哪個(gè)命名事件，例如，使用SDP協(xié)議（RFC2327[7]）。負(fù)載
格式使用了下列fmtp格式以列出可接受的事件值：
a=fmtp:<format><listofvalues>
這個(gè)值列表由逗號分開成員，它可以是一個(gè)十進(jìn)制數(shù)也可以是由連字符（波折號）隔開
的兩個(gè)十進(jìn)制數(shù)，且第二個(gè)數(shù)字要大于第一個(gè)。數(shù)字或連字符間不答應(yīng)空格。列表無需排序。
例如，假如負(fù)載格式使用負(fù)載類型號為100，可處理DTMF音（事件0到15）和撥號
音和鈴聲，那它在SDP消息中可如下表述：
a=fmtp:1000-15,66,70
因?yàn)樗袑?shí)現(xiàn)必須能接收事件0～15，所以在a=fmtp行上這些事件是可列可不列。
相應(yīng)的MIME參數(shù)是“events”，所以下面的樣本媒體類型定義要和上面SDP的例子相
對應(yīng)：
audio/telephone-event;events="0-11,66,67";rate="8000"
3．10DTMF事件
表1總結(jié)了電話事件負(fù)載格式中與DTMF有關(guān)的命名事件。
Eventencoding(decimal)
_________________________
0--90--9
*10
#11
A--D12--15
Flash16
表1：DTMF命名事件
3．11數(shù)據(jù)調(diào)制解調(diào)器和傳真事件
表3.11總結(jié)了出現(xiàn)在為傳真機(jī)或調(diào)制解調(diào)器服務(wù)的用戶線路中的事件及音頻。音頻
部分如下描述，其具體說明在表7中介紹。
ANS：這種頻率為2100+/-15Hz的話音用于禁止數(shù)據(jù)傳輸中[8,9]的回聲抑止。對于
傳真機(jī)，建議T.30[9]中引用了這種音頻，稱為終端標(biāo)識（CED）應(yīng)答。
/ANS：本信號與ANS相同，但每450+/-25ms會反相。它可以同時(shí)禁止回聲消除和
回聲抑止。在ITU的建議V.25[8]中，本信號表示為ANS（帶上劃線）。
ANSam：改進(jìn)的應(yīng)答話音(ANSam)[3]是頻率為2100+/-1Hz的不帶反相的正弦波信
號，調(diào)幅正弦波為15+/-0.1Hz。假如不需要禁止網(wǎng)絡(luò)回聲消除效，則該音可由調(diào)制解調(diào)器
發(fā)送。
/ANSam：改進(jìn)的帶相位反轉(zhuǎn)的應(yīng)答音(ANSam)[3]是頻率為2100+/-1Hz，反相間隔
為450+/-25ms的正弦波信號，調(diào)幅正弦波為15+/-0.1Hz。話音[10,8]由解調(diào)器[11]和傳真
機(jī)發(fā)送以禁止回聲抑止。
CNG：在撥被呼叫的傳真機(jī)電話號碼之后（應(yīng)答之前），呼叫群III的傳真機(jī)（可選
擇其一）開始發(fā)送1100Hz有斷續(xù)的CalliNG（CNG）音。[9]
CRdi：性能請求（CRd），初始化端[12]，是400毫秒長，頻率為1375Hz和2002
Hz的雙音信號，其后是一段100毫秒，1900Hz的單音信號。“這個(gè)信號要求遠(yuǎn)程站點(diǎn)從電
話模式切換到信息傳輸模式并要求遠(yuǎn)程站點(diǎn)傳輸性能列表。非凡地，Crdi是在呼叫過程中由
初始站點(diǎn)傳送，或在呼叫建立階段由呼叫站點(diǎn)作為對CRe或Mre的響應(yīng)發(fā)送。”
CRdr：CRdr是對Crdi（見上）的應(yīng)答音。它是由400毫秒的頻率為1529Hz和2225
Hz的雙音信號組成，且其后為100毫秒、1900Hz的單音信號。
CRe：性能請求(CRe)[12]是長度400毫秒、頻率1375Hz和2002Hz的雙音信
號，其后為長度100毫秒、頻率400Hz的單音信號。“這個(gè)信號要求遠(yuǎn)程站點(diǎn)從電話模式轉(zhuǎn)
換為信息傳輸模式，并要求遠(yuǎn)程站點(diǎn)傳輸性能列表消息。非凡地，CRe是呼叫建立時(shí)由自動
應(yīng)答站點(diǎn)來發(fā)送。”
CT：“本呼叫音由一串二進(jìn)制信號1或1300Hz的中斷脈沖信號組成，正脈沖
寬度為0.5s到0.7s，負(fù)脈沖寬度為1.5s到2.0s。”不采用V.8呼叫初始化音的調(diào)制解調(diào)器經(jīng)
常使用該音。
Esi：溢出信號(ESi)[12]是400毫秒的頻率為1375Hz和2002Hz的雙音信號，
其后為100毫秒、頻率為980Hz的單音信號。“這個(gè)信號要求遠(yuǎn)程站點(diǎn)從電話模式到信息傳
輸模式。ESi是由初始化站點(diǎn)來發(fā)送。”
Esr：溢出信號(ESr)[12]是400毫秒的頻率為1529Hz和2225Hz的雙音信號，其后
為100毫秒、頻率為1650Hz的單音信號。與ESi相同，但是由應(yīng)答站點(diǎn)發(fā)送。
Mrdi：性能要求（MRd）[12]，初始化方，是400毫秒、頻率為1375Hz和2002
Hz的雙音信號組成，其后為100毫秒、頻率1150Hz的單音信號。“這個(gè)信號要求遠(yuǎn)程站點(diǎn)
從電話模式轉(zhuǎn)換到信息傳輸模式，并要求遠(yuǎn)程站點(diǎn)發(fā)送模式選擇消息。非凡地，MRdi信號
是由初始站點(diǎn)在通話過程中傳送，或是由呼叫站點(diǎn)在呼叫建立時(shí)作為對Mre的應(yīng)答發(fā)送。”
MRdr：MRdr是對MRdi（見上）的應(yīng)答話音。它是由400毫秒的頻率為1529
Hz和2225Hz的雙話音信號組成，且緊隨于100毫秒的頻率為1150Hz的單話音信號。
Mre：它的模式要求(MRe)[12]是指400毫秒的頻率為1375Hz和2002Hz雙話
音信號，，且緊隨于100毫秒的頻率為650Hz的單話音信號。“這個(gè)信號要求從電話模式到
信息傳輸模式的遠(yuǎn)程站點(diǎn)傳輸以及要求遠(yuǎn)程站點(diǎn)進(jìn)行的選擇消息模式的傳輸。通常，MRe
是由專門為呼叫所設(shè)立的自動應(yīng)答站點(diǎn)來發(fā)送。”
V.21：V.21描述了使用頻移鍵控(FSK)的300b/s的全雙工調(diào)制解調(diào)器。它被用于群組
III中傳真機(jī)交換T.30信息。呼叫方在通道1發(fā)送，在通道2接收；應(yīng)答方在通道2發(fā)送，
通道1接收。每一位的值都有不同的音，所以V.21信令包含了所有4種不同的音。
表2總結(jié)了常用過程：
過程標(biāo)識
___________________________________________________
V.25andV.8 ANS
V.25,echocancellerdisabled ANS,/ANS,ANS,/ANS
V.8 ANSam
V.8,echocancellerdisabled /ANSam

表2：V.x建議中ANS,ANSamand/ANSam的使用
事件編碼（十進(jìn)制）
___________________________________________________
Answertone(ANS)32
/ANS33
ANSam34
/ANSam35
Callingtone(CNG)36
V.21channel1,"0"bit37
V.21channel1,"1"bit38
V.21channel2,"0"bit39
V.21channel2,"1"bit40
CRdi41
CRdr42
CRe43
ESi44
ESr45
MRdi46
MRdr47
MRe48
CT49
表3：數(shù)據(jù)和傳真的命名事件
3．12線路事件
表4概述了在用戶線路中可能出現(xiàn)的事件和音頻。
ITU建議E.182[13]定義了何時(shí)使用哪種音。它下面定義了呼叫者接聽到的標(biāo)準(zhǔn)音：
撥號音：交換機(jī)預(yù)備接收地址信息。
PABX內(nèi)部撥號音：PABX預(yù)備接收地址信息。
非凡撥號音：類似于撥號音，但呼叫者線路處于非凡條件，例如呼叫轉(zhuǎn)移或語音信件就
緒（如“Stutter撥號音”）。
二次撥號音：網(wǎng)絡(luò)已經(jīng)接受地址信息，但還需要額外信息。
鈴音：該事件引發(fā)接收器產(chǎn)生警示信號（“響鈴”）。受話方可以自己設(shè)置實(shí)際使用的振
鈴聲或用其它方式通知呼叫到達(dá)。（這不同于下面所提的呼叫方聽到的振鈴音。）
振鈴音：呼叫已發(fā)到受話方且呼叫信號（振鈴）正被傳送到被呼叫方。這種話音也稱為
“回響”。
非凡振鈴音：一種非凡服務(wù)，諸如呼叫轉(zhuǎn)移或呼叫等待，撥號完后激活。
忙音：被呼叫電話號碼正忙。
擁塞音：呼叫必須的設(shè)施暫時(shí)無法使用。
呼叫卡服務(wù)音：呼叫卡服務(wù)音由60毫秒的941Hz和1477Hz的話音疊加組成（DTMF
'#'），其后為940毫秒的350Hz和440Hz的話音（U.S.撥號音），按200毫秒定時(shí)成指數(shù)
衰減。
非凡信息音：受話方無法接通，但原因既不是“忙”也不是“擁塞”。為了便于使用自
動設(shè)備，本話音在所有呼叫失敗通知前使用。
安慰音：呼叫正在進(jìn)行。在長時(shí)轉(zhuǎn)撥延時(shí)中使用，例如，國際呼叫連接。
保持音：呼叫方處于保持狀態(tài)。
錄音音：呼叫方已經(jīng)被連接到自動應(yīng)答服務(wù)且被提示開始講話。
呼叫方等待音：被呼叫站點(diǎn)忙，但提供了呼叫等待服務(wù)。
收費(fèi)音：收費(fèi)電話一端的呼叫方被提醒支付硬幣。
積極指示音：附加服務(wù)啟動。
消極指示音：無法啟動附加服務(wù)。
掛斷警告音：呼叫方已經(jīng)掛斷設(shè)備超過一段時(shí)間。
被呼叫方或接聽方在通話中還可以收到以下話音：
呼叫等待音：另一用戶想接通本用戶。
警告音：呼叫正被錄音。本話音并非必需。
侵?jǐn)_音：呼叫被監(jiān)聽，例如被接線員。
CPE提示信號：一種提示設(shè)備有帶內(nèi)FSK數(shù)據(jù)到達(dá)的信號音。CPE提示信號是2130
Hz和2750Hz音的組合，答應(yīng)0.5%的誤差和80到0.80ms的寬度。CPE提示信號與ADSI
服務(wù)以及呼叫等待標(biāo)識服務(wù)[14]共同使用。
接線員可以聽到下列信號音：
收費(fèi)電話識別音：一個(gè)人正在使用收費(fèi)電話呼叫或接聽（因此收集該呼叫是不妥的）。
Eventencoding(decimal)
_____________________________________________
OffHook64
OnHook65
Dialtone66
PABXinternaldialtone67
Specialdialtone68
Seconddialtone69
Ringingtone70
Specialringingtone71
Busytone72
Congestiontone73
Specialinformationtone74
Comforttone75
Holdtone76
Recordtone77
Callerwaitingtone78
Callwaitingtone79
Paytone80
Positiveindicationtone81
Negativeindicationtone82
Warningtone83
Intrusiontone84
Callingcardservicetone85
Payphonerecognitiontone86
CPEalertingsignal(CAS)87
Off-hookwarningtone88
Ring89
表4：E.182線路事件
3．13擴(kuò)展線路事件
表5總結(jié)了可能出現(xiàn)在用戶線路中的特定區(qū)域（國家）事件和信號音。
3．14信息通路事件
表6總結(jié)了可能出現(xiàn)在主干的事件和話音。應(yīng)注重的是主干也會傳送線路事件，因?yàn)?br />MF信令不包括逆向信號（3.12小節(jié)）。
過渡性ABCD：在數(shù)字主干中使用的4位信號。對于N狀態(tài)信令，使用第一個(gè)N值
被。

Eventencoding(decimal)
___________________________________________________
Acceptancetone96
Confirmationtone97
Dialtone,recall98
Endofthreepartyservicetone99
Facilitiestone100
Linelockouttone101
NumberunoBTainabletone102
Offeringtone103
Permanentsignaltone104
PReemptiontone105
Queuetone106
Refusaltone107
Routetone108
Validtone109
Waitingtone110
Warningtone(endofperiod)111
WarningTone(Piptone)112
表5：特定地區(qū)（國家）線路事件
T1ESF（擴(kuò)展的超級幀格式）答應(yīng)2，4和16狀態(tài)信令位選項(xiàng)。這些信令位被命名為A、
B、C和D。當(dāng)使用ESFT1幀時(shí)，信令信息作為幀中的強(qiáng)制位6，12，18以及24發(fā)送。AD4
超級幀只用A和B位發(fā)送4狀態(tài)信令。當(dāng)使用CEPTE1結(jié)構(gòu)時(shí)，每幀發(fā)送雙通道16狀態(tài)
信令，所有信令都在時(shí)間槽16中攜帶。
由于這些是狀態(tài)信息而不是改變信令，實(shí)現(xiàn)中應(yīng)該使用下面的三倍冗余機(jī)制，類似于
ITU-TRec.I.366.2[16]中規(guī)定的AnnexL。發(fā)送時(shí)，相同的ABCD信息以5ms為間隔發(fā)送3
次。若在此期間其它信息發(fā)送，也要繼續(xù)。在經(jīng)過一段時(shí)間沒有任何改變后，ABCD信息每
隔5秒發(fā)送一次。
閃爍：一種短暫的轉(zhuǎn)換，典型的是以120－290ms為周期，從掛機(jī)到摘機(jī)再到掛機(jī)，
由接入交換機(jī)使用表示呼叫地址信令可以繼續(xù)。
來電捕捉：呼叫嘗試（摘機(jī)）的來到信息指示。

Eventencoding(decimal)
__________________________________________________
MF0...9128...137
MFK0orKP(start-of-pulsing)138
MFK1139
MFK2140
MFS0toST(end-of-pulsing)141
MFS1...S3142...143
ABCDsignaling(seebelow)144...159
Wink160
WinKOFf161
Incomingseizure162
Seizure163
Unseizecircuit164
Continuitytest165
Defaultcontinuitytone166
Continuitytone(singletone)167
Continuitytestsend168
Continuityverified170
Loopback171
Oldmilliwatttone(1000Hz)172
Newmilliwatttone(1004Hz)173

表6：信息通路事件

Seizure：由應(yīng)答交換機(jī)捕捉，對輸出捕捉的響應(yīng)。
Unseize電路：呼叫結(jié)束時(shí)從摘機(jī)到掛機(jī)的電路轉(zhuǎn)換。
閃爍關(guān)閉：一種短暫轉(zhuǎn)換，典型的是以100-350ms為周期，從摘機(jī)到掛機(jī)再回到摘
機(jī)的，在接線員服務(wù)主干使用。
連續(xù)音發(fā)送：一種頻率為2010Hz的信號音。
連續(xù)音檢測：一種頻率為2010Hz的信號音。
連續(xù)測試發(fā)送：一種頻率為1780Hz的信號音由呼叫交換機(jī)發(fā)送。假如被叫交換機(jī)
接收到，則返回“連續(xù)檢驗(yàn)”話音。
連續(xù)驗(yàn)證：一種頻率為2010Hz的音。它是用于雙音過程的一種應(yīng)答音。
4．用于電話話音的RTP負(fù)載格式
4．1介紹
第3節(jié)中介紹了通過名稱描述信號音和事件方法，這里介紹另外一種通過波形屬性描述
的方法。非凡是由于它不依靠于識別寬度和暫停，所以識別速度要比命名信號快。
對于撥號音、鈴音、忙音、擁塞音，非凡通知音以及其它非凡信號音，如收費(fèi)電話識別
音、呼叫等待或錄音話音等還沒有獨(dú)立的國際標(biāo)準(zhǔn)。然而，各地區(qū)的信號音都有很多共同的
特性[17]：

? 電話音包括單音，兩三種附加音，或者雙音調(diào)制。（幾乎所有電話音都用雙頻；
只有匈牙利的“非凡撥號音”為三頻。）混和音都有相同的振幅且無衰減。
? 電話事件的信號音在25Hz（安哥拉鈴音）到1800Hz的范圍內(nèi)。CED是最高的
使用頻率為2100Hz。電話頻率范圍限制在3400Hz之內(nèi)。（鋼琴的音頻范圍可
從27.5Hz到4186Hz。）
? 調(diào)制頻率范圍在15Hz（ANSam音）到480Hz（牙買加）之間。非整數(shù)頻率只
有162/3和331/3Hz。（這些分?jǐn)?shù)頻率來自早期的交流電網(wǎng)頻率。）
? 非連續(xù)性音寬度不小于4秒。
? ITU建議E.180[18]指出不同的電話公司要求音準(zhǔn)在0.5到1.5%之間。建議提出
頻差為1％。
4．2公共電話話音信號實(shí)例
作為對實(shí)現(xiàn)者的輔助，表7中概述了一些公共話音。標(biāo)明“ITU...”的行中表示這是E.180
[18]的建議。注重這里并沒有對這些音以非凡指導(dǎo)。表中符號“＋”表示沒有調(diào)制的附加音，
“*”則表示調(diào)幅。一些音的含義在3.12小節(jié)或3.11小節(jié)（對V.21而言）中有介紹。

音名 頻率 開周期閉周期
______________________________________________________
CNG11000.53.0
V.25CT13000.52.0
CED21003.3--
ANS21003.3--
ANSam2100*153.3--
V.21"0"bit,ch.111800.00333
V.21"1"bit,ch.19800.00333
V.21"0"bit,ch.218500.00333
V.21"1"bit,ch.216500.00333
ITUdialtone425----
U.S.dialtone350+440----
______________________________________________________
ITUringingtone4250.67--1.53--5
U.S.ringingtone440+4802.04.0
ITUbusytone425
U.S.busytone480+6200.50.5
______________________________________________________
ITUCongestiontone425
U.S.congestiontone480+6200.250.25
表7：電話音實(shí)例

4．3RTP頭字段的使用
時(shí)間戳：RTP時(shí)間戳反映了當(dāng)前數(shù)據(jù)包的采樣點(diǎn)。在3.5小節(jié)中討論事件寬度就從該
時(shí)刻開始。
4．4負(fù)載格式
根據(jù)前面描述的特征，本文定義了稱之為“信號音”的RTP負(fù)載格式，它可表示單頻
或多頻信號音。（相應(yīng)的MIME類型為“audio/tone”。）默認(rèn)時(shí)間戳頻率為8000Hz，但也可
定義其它頻率。注重的是時(shí)間戳頻率不影響頻率的解釋，只影響寬度。
與當(dāng)前慣例一致，這種負(fù)載格式?jīng)]有靜態(tài)負(fù)載類型編號，而使用動態(tài)和帶外方式建立的
RTP負(fù)載類型。
這在圖3中說明。
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
modulationTvolumeduration
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RRRRfrequencyRRRRfrequency
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RRRRfrequencyRRRRfrequency
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RRRRfrequencyRRRRfrequency
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
圖3：信號音負(fù)載格式
負(fù)載包括以下字段：
調(diào)制：用赫茲表示的調(diào)制頻率。該字段是9位無符號整數(shù)，答應(yīng)頻率一直到511Hz。
假如沒有調(diào)制，該字段值為0。
T：假如“T”位設(shè)為1，調(diào)制頻率要被3除。否則，就使用本來的調(diào)制頻率。由于實(shí)
際中還在使用162/3Hz這樣的調(diào)制頻率，該位答應(yīng)調(diào)制頻率精確到1/3Hz。
音量：話音的功率級別，以dBm0標(biāo)記，范圍從0到-63dBm0。（注重：對于數(shù)字信
號發(fā)生器首選的范圍是從-8dBm0到-3dBm0。）
寬度：話音的寬度，用時(shí)間戳單元度量。話音由RTP時(shí)間戳標(biāo)志的瞬間開始，持續(xù)
到整個(gè)寬度值。寬度的定義與基于采樣的編譯碼器一致，時(shí)間戳描述了第一個(gè)樣本的采樣點(diǎn)。
頻率：增加的信號音頻率，以赫茲為單位，以12位無符號整數(shù)發(fā)送。字段的長度足
夠表示到4095Hz，超出了電話網(wǎng)的范圍。0值表示靜音。單音可包含任何數(shù)目的頻率。
R：本字段為保留字段。發(fā)送方必須將它設(shè)為0，接收端則應(yīng)忽略它。
4．5可靠性
本負(fù)載格式采用3.7小節(jié)中描述的可靠性機(jī)制。
5．信號音合并和命名事件
利用RFC2198中指定方法，可以把第3及第4節(jié)的負(fù)載格式組合為單獨(dú)的負(fù)載。例如
圖4中的RTP數(shù)據(jù)包由兩個(gè)“信號音”和一個(gè)“電話事件”負(fù)載合并而成。負(fù)載類型可分
別選97和98，采樣頻率8000Hz。這里冗余格式動態(tài)負(fù)載類型為96。
數(shù)據(jù)包說明了美國鈴音的瞬態(tài)圖，1.5秒（12000個(gè)時(shí)間戳單元）即到達(dá)2.0/4.0第二節(jié)
拍的第二個(gè)正脈沖，整個(gè)鈴音周期為7.5秒（60000個(gè)時(shí)間戳單元）。第二節(jié)拍下頻率為440
+480Hz的話音開始第48000個(gè)RTP時(shí)間戳處。后面是4秒的靜音。但由于RFC2198只用
14位偏移，只能表示出2.05秒（16383個(gè)時(shí)間戳單元）。盡管信號音序列不完整，發(fā)送方也
可以判定這的確是回響，從而包括了響應(yīng)的命名事件。
6．MIME注冊
6．1audio/telephone-event
MIME媒體類型名：audio
MIME子類型名：telephone-event
必需參數(shù)：無
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VPXCCMPTsequencenumber
200009631
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
timestamp
48000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
synchronizationsource(SSRC)identifier
0x5234a8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FblockPTtimestampoffsetblocklength
198163834
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FblockPTtimestampoffsetblocklength
197163838
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FBlockPT
097
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
event=ring00volume=0duration=28383
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
modulation=00volume=63duration=16383
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0000frequency=00000frequency=0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
modulation=00volume=5duration=12000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0000frequency=4400000frequency=480
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
圖4：一個(gè)組合了話音和事件的RTP數(shù)據(jù)包
可選參數(shù)：“events”參數(shù)列出了實(shí)現(xiàn)支持的事件。表中的多個(gè)事件元素由逗號分隔。
每個(gè)元素是單個(gè)整數(shù)或由連字符分開的兩個(gè)整數(shù)。參數(shù)間不答應(yīng)空白。整數(shù)指出了實(shí)現(xiàn)支持
的事件號。所有的實(shí)現(xiàn)都必須支持事件0～15，所以假如執(zhí)行只支持這些事件的話，參數(shù)表
就可以省略。
“rate”參數(shù)描述了采樣速率，以赫茲為單位。數(shù)值可寫為浮點(diǎn)或整數(shù)形式。若忽略
不寫，則為默認(rèn)值8000Hz。
編碼考慮：這種類型只定義為通過RTP[1]傳送。
安全考慮：見本文中的“安全考慮“部分（第7節(jié)）。
互操作性考慮：無
已發(fā)行規(guī)范：本文
使用該媒體的應(yīng)用：電話事件音頻子類型支持在Internet上傳輸電話系統(tǒng)事件。
附加信息：
1．幻數(shù)：N/A
2．文件擴(kuò)展名：N/A
3．Macintosh的文件類型代碼：N/A
6．2audio/tone
MIME媒體類型名：audio
MIME子類型名：tone
必需參數(shù)：無
可選參數(shù)：“rate”描述了取樣品的速率，以赫茲為單位。數(shù)值可寫為浮點(diǎn)或整數(shù)形式。
若忽略不寫，則為默認(rèn)值8000Hz。
編碼考慮：只定義為通過RTP[1]傳輸。
安全考慮：見本文中的“安全考慮“部分（第7節(jié)）。
互操作性考慮：無
已發(fā)行規(guī)范：本文
使用該媒體的應(yīng)用：電話音音頻子類型支持純合成話音的傳輸，例如那些常用于當(dāng)前
電話系統(tǒng)中表示呼叫進(jìn)程的電話音。
附加信息：
1．幻數(shù)：N/A
2．文件擴(kuò)展名：N/A
3．Macintosh的文件類型代碼：N/A
7．安全考慮
使用本規(guī)范定義的負(fù)載格式的RTP數(shù)據(jù)包在安全考慮上要依照RTP規(guī)范(RFC1889
[1])，及任何合適的RTP框架（如RFC1890[19]）。這意味著媒體數(shù)據(jù)流的機(jī)密性要通過加
密來實(shí)現(xiàn)。因?yàn)樨?fù)載格式的數(shù)據(jù)壓縮應(yīng)用于端到端場合，所以加密可在壓縮之后進(jìn)行，這樣
兩種操作間就不會有沖突。
這種負(fù)載類型不會引起接收端包處理過程中在計(jì)算復(fù)雜性方面明顯的不一致性，從而避
免了潛在的拒絕服務(wù)。
在早期網(wǎng)絡(luò)采用帶內(nèi)信令且缺乏相應(yīng)的信號音濾波器，3.14小節(jié)中介紹的話音可以用于
收費(fèi)欺詐。
附加安全考慮在RFC2198[6]中描述。
8.IANA考慮
本文定義了兩種新的RTP負(fù)載格式，電話事件和電話音，以及相關(guān)的MIME類型，即
audio/event和audio/tone。
在audio/event類型中，附加的事件必須由IANA注冊。注冊要得到當(dāng)前IETF視聽傳輸
工作組主席的正式批準(zhǔn)，或者假如AVT組已經(jīng)關(guān)閉，也可由傳輸領(lǐng)域主管任命的一個(gè)專家
正式批準(zhǔn)。新事件的含義必須以RFC文檔或者由其它標(biāo)準(zhǔn)化團(tuán)體（如ITU-T）的等價(jià)標(biāo)準(zhǔn)
化文檔形式發(fā)行。
鳴謝
對Megaco工作組的建議表示萬分感激。具體建議和意見由FredBurg,，SteveCasner，
FatihErdin，BillFoster，MikeFox，GunnarHellstrom，TerryLyons，SteveMagnell,，Vern
PaxsonandColinPerkins提供。
作者地址
HenningSchulzrinne
Dept.ofComputerScience
ColumbiaUniversity
1214AmsterdamAvenue
NewYork,NY10027
USA
EMail:schulzrinne@cs.columbia.edu
ScottPetrack
MetaTel
45RumfordAvenue
Waltham,MA02453
USA
EMail:scott.petrack@metatel.com
參考書目
[1]Schulzrinne,H.,Casner,S.,Frederick,R.andV.Jacobson,
"RTP:ATransportProtocolforReal-Timeapplications",RFC
1889,January1996.

[2]Bradner,S.,"KeyWordsforuseinRFCstoIndicateRequirement
Levels",BCP14,RFC2119,March1997.
[3]InternationalTelecommunicationUnion,"Proceduresforstarting
sessionsofdatatransmissionoverthepublicswitchedtelephone
network,"RecommendationV.8,TelecommunicationStandardization
SectorofITU,Geneva,Switzerland,Feb.1998.
[4]R.KocenandT.Hatala,"Voiceoverframerelayimplementation
agreement",ImplementationAgreementFRF.11,FrameRelayForum,
FosterCity,California,Jan.1997.
[5]InternationalTelecommunicationUnion,"Multifrequencypush-
buttonsignalreception,"RecommendationQ.24,Telecommunication
StandardizationSectorofITU,Geneva,Switzerland,1988.
[6]Perkins,C.,Kouvelas,I.,Hodson,O.,Hardman,V.,Handley,M.,
Bolot,J.,Vega-Garcia,A.andS.Fosse-Parisis,"RTPPayload
forRedundantAudioData",RFC2198,September1997.
[7]HandleyM.andV.Jacobson,"SDP:SessionDescriptionProtocol",
RFC2327,April1998.
[8]InternationalTelecommunicationUnion,"Automaticanswering
equipmentandgeneralproceduresforautomaticcallingequipment
onthegeneralswitchedtelephonenetworkincludingprocedures
fordisablingofechocontroldevicesforbothmanuallyand
automaticallyestablishedcalls,"RecommendationV.25,
TelecommunicationStandardizationSectorofITU,Geneva,
Switzerland,Oct.1996.
[9]InternationalTelecommunicationUnion,"Proceduresfordocument
facsimiletransmissioninthegeneralswitchedtelephone
network,"RecommendationT.30,TelecommunicationStandardization
SectorofITU,Geneva,Switzerland,July1996.
[10]InternationalTelecommunicationUnion,"Echocancellers,"
RecommendationG.165,TelecommunicationStandardizationSector
ofITU,Geneva,Switzerland,Mar.1993.
[11]InternationalTelecommunicationUnion,"AmodemOperatingat
datasignalingratesofupto33600bit/sforuSEOnthe
generalswitchedtelephonenetworkandonleasedpoint-to-point
2-wiretelephone-typecircuits,"RecommendationV.34,
TelecommunicationStandardizationSectorofITU,Geneva,
Switzerland,Feb.1998.
[12]InternationalTelecommunicationUnion,"Proceduresforthe
identificationandselectionofcommonmodesofoperation
betweendatacircuit-terminatingequipments(DCEs)andbetween
dataterminalequipments(DTEs)overthepublicswitched
telephonenetworkandonleasedpoint-to-pointtelephone-type
circuits,"RecommendationV.8bis,Telecommunication
StandardizationSectorofITU,Geneva,Switzerland,Sept.1998.

[13]InternationalTelecommunicationUnion,"Applicationoftonesand
recordedannouncementsintelephoneservices,"Recommendation
E.182,TelecommunicationStandardizationSectorofITU,Geneva,
Switzerland,Mar.1998.
[14]Bellcore,"Functionalcriteriafordigitalloopcarrier
systems,"TechnicalRequirementTR-NWT-000057,Telcordia
(formerlyBellcore),Morristown,NewJersey,Jan.1993.
[15]J.G.vanBosse,SignalinginTelecommunicationsNetworks
TelecommunicationsandSignalProcessing,NewYork,NewYork:
Wiley,1998.
[16]InternationalTelecommunicationUnion,"AALtype2service
specificconvergencesublayerfortrunking,"Recommendation
I.366.2,TelecommunicationStandardizationSectorofITU,
Geneva,Switzerland,Feb.1999.
[17]InternationalTelecommunicationUnion,"Varioustonesusedin
nationalnetworks,"RecommendationSupplement2to
RecommendationE.180,TelecommunicationStandardizationSector
ofITU,Geneva,Switzerland,Jan.1994.
[18]InternationalTelecommunicationUnion,"Technical
characteristicsoftonesfortelephoneservice,"Recommendation
Supplement2toRecommendationE.180,Telecommunication
StandardizationSectorofITU,Geneva,Switzerland,Jan.1994.
[19]Schulzrinne,H.,"RTPProfileforAudioandVideoConferences
withMinimalControl",RFC1890,January1996.
版權(quán)說明
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
revokedbytheInternetSocietyoritssuccessorsorassigns.
Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.
致謝
FundingfortheRFCEditorfunctioniscurrentlyprovidedbytheInternetSociety.