5. 発信トラブルと対策

VE-PG3はパルス発信に対応していないため、ダイヤル信号をDTMFに変換する必要があります。AliExpressで「Dialor 2.0」と呼ばれるPulse to Tone Converterを購入しました。

AliExpressで購入したDialor 2.0

動作確認をしたところ、数字「1」は正常にDTMFに変換されるものの、「2」以降が正しくDTMFにならない状態でした。ベルが鳴るように戻した配線を外すと正しく変換されることから、Dialor 2.0の不良ではないようです。しばらく悩んでいましたが、結局、C1(1.5uF/250V)をメタライズド・フィルム・キャパシター(1uF/250V)に交換したところ、発信できるようになりました。

C1交換後の電話機

電話線にラグ端子を取り付け、ケースを超音波カッターで加工して、見た目も含めてスッキリ接続できるようになりました。

Dialor 2.0のケース加工を行った様子

6. 東京広域電話網への接続

参加手順は以下の通りです。

参加手順は以下の通りです。
①東京広域電話網のDiscordサーバーに参加する
②各局が提供しているTailscale invite linkから各局のPBXを自局のVPN内に登録する
③各局が提供しているSIP Username / PasswordをFreePBXのPJSIP Trunkに設定する
④Outbound Routesを設定する

各局のPBXをSIP Trunkに追加

各局のPrefixをOutbound Routesに追加

相手局によっては、接続自体は成立するものの、相手側からの音声が無音となる場合があります。パケット解析を行ったところ、こちらから相手側へのRTP音声パケットは送出されている一方で、相手側からのRTP音声パケットが到達していないようでした。

この不具合は、Tailscale上で相手が提示しているIPアドレスと、自身の環境で認識されているIPアドレスが一致していない場合に発生することが分かっています。この状態では、RTPパケットの送信先が不正となり、結果として片方向音声が発生します。

対応策として、非推奨ではありますが、TailscaleのAdmin Consoleから該当ノードのIPアドレスを編集し、相手局が提示しているIPアドレスと一致させることで、本事象が解消されます。

Tailscale上で相手局のIPアドレスを変更する

なお、Tailscaleにルーティングする際は100.64.0.0/10をLocal Networkに設定すれば External Addressは不要(空欄でOK)です。

Asterisk SIP SettingsのNAT設定の例

着信の受け付けには以下の設定が必要です。

• ・着信用のSIP Trunkを作成し、任意のユーザー名およびパスワードを設定
• ・着信設定(Inbound Route)において、着信した番号に応じてダイヤル電話機または自動応答局へ振り分け
• ・Tailscale上でPBXマシンのReusableな招待リンクを作成し、Discordにて共有

着信側 Trunk設定

Inbound Routes設定

TailscaleでReusableな招待リンクを作成

正しく設定されていれば、東京広域電話網各局から開通確認の電話がかかってくることでしょう!

7. 成果

最終的に
 ・P.M.G(Postmaster-General's Department, Australia)802型ダイヤル電話機
 ・Dialor 2.0
 ・Icom VE-PG3
 ・RasPBX(Raspberry Pi 5+FreePBX)
の構成で東京広域電話網への接続に成功しました。

東京広域電話網の接続関係を可視化するWebアプリケーションとして「Mantela Viewer」が公開されています。このツールでは、各参加局が公開しているmantela.jsonの所在を指定することで、電話網内の接続関係を視覚的に確認できます。このJSONの内容を確認してみると、独自ドメインを保有している参加者の割合が非常に高いことが分かります。この点からも、「東京広域電話網」の参加者は総じてITスキルが高く、インフラやネットワーク技術に明るい方が多いことがうかがえます。参考までに、私の環境を起点にしたMantela Viewerの表示例は以下の通りです。

東京広域電話網の接続関係図

電話網・SIP・PBX・アナログ電話に関し、総合的に理解を深める有意義な経験となりました。本取り組みにあたり、多くの知見を共有いただいたKusaReMKN氏と東京広域電話網のメンバー各位に深く感謝します。