SIP防爆電話は登録済みなのに通話できない：よくある障害の切り分け方法

SIP防爆電話を保守する際、REGISTERトランザクションに対する200 OKは、端末が登録サーバーとの間で認証済みのアドレスバインディングを正常に確立したことだけを示します。INVITEが正しくルーティングされること、SDPで互換コーデックをネゴシエーションできること、あるいは防爆電話と相手側の間でRTPメディアが双方向に通ることまでは保証しません。つまり「登録済み」はSIP制御プレーンの到達性の一部を示す状態であり、エンドツーエンドの通話機能全体が正常であることを意味しません。

そのため、防爆電話が正常に登録されているように見えても、着信しない、接続しても無音、片方向音声になる、応答直後に切断される、といった症状が発生します。多くの場合、実際の原因は登録サーバーではありません。問題は登録後のシグナリング経路、メディア経路、または端末内のローカル音声系統にあります。シグナリング、メディア、端末音声の3層で切り分ければ、「登録済みなのに通話できない」という曖昧な申告を個別に検証できる段階へ分解でき、見当違いの再起動を繰り返すことも避けられます。

なぜ「登録済み」だけでは通話できると断定できないのか

まず、登録処理が実際に何をしているかを確認します。端末が送信するREGISTERリクエストには通常、いくつかの重要なフィールドがあります。Request-URIは登録ドメインを示し、Toは登録対象のアカウント、すなわちAddress-of-Record（AOR）を表します。Contactは端末の現在の到達可能アドレス（通常はIPアドレスとポート）を示し、Expiresは登録が有効な期間を定義します。

登録は一度だけ行う処理ではありません。プラットフォームはロケーションサービスに、特定のAORが現在どのContactを通じて到達可能かという関係を保持します。このバインディングには有効期限があり、一般的には約1時間に設定されることがあります。端末は期限切れ前に登録を更新する必要があり、更新しなければプラットフォームは最終的にその内線をオフラインと判断する可能性があります。

認証は通常2回のやり取りで行われます。端末が最初に認証情報なしでREGISTERを送ると、サーバーはrealmやnonceなどのチャレンジパラメータを含む401 Unauthorizedを返します。端末はアカウント情報を使って認証ダイジェストを計算し、Authorizationヘッダーを付けたREGISTERを再送します。その後、通常は200 OKが返されます。したがってシグナリング上の「登録成功」とは、端末とサーバーが認証済みREGISTERトランザクションを完了したことを意味します。

実際の電話通話には、さらに多くの処理が必要です。ユーザーがダイヤルすると端末はINVITEを生成し、PBX、SIPサーバー、またはディスパッチプラットフォームが番号計画や権限ルールに基づいて着信先をルーティングします。その後、双方がSDPでコーデック、メディアアドレス、RTPポートをネゴシエーションして初めて音声が流れます。

シグナリングとメディアは別経路を通ることも重要です。SIPシグナリングは一般にUDP/TCP 5060またはTLS 5061を使用しますが、RTPは別の動的UDPポート範囲を使います。ファイアウォールが5060を許可していてもRTP範囲を遮断していれば、登録は正常でも通話は無音になります。

REGISTER成功
→ SIPアカウントはオンライン表示
→ それでもINVITEは拒否される可能性がある
→ 200 OKが返っても
→ RTPはファイアウォール、NAT、誤ったメディアアドレスで遮断される可能性がある
→ RTPが端末に到達しても
→ ローカルのマイクやスピーカーが故障している可能性がある

要点は単純です。登録状態は、ある時点で1つのトランザクションが成功したことを示すスナップショットにすぎず、エンドツーエンド音声が利用可能である証明ではありません。登録は定期的に更新されるため、画面上の「登録済み」は直近の更新成功を示しているだけで、現時点のネットワーク到達性すら保証しません。

最初に呼設定の障害か音声メディアの障害かを判断する

「登録済みだが通話できない」と報告されたとき、最初からコーデックやネットワーク設定を変更すべきではありません。まず「通話できない」が具体的に何を指すのかを確認します。いくつか質問するだけで、ツールを使う前に切り分け方向をほぼ決められます。

完全なSIP通話は大きく2段階に分けられます。第1段階は呼設定で、INVITEから始まり、着信側が200 OKで応答し発信側がACKを送るまでです。第2段階は音声メディアで、SDPネゴシエーション完了後に双方向RTPが実際に流れる段階です。最も簡単な境界は、ユーザーインターフェースが通話を「接続済み」と表示しているかどうかです。

ダイヤル直後にエラーになる、呼出音が鳴らない、相手側に着信自体が表示されない場合は、SIPシグナリングまたは呼ルーティングの問題である可能性が高くなります。双方が接続済みと表示され通話時間も進んでいるのに無音または片方向音声であれば、SDPおよびRTPメディア経路を調査します。

ほかにも2つのパターンが参考になります。発信はできるが着信できない場合は、着信番号ルーティング、Contactアドレス、NAT、プラットフォーム側のルーティングが原因になりやすく、着信はできるが発信できない場合は、ダイヤルプラン、発信権限、番号フォーマット、SIPトランク設定を確認します。

通常のSIP内線同士は通話できるのに、ディスパッチコンソール、ページングシステム、PSTN宛てだけ失敗する場合は、障害範囲がかなり限定され、特定ルートやシステムインターフェースの問題である可能性が高まります。

現場からの有効な障害報告では、少なくとも次の4点を明確にします。

• 発信障害か着信障害か？

• 呼出音は鳴るか？

• 画面上は接続済みになるか？

• 完全な無音、片方向音声、または数秒後の切断のどれか？

この4点は「電話が使えない」という一言よりはるかに有用です。

呼設定に失敗する場合、番号・権限・SIP応答のどれを先に確認するか

呼設定段階で問題が発生している場合、防爆電話のハードウェアを疑う前にSIPシグナリング経路を追います。実用的な順序は、番号 → 権限 → 応答コード → シグナリング到達性です。

まず番号とダイヤルプランを確認します。端末が送るRequest-URIはプラットフォームの期待と一致しているか、内線にプレフィックスが必要か、システム間通話に市外局番・アクセスコード・番号変換が必要かを確認します。「登録済みだが発信できない」ケースの多くは、電話が送信する番号形式とPBXのルーティングルールの不一致です。

例えば、電話が8001を送信しているのにPBXが8#8001または完全なE.164形式を要求している場合があります。INVITEのRequest-URIをパケットキャプチャで確認すればすぐ判別できます。

次にアカウント権限を確認します。内線のみ許可されPSTN権限がない端末や、通常のSIP内線には発信できても緊急ホットライン、ディスパッチグループ、ページングゾーンにはアクセスできない端末があります。こうしたサービスクラス設定は工業用途で見落としやすく、登録処理では業務上の発信権限まで検証しません。REGISTERが答えるのは「このアカウントはオンラインか？」であり、実際の発信が答えるのは「このアカウントはこの宛先に発信できるか？」です。

続いてSIPレスポンスコードからさらに原因を絞り込みます。

障害解析でよく見る応答があります。401/407は資格情報、アルゴリズム、アカウントバインディングなど認証チャレンジ処理を示すことが多く、403では権限ルール、アカウントポリシー、プラットフォームが拒否した理由を確認します。404は番号が存在しない、または一致するルートがない可能性があります。408と480はタイムアウトまたはユーザー利用不可を示し、488はメディア能力やコーデックの不一致と関連することが一般的です。

SIP設定が正しく見えてもINVITEが宛先システムに届かない場合は、ネットワーク経路に戻って確認します。VLAN、ゲートウェイ、ファイアウォール、ACL、電話が実際に使用している宛先アドレスを確認します。最も早いのはサーバー側でパケットキャプチャする方法です。INVITEが到達しても転送されないならPBXまたはディスパッチプラットフォームのルーティングを確認し、到達しないなら端末または端末とサーバー間のネットワークを調べます。

通話は接続済みなのに無音または片方向音声の場合、何を確認するか

「双方とも接続済みだが音がない」は代表的なSIP障害です。この段階では通常、呼シグナリング自体は正常に完了しています。問題はSDPネゴシエーションまたはRTP転送である可能性が高く、シグナリングプレーンからメディアプレーンへ調査を移します。

まずSDPに含まれるメディア情報を確認します。c=は接続先アドレス、m=はメディア種別とポート、a=rtpmapはペイロードタイプとコーデックの対応、a=sendrecv/sendonly/recvonlyはメディア方向を示します。

端末がINVITEまたは200 OKのSDPで通知する音声アドレスは、相手側から到達可能でなければなりません。相手が別ネットワークにいるのに、端末が192.168.x.xのようなルーティング不能なプライベートアドレスをSDPに設定すると、SIP呼自体は成立してもRTPは宛先に届きません。典型的な「接続済みだが無音」です。

NAT環境では特に発生しやすく、対処方法はネットワーク構成に依存します。SIPシグナリングはNATを通過できても、メディア経路が完全に失敗することがあります。代表的なNAT動作にはフルコーンNAT、制限コーンNAT、ポート制限コーンNAT、シンメトリックNATがあり、後者ほど通過が難しくなります。

産業ネットワークではSBCをメディアリレーとして使用し、RTPを既知のポイントにアンカーする方法が一般的です。STUNでパブリックアドレスマッピングを検出する構成や、より複雑な環境でTURNまたはICEを使う場合もあります。正しい方式は実際のトポロジー次第です。REGISTER成功はRTPがNATを通過できる証明ではありません。

ファイアウォールもよくある原因です。SIPポートとして分かりやすい5060または5061だけを許可し、音声用の別RTP範囲を許可していないケースがあります。多くの端末は10000～20000などの範囲からRTPポートを動的に割り当てます。SIPだけ許可しACLがRTPを遮断していれば、「通話は接続するが無音」という症状になります。

片方向音声は方向別に確認します。管制室では現場電話の音が聞こえるのに、現場側では管制室の音が聞こえないなら、少なくとも一方向のRTPまたは一つのローカル音声経路は動作しています。全ネットワークを最初から確認するのではなく、双方のSDPアドレス、RTPポート、NATマッピング、キャプチャしたメディアフローを比較します。方向ごとの差から、片側のNAT、ファイアウォールルール、誤ったSDPアドレスへ直接絞り込めることがあります。

ネットワーク確認後はコーデックとローカル音声系統を確認する

RTPパケットが存在しても、明瞭な音声が保証されるわけではありません。次に双方が実際に互換コーデックをネゴシエーションしたかを確認します。

コーデックネゴシエーションはSDPのオファー／アンサーモデルに従います。発信端末はINVITE SDPに対応コーデックを通常優先順位順で列挙し、着信端末は自分も対応するコーデックを選択して200 OKで返します。共通コーデックがなければメディアネゴシエーションは失敗します。

産業用防爆電話で一般的なコーデックには、G.711（PCMU/PCMA、64 kbps、PSTN環境との互換性が高い）、低帯域回線向けのG.729、広帯域音声向けのG.722、一部の新しい端末で利用されるOpusがあります。電話側が1つのコーデックグループだけを有効にし、PBX、録音システム、ディスパッチプラットフォームが別のものだけをサポートする場合、488 Not Acceptable Hereになったり、実装によっては接続済みでもメディアが異常になったりします。

正しい確認方法は、管理画面の「有効」表示だけを見るのではなく、双方のSDPメッセージにあるペイロードタイプとコーデック一覧を比較することです。

コーデックネゴシエーションとRTP転送が正常と確認できたら、端末の物理音声経路へ進みます。防爆電話は高騒音、湿気、粉塵、腐食性環境で長期間使用されることがあります。SIPスタックが正常でも、マイク、ハンドセット、スピーカー、アンプモジュール、コネクタ、現場ケーブルが故障する可能性があります。

実用的なのは、RTP統計と現場で実際に聞こえる音を比較する方法です。パケットキャプチャでは双方向RTPが連続し、パケット数とタイミングが正常でも片側が無音なら、ミュート状態、音量、物理マイクまたはスピーカーを確認します。RTPは送信されているものの音声内容が実質無音なら、マイク入力または音声収録経路も確認します。

定量的なメディア分析ができる場合、特に有効なのはパケットロス、ジッタ、片方向遅延です。パケットロスが増えると音声劣化が目立ち、過大なジッタには大きなジッタバッファが必要になる場合があります。片方向遅延が大きいと自然な会話が難しくなります。特定のネットワークホップに損失が集中していれば、リンク混雑や無線伝送が関係している可能性があります。

増幅出力を持つ防爆ページングステーションでは、内蔵電話スピーカー経路と外部ホーンまたはアンプ出力を区別します。両者がまったく同じ音声経路を使うとは限りません。通常のハンドセット通話やハンズフリー通話が正常でも外部ページング音声が正常とは限らず、その逆も同様です。試運転と障害診断では、必要な音声経路を個別に検証し、「ページング音声が出ない」という訴えをすべてSIP障害として扱わないことが重要です。

パケットキャプチャで障害範囲を素早く絞り込む方法

複雑なSIP障害では、パラメータを何度も変更するより、失敗した1回の通話を完全にキャプチャし、REGISTERからBYEまで時系列で追う方が効果的です。ほとんどのケースはWiresharkで十分です。有効なキャプチャポイントは電話側、スイッチのミラーポート、SBCまたはPBX側です。

キャプチャ位置によって証明できる内容が変わります。端末側のトレースは電話が実際に送受信した内容を示し、障害がローカル起因か判断できます。SBCまたはPBX側では、プラットフォームがシグナリングを正しく受信・転送したか確認できます。VLAN、拠点、SBCをまたぐ構成では複数地点でキャプチャする方が望ましく、1地点だけではメッセージがそこを通過したことしか証明できず、その先のネットワーク動作までは証明できません。

トレースを取得したら、次の順序で通話を追います。

1. REGISTERは成功したか？
→ 2. INVITEは実際に送信されたか？
→ 3. PBXは受信して正しくルーティングしたか？
→ 4. 相手側は18x / 200 OKを返したか？
→ 5. SDPは共通コーデックをネゴシエーションしたか？
→ 6. 双方向RTPが実際に存在するか？
→ 7. RTP宛先IPアドレスとポートは正しいか？
→ 8. 現場マイクとスピーカーは実際に音声を通しているか？

Wiresharkには便利な機能があります。SIPメッセージはsipやsip.CSeqなどでフィルタリングできます。Telephony → VoIP Callsでは、通話のシグナリングシーケンスと関連RTPストリームをまとめて確認できます。RTP分析ではパケットロス、ジッタなどのメディア品質指標も確認できます。

障害診断の順序はシグナリングを先に、メディアを後にするのが基本です。シグナリングが失敗していれば呼設定の問題であり、シグナリング完了後にメディアがなければメディア経路を調査します。

「発信はできるが着信できない」場合は、着信INVITEが本当に防爆電話まで届いているか確認します。数秒または数十秒後に一定して切断する場合は、ACK、Session Timer、NATマッピング、期待するメッセージが届かなかったためプラットフォームがセッションを解放していないかを確認します。

もう一つ分かりにくい例が、通話中のメディア再ネゴシエーションです。re-INVITEでRTPアドレスやポートが変わることがあります。その再ネゴシエーション時にNATマッピングが失敗すると、「数秒は通話できたが、その後音声が消えた」という症状になります。

目的はすべてのSIPレスポンスコードを暗記することではありません。常にこの通話が最後に正常通過した層はどこで、最初の異常はどこに現れたか？と問い続けます。最初の障害点が特定できれば、切り分けの大半は完了しています。

よくある質問

SIP電話が登録済みと表示されていれば、少なくともネットワーク正常の証明になるか？

いいえ。登録済みは、ある時点で端末がRegistrarとのSIP登録トランザクションを完了できたことだけを示します。呼ルーティング、宛先到達性、RTP、NAT、ファイアウォールルール、端末の音声ハードウェアがすべて正常であることは証明しません。実際の通話中にパケットロスや高遅延が発生しないことも保証しません。登録は周期的なため、表示状態は前回の更新成功を示しているだけの場合があります。

双方とも接続済みだが無音。最初に何を確認すべきか？

まずSDPのメディアIPアドレス、RTPポート、コーデックネゴシエーションを確認します。その後、ファイアウォール、NAT装置、SBCが双方向RTPを許可しているか確認します。双方向RTPが双方の端末まで確実に到達していれば、マイク、スピーカー、ミュート状態、ローカル音声出力設定へ進みます。実用上はメディア経路を先に、ローカルハードウェアを後に確認します。

同じ防爆電話で内線通話はできるのにPSTN通話だけ失敗するのはなぜか？

内線通話とPSTN通話は通常、異なるルーティング経路を使います。外線通話には発信権限、番号変換、SIPトランク設定、通信事業者側ルーティング、発信者番号表示ルールも関係します。内線間通話の成功はSIPとメディア経路の一部が正常なことしか証明しません。PSTN通話ではさらにSIPトランクと通信事業者網を通過するため、追加のルーティングとポリシー要件があります。

登録は正常だが音声が途切れる、または通話途中で切れる。考えられる原因は？

多くはメディア転送品質の問題です。パケットロス、過大なジッタ、帯域不足、期限切れNATマッピングなどが通話中のRTPを中断させます。まずRTPロスとジッタを確認し、必要に応じてリンク容量や無線カバレッジを調べます。一定時間後に必ず切れる場合は、re-INVITEによるメディア再ネゴシエーションやSession Timerも確認します。

電話を交換すると直るのに、元の端末では失敗し続けるのはなぜか？

ネットワークよりも、元の電話の設定、ファームウェア、ローカルハードウェアを疑うべき状況です。ファームウェア不具合、登録有効期限、NAT処理、RTPポート範囲などのSIP設定ミス、DSPまたは音声モジュール障害が考えられます。すぐにネットワーク不安定と判断せず、コーデック一覧、SIPポート、NAT設定を中心に2台の設定を1項目ずつ比較します。

SIP防爆電話の再起動は正しい障害診断方法といえるか？

再起動で一時的に登録が戻ったり、NATマッピングが更新されたり、停止したプロセスが解消されたりすることはありますが、障害切り分けの代わりにはなりません。原因がダイヤルプラン、SIP権限、ファイアウォールルール、コーデックネゴシエーション、メディアルーティングにある場合、再起動は一時的に隠すだけか、効果がない場合もあります。症状を記録し、シグナリングトレースとログを保存した上で、最初の障害点が端末・ネットワーク・通信プラットフォームのどこかを判断する方が適切です。

Becke Telcomは、端末、IP PBX、SIPトランク、ネットワークスイッチング、SBC、ディスパッチシステムの実際の構成に基づいた障害切り分けを支援できます。また、石油化学、エネルギー、鉱山、トンネルなどの産業通信環境向けに、防爆電話、防爆ページング電話、SIPゲートウェイ、IPページング、統合ディスパッチ機器を提供しています。