組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者： 吳晶（wing_wujing@sina.com）李超（licc_li@sina.com）
譯文發布時間：2001-6-27
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須保留本文檔的翻譯及版權信息。



Network Working Group                                      H. Schulzrinne
Request for Comments: 2833                            Columbia University
Category: Standards Track                                      S. Petrack
                                                            MetaTel
                                                            May 2000


用于DTMF數字信號、電話音和電話信號的RTP負載格式

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

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

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

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

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

標志位：RTP標志位指示一個新事件的開始。
3．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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     event     |E|R| volume    |          duration             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
圖一：命名事件的負載格式

事件：事件按照3.10到3.14小節所示編碼。
volume：音量，對于DTMF數字信號及其它可表示為音頻的事件，本字段描述音頻
的功率級，以dBm0標記。功率級范圍從0 到-63 dBm0。有效的DTMF范圍是從0 到-36 dBm0
（必須做到）；低于-55 dBm0則必須丟棄（TR-TSY-000181,ITU-T Q.24A）。因而，值越大表
明音量越小。這里的值只為DTMF數字定義。對于其它事件，發送端設置為零且接收端將
忽略該值。
duration：數字信號的寬度以時間戳單元表示。這樣，事件從RTP時間戳表示的瞬間
開始，并一直持續到該參數表示的長度。事件可以已經結束也可以沒有結束。以8000赫茲
取樣來說，本字段最長可以表示8秒。
E：結束位若設置為1表明數據包中含有事件的結束。因此上述的duration參數即測定
了事件的完整寬度。
發送方重發電話音的最后一個數據包才設置結束位，而不是第一次傳送時就發送。這
就避免了不斷等待測定話音是否真正結束。接收端的實現可以使用不同算法產生話音，下面
列出了兩種。第一種，接收端簡單地在音頻播放緩沖區中時間戳描述的位置上放置給定寬度
的話音。接收到擴充同一音頻的附加數據時，播放緩沖區中的波形相應擴展。（但要特別注
意，播放緩沖區中的音頻可能要經過混合，例如疊加，而不是簡單拷貝。）所以，如果一個
數據包話音持續時間長于丟失的間隔時間且播放延遲很短，則會出現話音間隙。另外一種方
法，接收端可以開始一段音頻并一直播放至接收到有結束位的數據包，下一個話音可通過不
同的時間戳值或給定的流失周期區分。此舉提高了數據丟失時的魯棒性，但如果事件的最后
數據包在所有重發中都丟失了，則會造成話音擴展。為了避免話音“粘滯”，必須限制擴展
音頻的時間周期。無論使用哪種算法，話音不應該擴展到三個以上數據包間隔時間。輕微的
擴展和短暫的暫停一般都是無害的。
R：本字段為以后使用而保留。發送方必須將它設為0，接收端則應忽略它。
3．6發送事件數據包
音源一識別到事件就應開始發送事件數據包，之后按每50毫秒或根據會話中使用的音