DTMF 按鍵訊號
DTMF（Dual-Tone Multi-Frequency）就是電話按鍵發出的那個「嘟」聲，是電話系統裡最基本的使用者輸入方式。從按鍵式電話一路到現在的 IVR 自助服務，DTMF 能不能被正確偵測、正確傳過去，直接關係到客服系統穩不穩。
DTMF 原理
雙音多頻
DTMF 的核心原理是每個按鍵同時產生兩個頻率的正弦波：一個來自低頻群組（行），一個來自高頻群組（列）。兩個頻率的組合唯一對應一個按鍵。
這種雙音設計的目的是提高抗干擾能力。單一頻率可能被語音中的自然頻率誤觸發，但兩個特定頻率同時出現的機率極低。
頻率選擇原則
DTMF 的頻率經過精心選擇，確保：
- 頻率之間不是整數倍關係（避免諧波干擾）
- 所有頻率都在電話語音頻帶（300-3400 Hz）內
- 低頻群組和高頻群組之間有足夠的頻率間距
頻率對照表
標準 4x4 鍵盤
| 1209 Hz | 1336 Hz | 1477 Hz | 1633 Hz | |
|---|---|---|---|---|
| 697 Hz | 1 | 2 | 3 | A |
| 770 Hz | 4 | 5 | 6 | B |
| 852 Hz | 7 | 8 | 9 | C |
| 941 Hz | * | 0 | # | D |
你可能注意到表裡有 A/B/C/D。標準 DTMF 其實定義了 16 個按鍵（0-9、、#、A-D），只是一般電話鍵盤只做了 12 個（0-9、、#）。A-D 用在特殊場合，像軍事通訊和部分 PBX 功能碼，VoIP 和 IVR 系統裡偶爾也會用到這幾個擴展鍵。
DTMF 訊號參數
| 參數 | 標準值 | 說明 |
|---|---|---|
| 最小持續時間 | 40 ms | 按鍵訊號的最短時間 |
| 建議持續時間 | 70-100 ms | 確保可靠偵測 |
| 最小間隔 | 40 ms | 兩個按鍵之間的最短靜默 |
| 建議間隔 | 50-70 ms | 確保不會合併偵測 |
| 高頻/低頻功率比 | +1 至 +3 dB | 高頻群組略強（Pre-emphasis） |
| 訊號位準 | -10 至 0 dBm | 每個頻率的功率 |
偵測條件
DTMF 偵測器（Detector）需要同時滿足以下條件才判定為有效按鍵：
- 偵測到一個低頻群組頻率和一個高頻群組頻率
- 兩個頻率的功率差在容許範圍內
- 訊號持續時間超過最小門檻
- 無其他顯著的干擾頻率（Twist 檢查）
傳輸方式
在 VoIP 環境中，DTMF 訊號的傳輸方式是經常遇到的相容性問題。主要有三種傳輸方式：
In-band（帶內傳輸）
DTMF 訊號直接作為語音的一部分，由 Codec 編碼後在 RTP 串流中傳輸。
運作方式：
按鍵 → 產生雙音頻 → Codec 編碼 → RTP 封包 → 解碼 → DTMF 偵測優缺點：
| 優點 | 缺點 |
|---|---|
| 最簡單，無需特殊設定 | 壓縮 Codec（G.729 等）可能破壞 DTMF 頻率 |
| 所有設備都支援 | 丟包會造成偵測失敗 |
| Jitter 可能影響偵測時序 | |
| VAD（靜音偵測）可能誤判 DTMF 為靜音 |
In-band 有個致命問題：G.729 這類低位元率 Codec 用的是預測式編碼，會把 DTMF 的正弦波形嚴重扭曲。所以只要環境用了壓縮 Codec，In-band DTMF 幾乎測不準，不建議用；就算是 G.711，遇到網路丟包也可能漏測。
Out-of-band：RFC 2833 / RFC 4733
DTMF 訊號以專用的 RTP Payload Type 傳輸，與語音媒體分離。這是目前最廣泛使用的方式。
RFC 4733（取代 RFC 2833）定義的 RTP 事件封包格式：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 欄位 | 說明 |
|---|---|
| Event | DTMF 事件編號（0-9, 10=*, 11=#, 12-15=A-D） |
| E（End） | 結束標記，表示按鍵已釋放 |
| R（Reserved） | 保留位元 |
| Volume | 訊號音量（dBm0，0 為最大） |
| Duration | 按鍵持續時間（以 RTP 時戳單位計） |
SDP 協商：
在 SDP 中透過 telephone-event 宣告支援 RFC 4733：
m=audio 49170 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16a=fmtp:101 0-16 表示支援事件 0-16（0-9、*、#、A-D、Flash）。
可靠性機制：
RFC 4733 規定每個 DTMF 事件至少發送 3 次結束封包（End packet），以確保接收端能正確偵測到按鍵結束。
順帶釐清 RFC 2833 和 RFC 4733 的關係：4733 是 2833 的更新版，DTMF 這部分兩者幾乎一樣，實務上兩個編號經常混著講。多數設備的設定畫面還是寫「RFC 2833」，但實際遵循的是 4733。
SIP INFO 方式
DTMF 訊號透過 SIP INFO 訊息（在信令通道中）傳送，完全脫離 RTP 媒體路徑。
SIP INFO 訊息範例：
INFO sip:bob@192.168.1.100 SIP/2.0
Content-Type: application/dtmf-relay
Signal=5
Duration=160或使用 application/dtmf Content-Type：
INFO sip:bob@192.168.1.100 SIP/2.0
Content-Type: application/dtmf
5優缺點：
| 優點 | 缺點 |
|---|---|
| 不佔用 RTP 頻寬 | 信令路徑可能與媒體路徑不同 |
| 不受 Codec 影響 | SIP Proxy 可能不轉發 INFO |
| 文字格式易於除錯 | 延遲可能較高（SIP 交易延遲） |
| 部分設備不支援 |
三種方式比較
| 特性 | In-band | RFC 4733 | SIP INFO |
|---|---|---|---|
| 傳輸通道 | RTP（語音流） | RTP（事件封包） | SIP（信令） |
| Codec 相容性 | G.711 尚可，壓縮 Codec 差 | 與 Codec 無關 | 與 Codec 無關 |
| 可靠性 | 低 | 高 | 中 |
| 跨設備相容性 | 高 | 高 | 中 |
| 延遲 | 低 | 低 | 中高 |
| SBC 處理 | 不需特殊處理 | 需轉換或透傳 | 需轉發 INFO |
| 建議使用 | 不建議 | 首選方式 | 備選方式 |
DTMF 模式轉換
SBC 的 DTMF 轉換功能
在實際環境中，不同設備可能使用不同的 DTMF 傳輸方式。SBC 的重要功能之一就是在不同模式之間進行轉換：
電信端（In-band）── SBC（轉換）── 企業端（RFC 4733）
電信端（RFC 4733）── SBC（轉換）── IVR（SIP INFO）常見相容性問題
| 問題 | 症狀 | 解決方式 |
|---|---|---|
| DTMF 模式不匹配 | IVR 無法偵測按鍵 | SBC 設定 DTMF 轉換 |
| 重複偵測 | 一次按鍵偵測為多次 | 調整持續時間和間隔參數 |
| 遺漏偵測 | 快速按鍵部分遺漏 | 增加按鍵間最小間隔 |
| 時序問題 | 長按被偵測為多次短按 | 調整偵測器的 On/Off 計時器 |
| RFC 4733 PT 不匹配 | SDP 協商的 PT 值不一致 | 確認雙方的動態 PT 分配 |
在 IVR 系統中的應用
IVR 選單導航
DTMF 是 IVR（Interactive Voice Response）系統最基本的使用者輸入方式：
IVR 提示語: "查詢帳戶餘額請按1，轉接客服請按0"
用戶按鍵: [1]
IVR 偵測: DTMF Event = 1
IVR 動作: 進入帳戶餘額查詢流程DTMF 收集模式
| 模式 | 說明 | 應用場景 |
|---|---|---|
| 單鍵（Single Digit） | 偵測到一個按鍵即回應 | 選單選項（按1/按2） |
| 多位數（Multi-Digit） | 收集一組數字（以 # 結束或逾時） | 輸入帳號、密碼 |
| 定長（Fixed Length） | 收集固定位數的數字 | 輸入身分證號（10碼） |
IVR DTMF 設計建議
| 建議 | 說明 |
|---|---|
| 提供按鍵確認音 | 每次偵測到按鍵播放短促確認音 |
| 設定合理逾時 | 首鍵逾時 5-10 秒，後續鍵 3-5 秒 |
| 允許重新輸入 | 提供 * 鍵清除重輸的機制 |
| 支援 Barge-in | 允許在提示語播放時按鍵 |
| 限制重試次數 | 最多 3 次錯誤後轉人工 |
| 遮罩敏感輸入 | 密碼等敏感資訊不回讀確認 |
DTMF 安全考量
| 風險 | 說明 | 防護措施 |
|---|---|---|
| DTMF 竊聽 | 擷取封包中的 DTMF 事件 | 使用 SRTP 加密 |
| 錄音中的 DTMF | 密碼等敏感按鍵被錄音保存 | 錄音暫停或遮罩 |
| DTMF 注入 | 攻擊者發送偽造的 DTMF 事件 | SBC 驗證來源 |
碰到信用卡號要特別小心。依 PCI DSS 的要求，IVR 若用 DTMF 收信用卡號，必須做到三件事：傳輸過程中 DTMF 要加密、收卡號期間錄音要暫停或把 DTMF 音調遮掉、卡號不能以明文寫進日誌。
DTMF 除錯方法
抓包分析
使用 Wireshark 分析 DTMF 封包：
- RFC 4733：篩選 RTP 封包，查看 Payload Type 是否為 SDP 中協商的 telephone-event PT
- SIP INFO：篩選 SIP INFO 方法，查看 Content-Type 和 Body
- In-band：使用 Wireshark 的 RTP Player 功能播放音訊，聽取 DTMF 音調
常見問題排查清單
- 確認雙方 SDP 中是否正確協商了 telephone-event
- 確認 SBC/Proxy 是否正確轉發或轉換 DTMF
- 檢查 DTMF 持續時間是否足夠（> 40ms）
- 確認 IVR 設定的 DTMF 模式與實際收到的一致
- 檢查是否有 VAD（Voice Activity Detection）誤判