什麼是DTMF訊號傳送方式？
在自動語音系統輸入帳戶號碼、在電話會議輸入入會密碼、在對講機輸入開門碼，靠的都是同一套按鍵音訊號。這套訊號原本設計為在模擬電話線上以聲音傳送，換到IP網絡之後卻多出幾種互不相容的傳送方式，配置不一致就會出現按鍵無反應或數字重複。本頁說明其頻率基礎、三種傳送方式的分別，以及實際排查方向。
DTMF音頻訊號的頻率組合與時長要求
DTMF（Dual-Tone Multi-Frequency，雙音多頻）是一套在話音頻帶內傳送按鍵訊息的訊號系統，由貝爾實驗室開發，商標名稱為Touch-Tone，其後由ITU-T以Q.23建議書標準化。它的設計原則是：每一個按鍵不是單一頻率，而是兩個正弦波同時發出，一個來自低頻組（代表鍵盤的行），一個來自高頻組（代表鍵盤的列）。
低頻組為697 Hz、770 Hz、852 Hz、941 Hz；高頻組為1209 Hz、1336 Hz、1477 Hz、1633 Hz。四行乘四列共可表示十六個訊號，即數字0至9、符號「*」與「#」，以及較少使用的字母A至D。舉例而言，按下「1」鍵時，話機會同時發出697 Hz與1209 Hz兩個音，接收端以濾波或數位訊號處理方式檢出這一對頻率，即可還原按鍵。
採用兩個頻率疊加而非單一頻率，是為了避免人聲或線路雜音被誤判為按鍵——同時出現兩個特定頻率且維持一段時間的機會遠低於單一頻率。另一項設計考慮是DTMF所用的頻率刻意與交換機之間的多頻路由訊號（例如MF/R1、R2）不同，避免用戶話機干擾局間的路由與交換。
時長方面，RFC 4733引述ITU-T Q.24建議書附表A-1的調查結果：受訪國家的舊式交換設備一般要求最短可辨識訊號長度為40毫秒、訊號之間最短停頓為40毫秒，最高撥號速率視國家而定為每秒8至10位。人手按鍵產生的訊號通常遠長於此，因此在正常使用中不會觸及下限；但由設備自動送出的快速數字串，就有可能因為音長或間隔不足而被接收端漏收。
IP電話環境下的三種傳送方式
模擬電話線只有一條音頻通道，DTMF只能以聲音形式傳送，沒有選擇問題。IP電話則把訊令（呼叫建立與控制）與媒體（語音封包）分開處理，於是按鍵訊息出現三條可走的路徑，兩端必須事先協商採用同一種，否則按鍵不會被對方認得。
帶內音頻（In-band）
把DTMF當成普通聲音，由話機產生真實的雙頻音，經語音編碼器壓縮後隨RTP語音封包一同傳送，接收端解碼後再以偵測器辨認。優點是不需任何額外協商，缺點是訊號質素完全取決於編碼器是否忠實還原兩個頻率，並且封包遺失會直接令音長被截斷。
具名電話事件（RFC 4733）
不傳送聲音，改為在RTP串流中以獨立的酬載類型傳送一個「事件」描述：按了哪個鍵、音量多少、已持續多久。接收端按描述自行重建按鍵音或直接消化。這是IP電話最常用的方式，亦是SIP Trunk服務普遍要求的做法。
訊令帶外（SIP INFO）
把按鍵訊息放在訊令通道傳送。SIP的INFO方法最初由RFC 2976定義，其後由RFC 6086的INFO封包框架取代。這種方式與媒體路徑完全分離，可靠性高，但按鍵與語音之間的時序關係較難維持，且需要雙方對訊息格式有共同約定，實務上多見於特定平台之間的對接。
三者並非互相排斥：不少設備可以同時開啟帶內與具名事件兩種，但這正是最常見的故障來源之一，詳見下文的排查一節。
RFC 4733封包格式與協商參數
RFC 4733《RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals》於2006年12月發布，正式取代RFC 2833。業界至今仍普遍以「RFC 2833」稱呼這種方式，但實際實作應以RFC 4733為準；後者保留了原有框架，收窄為最基本的事件代碼並建立IANA登記表，同時新增三項機制：把長事件切分為分段、在單一封包內報告多個事件，以及狀態事件的概念。
其酬載格式只有四個欄位，共四個位元組：事件代碼（8位元）、結束位E（1位元）、保留位R（1位元）、音量（6位元）、持續時間（16位元）。事件代碼中，數字0至9對應代碼0至9，「*」為10，「#」為11，A至D為12至15。音量以dBm0表示但捨去符號，範圍0至63，數值越大代表音量越低。持續時間以時戳單位計算；在8000 Hz取樣率下，該欄位足以表達約八秒的事件長度，超過就必須切分為連續分段。
可靠性機制值得留意。RFC 4733規定發送端在辨認到事件後應持續送出更新封包，更新間隔建議為50毫秒；而每個事件與每個分段的最後一個封包，應按相同間隔合共送出三次，確保即使其中一份遺失，接收端仍能正確判斷事件的總長度。此外可配合RFC 2198的冗餘機制，把重傳與新事件報告合併在同一封包，減少封包與標頭開銷。
協商方面，具名事件沒有固定的靜態酬載類型編號，須以動態編號指派，並在SDP中以a=rtpmap宣告，例如「a=rtpmap:101 telephone-event/8000」。媒體類型為audio/telephone-event，另有選用參數events（列出支援的事件代碼，例如0-15）與rate（取樣率，預設8000 Hz）。兩端指派的動態編號不必相同，但必須各自在SDP中正確宣告並依對方宣告的編號發送。
低位元率編碼為何破壞帶內按鍵音
帶內傳送方式的最大弱點，來自語音編碼器的設計目標。G.711一類的波形編碼器直接對取樣值量化，還原出的波形與原始波形接近，雙頻音基本上可以通過；但低位元率編碼器（例如G.729、G.723.1）採用的是參數化的語音合成模型，它並不忠實記錄波形，而是分析出一組近似人類聲道特性的參數再於接收端重建。
DTMF是兩個純正弦波的疊加，並不符合人類發聲的物理模型，經這類編碼器處理後往往嚴重失真。RFC 4733在說明閘道應用時亦明確指出：由閘道負責偵測按鍵音，可以避免像G.723.1這類低位元率編碼器把DTMF音變得無法辨識。
實務含意有三點。第一，若通話路徑上任何一段使用低位元率編碼，帶內方式便不可靠，必須改用具名電話事件。第二，即使全程使用G.711，帶內方式仍受封包遺失影響：遺失兩個連續封包等同音長被挖走一段，接收端可能判斷為兩次按鍵或完全漏收。第三，回音消除、自動增益控制與噪音抑制等音頻處理功能亦可能改動雙頻音的振幅比例，令偵測器判斷失準，這在使用免手持話機或軟電話時尤其明顯。
因此在有多段轉接的環境中，較穩妥的做法是全程統一採用具名電話事件，並在每一段接駁點（IP-PBX、對外中繼、雲端平台）確認設定一致，而非依賴任何一段的音頻質素。
常見故障徵狀與排查方向
按鍵訊號的故障多數不會令通話中斷，只表現為自動語音系統無反應或反應錯誤，因此容易被誤判為對方系統的問題。以下按徵狀分類。
- 數字重複（按一次變兩次）——最典型的成因是設備同時以帶內音頻與具名事件送出同一按鍵，接收端兩者都認得，於是計算為兩次。處理方式是在話機、IP-PBX與對外中繼上選定單一方式，並關閉其餘方式。
- 完全無反應——通常是酬載類型協商失敗。檢查雙方SDP的a=rtpmap宣告是否一致存在telephone-event，以及發送端是否按對方宣告的編號發送。若一方只支援帶內而另一方只接受具名事件，結果亦是全無反應。
- 只認得前幾位——多與音長或更新機制有關。若封包遺失率偏高而最後封包的三次重傳被截斷，接收端對事件結束的判斷會出錯，令後續按鍵被併入上一個事件。此時應先量度該路徑的封包遺失與抖動。
- 語音正常但按鍵失效——說明語音路徑通暢，問題集中在事件酬載。留意部分中間設備（會話邊界控制器、防火牆的深度封包檢測）可能只放行協商中的語音酬載類型，而阻擋動態編號的事件酬載。
- 需長按才有反應——接收端要求的最短音長較長，或發送端把長按事件切分後首段偏短。可嘗試調整發送端的最短音長設定，並確認Q.24所述的40毫秒下限有足夠餘量。
- 間歇性失效——與網絡負荷相關。事件封包與語音封包共用同一RTP串流，若沒有服務品質標記，繁忙時段的封包遺失會同時影響兩者，但按鍵的影響更明顯，因為單一封包遺失即可改變事件判斷。
排查次序建議由設定一致性開始（協商參數與傳送方式），再檢視網絡質素（遺失與抖動），最後才調整音長一類的細節參數，避免在協商本身錯誤的情況下反覆微調數值。
香港環境的常見應用與部署注意
本地企業日常接觸按鍵訊號的場合，比一般想像更多。銀行與保險公司的自動語音服務要求輸入帳戶號碼與身份證字母，電話會議平台要求輸入入會碼，客戶服務熱線以按鍵分流至不同部門，物流與零售的訂單查詢系統亦以按鍵輸入單號。這些都屬於企業對外通話的一部分，一旦按鍵訊號失效，員工無法完成查詢，而故障原因往往在自己一方的電話系統設定，而非對方的服務。
另一類本地常見情況是舊有設備的遷移。不少大廈的對講機系統以按鍵碼開門，防盜警報主機以DTMF格式向中央監控中心報告事件，部分電子收費終端亦以按鍵音傳送交易資料。這些設備原本接在模擬電話線上，並不理解IP網絡的協商機制；當公司把電話線遷移至IP架構時，若中間的類比轉換裝置採用低位元率編碼或未正確處理按鍵音，設備會表現為間歇性通報失敗。警報通報格式的細節可參考本站關於Contact ID的說明。
香港中小企的辦公室網絡多與寬頻共用同一條線路，繁忙時段的封包遺失並不罕見。因此在規劃IP電話時，建議把按鍵訊號的傳送方式列入驗收項目：在正式切換前，以實際會用到的自動語音服務逐一測試輸入長數字串，並在辦公室網絡繁忙時再測一次。這比單純測試「打得通、聽得到」更能反映日常使用情況。