DTMF 音声エンコーダ — 0-9 / * / # / A-D → 電話プッシュ音 WAV/MP3

DTMF 合成が使われる文脈と、なぜブラウザ内で完結させるか

DTMF トーンを合成する用途は主にテスト・教育・検証です。IVR システムのテスト音源作成、CTF 問題の出題素材、電話プロトコルの学習教材、そして dtmf-decode-audio との相互検証 (生成した音声を復号して符号化精度を確認する) などが代表的な使い方です。入力は数字列なので、音声ファイルを扱う他のツールとは性質が異なりますが、それでもブラウザ内で完結させる理由があります。

電話番号形式の数字列 (特に実際の電話番号・内線番号・PBX アクセスコード) を入力として使う場合、その数字列を外部サーバーへ送ることは好ましくありません。DTMF エンコーダーがオンラインサービスとして提供される場合、入力した番号がサービス側のログに残る可能性があります。テスト目的でもリアルな番号を使うことがあるため、入力データがブラウザ内に留まる設計は意味があります。

入力値の機密性と行動観測の問題

「どの数字列を DTMF として符号化したか」という情報は、文脈によっては機密です。PBX の内線番号体系、IVR のルーティングコード、テスト用のアクセス番号などは、公開されるべきではない情報です。オンラインの DTMF ジェネレーターにこうした番号を入力すると、サービス側のアクセスログに「この IP アドレスがこの番号を DTMF 化しようとした」という記録が残ります。

行動観測の角度でも注意が必要です。「どんな番号を入力したか」は直接的な情報ですが、「いつ、どのくらいの頻度で DTMF を生成しているか」もパターンとして観測可能です。テレコム系の業務やセキュリティ調査に使う場合は特に、入力データがブラウザ外に出ない実装を選ぶメリットがあります。

PCM 合成から lamejs エンコードまでブラウザ内 JavaScript で完結

このツールはキー列のパース、PCM サンプル列の合成、WAV / MP3 エンコードをすべてブラウザ内 JavaScript で実行します。各キーに対応する 2 つの正弦波 (低域グループ + 高域グループ) を振幅 30% で生成して加算し、トーン区間と無音区間を交互に並べて PCM バッファを構築します。WAV は自前の RIFF/WAVE ヘッダ構築でエンコード、MP3 は @breezystack/lamejs (LAME の JavaScript 移植) で CBR エンコードします。

DevTools の Network タブを確認すると、ページロード後の音声生成・ダウンロード操作でリクエストはゼロです。PCM 合成ロジックと lamejs の呼び出し部分を含めて、実装は GitHub で公開されています。

テストと教育目的での活用と、本番環境への注意

IVR システムのテストに使う場合、本ツールで生成した DTMF 音声を dtmf-decode-audio で復号して、期待した数字列が正確に復元されることを確認するという相互検証フローが有用です。CTF 問題では DTMF を使った問題がまれに出題されるため、音源を生成して自己検証するための道具として使えます。連続トーンだけで波形特性を確認したい場合は tone-generate で純音を生成して audio-tone-detect で検出精度を測る、というキャリブレーションも組み合わせられます。

実際の電話番号や PBX コードを使うときは、生成した音声ファイルの保存先と共有範囲に注意してください。DTMF 音声ファイルは「見ただけではわからない」形で数字列を含んでいます。dtmf-decode-audio で簡単に復号できますが、それは本ツールでも同じ手軽さで確認できます。

ITU-T Q.23 / Q.24 仕様と DTMF の 4x4 周波数マトリクス

DTMF は ITU-T 勧告 Q.23 / Q.24 で標準化された 8 周波数 (low group 697 / 770 / 852 / 941 Hz × high group 1209 / 1336 / 1477 / 1633 Hz) の 4x4 マトリクスです。電話端末では 1633 Hz 列 (A / B / C / D キー) は省略されており実質 4x3 = 12 キーですが、本ツールはマトリクスの全 16 シンボルを符号化できます (A / B / C / D は軍用通信や ARC キーパッドで使用)。各周波数は 1.5% 以下の偏差で生成する必要があり、Q.24 はトーン長 40 ms 以上 (典型 70〜100 ms)、ポーズ 40 ms 以上、power 差 (twist) は low group - high group = -8 dB〜+4 dB (北米仕様、ETSI 仕様は別範囲) と規定しています。本ツールは振幅 30% (各周波数) × 2 = 60% peak の正弦波加算で生成し、デフォルトの ON / OFF 長 (120 ms / 80 ms) は ITU-T 仕様に余裕を持って収まります。

なぜ 2 つの周波数の組み合わせなのかという設計判断は、誤検出耐性の確保にあります。1950 年代後半に AT&T Bell Labs (AT&T 1958, Schenker) が設計した時点で、人の話し声 (基音 100〜300 Hz、第 1 ホルマント 500〜900 Hz、第 2 ホルマント 1500〜2500 Hz) とは異なる組み合わせを選び、片方の周波数だけで誤検出が起きないよう twist 比のしきい値を Goertzel 検出側に持たせる構造にしたことが、現代まで残っている DTMF の堅牢性の源泉です。SF (Single Frequency) signaling や Blue Box 系の 2600 Hz シングルトーン (Joybubbles / Steve Wozniak 時代のフリーキング) との対比で、DTMF が「正規の信号と話し声を確実に区別する」という設計目標を持っていたことが分かります。

IVR テスト・テレコムセキュリティ調査での活用と実務的注意点

DTMF 音声の主な実務的用途は (1) IVR システムの自動化テスト (生成した音声を IVR に再生して、メニュー遷移を検証)、(2) PBX / SIP トランクのトーン透過性検査 (G.711 / G.729 / Opus の codec 越しに DTMF が正しく伝わるか)、(3) RFC 4733 (telephone-event payload type) による RTP 帯域内 DTMF と帯域外 DTMF の比較検証、(4) ペネトレーションテスト時の War Dialing 代替 (実機を回さずトーン音源を準備) などです。G.729 のような低ビットレートコーデック越しでは、サイン波の品質が劣化して twist 比が崩れ、受信側で誤検出するケースがあります — このため本ツールで生成した WAV を実環境の codec チェーンに通して、最終受信側で dtmf-decode-audio で逆検証する round-trip テストが、IVR / VoIP の品質保証で有効です。

業務利用上の注意として、生成した音声ファイルが PBX 内線番号やアクセスコードを含む場合、ファイルそのものが機密情報の伝送媒体になります。電子メール添付・チャット共有・クラウドストレージ保存のいずれも、復号可能な形で機密数字列を残します。テスト終了後は音声ファイルを削除し、テスト記録には dtmf:<number> のような構造化記法 (Asterisk / FreeSWITCH の Dialplan 表記) で残すのが運用上は安全です。クレジットカード番号や PIN を含む DTMF を生成する場面は通常ないはずですが、もし業務上必要な場合は、PCI-DSS の Sensitive Authentication Data 保管禁止規定に該当する可能性を確認してください。