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

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

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

摘要
本備忘錄描述了在RTP數據包中傳送雙音多頻(DTMF)信號、其它電話信號音和電話事
件的方法。
目錄
1介紹 2
1．1術語 3
2．語音與事件 3
3．用于命名電話事件的RTP負載格式 4
3．1介紹 4
3．2同時產生音頻和事件 4
3．3事件類型 4
3．4RTP頭用法 5
3．5負載格式 5
3．6發送事件數據包 6
3．7可靠性 6
3．8舉例 7
3．9接收端使用SDP性能的表述 7
3．10DTMF事件 8
3．11數據調制解調器和傳真事件 8
3．12線路事件 10
3．13擴展線路事件 12
3．14信息通路事件 12
4．用于電話話音的RTP負載格式 13
4．1介紹 13
4．2公共電話話音信號實例 14
4．3RTP頭字段的使用 15
4．4負載格式 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
版權說明 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術語
本文中的關鍵字“必須”，“必須不”，“要求的”，“應該”，“不應該”，“會”，“不會”，“建
議”，“或許”，“可選的”在RFC2119中解釋。
2．語音與事件
網關處理DTMF數字信號和事件的方式有兩種。第一種，它可以簡單測量聲音波段信
號的頻率成分并將這些信息傳送到RTP接收端（第四節）。在這種模式下，網關僅從語音信
號中簡單辨別話音，無需鑒別話音的含義。用于PSTN且人可感知的所有話音信號都是一系
列簡單正弦波的組合，經過疊加或調制。（至少有一種話音使用了周期性相位反轉，如在話
音線路上指示數據傳輸的ANSamtone[3]。）
第二種，網關可以識別電話音并將它們譯為名稱，如振鈴或忙音。接收端即產生電話音
信號或其它相應的信號描述。通常，由于信號識別依賴開/關模式或個別電話音序列，這種
識別會花幾秒鐘。另一方面，網關可以訪問產生電話音的真實信令信息，因此能夠立刻生成
RTP包，無需繞開聲音信號。
在電話網絡中，電話音產生于不同的地方，取決于開關技術和音調特性。這就決定了當
一個人給國外打電話時所聽見的是她所熟悉的本地音調還是被叫國使用的音調。
對于模擬線路而言，撥號音通常是通過本地開關產生的。ISDN終端可以在本地產生撥
號音，然后發送包含所撥數字的Q.931SETUP消息。如果終端只發送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
赫茲，但時鐘頻率可在動態分配負載類型時重定義。
這里描述的負載格式與VoiceoverFrameRelayImplementationAgreement[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．4RTP頭用法
時間戳：RTP時間戳反映了當前數據包的測量點。3.5小節描述的事件持續時間就從該
點算起。接收方根據所有數據包的時間戳計算RTCP接收報告中需要的波動。注意：波動值
應主要用來比較兩個用戶或是兩個時間段內的接收質量，并非是絕對的度量。

標志位：RTP標志位指示一個新事件的開始。
3．5負載格式
圖一所示為負載格式。

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|event|E|R|volume|duration|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
圖一：命名事件的負載格式

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

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

表2：V.x建議中ANS,ANSamand/ANSam的使用
事件編碼（十進制）
___________________________________________________
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：數據和傳真的命名事件
3．12線路事件
表4概述了在用戶線路中可能出現的事件和音頻。
ITU建議E.182[13]定義了何時使用哪種音。它下面定義了呼叫者接聽到的標準音：
撥號音：交換機準備接收地址信息。
PABX內部撥號音：PABX準備接收地址信息。
特殊撥號音：類似于撥號音，但呼叫者線路處于特殊條件，例如呼叫轉移或語音信件就
緒（如“Stutter撥號音”）。
二次撥號音：網絡已經接受地址信息，但還需要額外信息。
鈴音：該事件引發接收器產生警示信號（“響鈴”）。受話方可以自己設置實際使用的振
鈴聲或用其它方式通知呼叫到達。（這不同于下面所提的呼叫方聽到的振鈴音。）
振鈴音：呼叫已發到受話方且呼叫信號（振鈴）正被傳送到被呼叫方。這種話音也稱為
“回響”。
特殊振鈴音：一種特殊服務，諸如呼叫轉移或呼叫等待，撥號完后激活。
忙音：被呼叫電話號碼正忙。
擁塞音：呼叫必須的設施暫時無法使用。
呼叫卡服務音：呼叫卡服務音由60毫秒的941Hz和1477Hz的話音疊加組成（DTMF
'#'），其后為940毫秒的350Hz和440Hz的話音（U.S.撥號音），按200毫秒定時成指數
衰減。
特殊信息音：受話方無法接通，但原因既不是“忙”也不是“擁塞”。為了便于使用自
動設備，本話音在所有呼叫失敗通知前使用。
安慰音：呼叫正在進行。在長時轉撥延時中使用，例如，國際呼叫連接。
保持音：呼叫方處于保持狀態。
錄音音：呼叫方已經被連接到自動應答服務且被提示開始講話。
呼叫方等待音：被呼叫站點忙，但提供了呼叫等待服務。
收費音：收費電話一端的呼叫方被提醒支付硬幣。
積極指示音：附加服務啟動。
消極指示音：無法啟動附加服務。
掛斷警告音：呼叫方已經掛斷設備超過一段時間。
被呼叫方或接聽方在通話中還可以收到以下話音：
呼叫等待音：另一用戶想接通本用戶。
警告音：呼叫正被錄音。本話音并非必需。
侵擾音：呼叫被監聽，例如被接線員。
CPE提示信號：一種提示設備有帶內FSK數據到達的信號音。CPE提示信號是2130
Hz和2750Hz音的組合，允許0.5%的誤差和80到0.80ms的寬度。CPE提示信號與ADSI
服務以及呼叫等待標識服務[14]共同使用。
接線員可以聽到下列信號音：
收費電話識別音：一個人正在使用收費電話呼叫或接聽（因此收集該呼叫是不妥的）。
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擴展線路事件
表5總結了可能出現在用戶線路中的特定區域（國家）事件和信號音。
3．14信息通路事件
表6總結了可能出現在主干的事件和話音。應注意的是主干也會傳送線路事件，因為
MF信令不包括逆向信號（3.12小節）。
過渡性ABCD：在數字主干中使用的4位信號。對于N狀態信令，使用第一個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：特定地區（國家）線路事件
T1ESF（擴展的超級幀格式）允許2，4和16狀態信令位選項。這些信令位被命名為A、
B、C和D。當使用ESFT1幀時，信令信息作為幀中的強制位6，12，18以及24發送。AD4
超級幀只用A和B位發送4狀態信令。當使用CEPTE1結構時，每幀發送雙通道16狀態
信令，所有信令都在時間槽16中攜帶。
由于這些是狀態信息而不是改變信令，實現中應該使用下面的三倍冗余機制，類似于
ITU-TRec.I.366.2[16]中規定的AnnexL。發送時，相同的ABCD信息以5ms為間隔發送3
次。若在此期間其它信息發送，也要繼續。在經過一段時間沒有任何改變后，ABCD信息每
隔5秒發送一次。
閃爍：一種短暫的轉換，典型的是以120－290ms為周期，從掛機到摘機再到掛機，
由接入交換機使用表示呼叫地址信令可以繼續。
來電捕獲：呼叫嘗試（摘機）的來到信息指示。

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：由應答交換機捕捉，對輸出捕捉的響應。
Unseize電路：呼叫結束時從摘機到掛機的電路轉換。
閃爍關閉：一種短暫轉換，典型的是以100-350ms為周期，從摘機到掛機再回到摘
機的，在接線員服務主干使用。
連續音發送：一種頻率為2010Hz的信號音。
連續音檢測：一種頻率為2010Hz的信號音。
連續測試發送：一種頻率為1780Hz的信號音由呼叫交換機發送。如果被叫交換機
接收到，則返回“連續檢驗”話音。
連續驗證：一種頻率為2010Hz的音。它是用于雙音過程的一種應答音。
4．用于電話話音的RTP負載格式
4．1介紹
第3節中介紹了通過名稱描述信號音和事件方法，這里介紹另外一種通過波形屬性描述
的方法。特別是由于它不依賴于識別寬度和暫停，所以識別速度要比命名信號快。
對于撥號音、鈴音、忙音、擁塞音，特殊通知音以及其它特殊信號音，如收費電話識別
音、呼叫等待或錄音話音等還沒有獨立的國際標準。然而，各地區的信號音都有很多共同的
特性[17]：

? 電話音包括單音，兩三種附加音，或者雙音調制。（幾乎所有電話音都用雙頻；
只有匈牙利的“特殊撥號音”為三頻。）混和音都有相同的振幅且無衰減。
? 電話事件的信號音在25Hz（安哥拉鈴音）到1800Hz的范圍內。CED是最高的
使用頻率為2100Hz。電話頻率范圍限制在3400Hz之內。（鋼琴的音頻范圍可
從27.5Hz到4186Hz。）
? 調制頻率范圍在15Hz（ANSam音）到480Hz（牙買加）之間。非整數頻率只
有162/3和331/3Hz。（這些分數頻率來自早期的交流電網頻率。）
? 非連續性音寬度不小于4秒。
? ITU建議E.180[18]指出不同的電話公司要求音準在0.5到1.5%之間。建議提出
頻差為1％。
4．2公共電話話音信號實例
作為對實現者的輔助，表7中概述了一些公共話音。標明“ITU...”的行中表示這是E.180
[18]的建議。注意這里并沒有對這些音以特殊指導。表中符號“＋”表示沒有調制的附加音，
“*”則表示調幅。一些音的含義在3.12小節或3.11小節（對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：電話音實例

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|modulation=0|0|volume=63|duration=16383|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0000|frequency=0|0000|frequency=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|modulation=0|0|volume=5|duration=12000|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0000|frequency=440|0000|frequency=480|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
圖4：一個組合了話音和事件的RTP數據包
可選參數：“events”參數列出了實現支持的事件。表中的多個事件元素由逗號分隔。
每個元素是單個整數或由連字符分開的兩個整數。參數間不允許空白。整數指出了實現支持
的事件號。所有的實現都必須支持事件0～15，所以如果執行只支持這些事件的話，參數表
就可以省略。
“rate”參數描述了采樣速率，以赫茲為單位。數值可寫為浮點或整數形式。若忽略
不寫，則為默認值8000Hz。
編碼考慮：這種類型只定義為通過RTP[1]傳送。
安全考慮：見本文中的“安全考慮“部分（第7節）。
互操作性考慮：無
已發行規范：本文
使用該媒體的應用：電話事件音頻子類型支持在Internet上傳輸電話系統事件。
附加信息：
1．幻數：N/A
2．文件擴展名：N/A
3．Macintosh的文件類型代碼：N/A
6．2audio/tone
MIME媒體類型名：audio
MIME子類型名：tone
必需參數：無
可選參數：“rate”描述了取樣品的速率，以赫茲為單位。數值可寫為浮點或整數形式。
若忽略不寫，則為默認值8000Hz。
編碼考慮：只定義為通過RTP[1]傳輸。
安全考慮：見本文中的“安全考慮“部分（第7節）。
互操作性考慮：無
已發行規范：本文
使用該媒體的應用：電話音音頻子類型支持純合成話音的傳輸，例如那些常用于當前
電話系統中表示呼叫進程的電話音。
附加信息：
1．幻數：N/A
2．文件擴展名：N/A
3．Macintosh的文件類型代碼：N/A
7．安全考慮
使用本規范定義的負載格式的RTP數據包在安全考慮上要依照RTP規范(RFC1889
[1])，及任何合適的RTP框架（如RFC1890[19]）。這意味著媒體數據流的機密性要通過加
密來實現。因為負載格式的數據壓縮應用于端到端場合，所以加密可在壓縮之后進行，這樣
兩種操作間就不會有沖突。
這種負載類型不會引起接收端包處理過程中在計算復雜性方面明顯的不一致性，從而避
免了潛在的拒絕服務。
在早期網絡采用帶內信令且缺乏相應的信號音濾波器，3.14小節中介紹的話音可以用于
收費欺詐。
附加安全考慮在RFC2198[6]中描述。
8.IANA考慮
本文定義了兩種新的RTP負載格式，電話事件和電話音，以及相關的MIME類型，即
audio/event和audio/tone。
在audio/event類型中，附加的事件必須由IANA注冊。注冊要得到當前IETF視聽傳輸
工作組主席的正式批準，或者如果AVT組已經關閉，也可由傳輸領域主管任命的一個專家
正式批準。新事件的含義必須以RFC文檔或者由其它標準化團體（如ITU-T）的等價標準
化文檔形式發行。
鳴謝
對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.
版權說明
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.