IP電話は、企業通信、指令システム、コールセンター、キャンパス、産業現場、ホテル、公共サービスネットワークで広く使用されています。最近のIP電話のほとんどはSIPプロトコルを使用しており、SIPサーバー、IP PBXプラットフォーム、ソフトスイッチシステム、ユニファイドコミュニケーションプラットフォームへの登録が容易です。しかし、導入中に一方向音声という一般的な問題が発生することがあります。

一方向音声とは、通話は接続されているものの、片方だけしか相手の声が聞こえない状態を指します。SIPシグナリングは正常に見え、電話は鳴り、通話は正常に応答されるかもしれませんが、音声ストリームが双方向に正しく伝送されません。この問題は通常、NAT、RTP伝送、ファイアウォールポリシー、SIP ALG、コーデックネゴシエーション、エンドポイント設定、またはサーバーのメディア設定に関連しています。

シグナリングとメディアの違いから始める

SIP電話通話には、シグナリングとメディアという2つの重要な部分があります。SIPシグナリングは登録、ダイヤル、呼び出し、通話設定、通話切断に使用されます。RTPは通話確立後に実際の音声ストリームを伝送するために使用されます。この違いが、一方向音声が発生する理由を理解する鍵です。

多くの場合、デフォルトのSIPポート（多くの場合UDPまたはTCP 5060）がネットワークで許可されているため、SIP部分は成功します。電話は正常に登録、発信、応答できます。しかし、音声に使用されるRTPポートはSIPシグナリングポートとは異なります。RTPパスがブロックされている、誤ったルーティング、不正な変換、または間違ったIPアドレスに送信されている場合、通話は正常な双方向音声なしで接続される可能性があります。

したがって、トラブルシューティングはSIP登録状態で止まってはいけません。正常に登録された電話でもメディアの問題が発生する可能性があります。エンジニアは、通話中に双方がRTPパケットを送受信できるかどうかを確認する必要があります。

NATは音声方向問題の一般的な原因

NATにより、ローカルエリアネットワーク内のデバイスはパブリックIPアドレスを介して外部ネットワークにアクセスできます。これは企業オフィス、支店、ホテル、工場、遠隔地で一般的です。IP電話またはSIPサーバーがNATの背後にある場合、デバイスはSIPまたはSDP情報でプライベートIPアドレスをアドバタイズする可能性があります。その後、リモート側は到達不能なプライベートアドレスにRTPパケットを送信しようとします。

これは、特にSIPサーバーがパブリックネットワークに展開され、IP電話が異なるLAN環境にある場合の、一方向音声の最も一般的な原因の1つです。通話は確立されるかもしれませんが、メディアストリームが正しい内部デバイスに戻れません。

これを解決するには、適切なNATトラバーサル設計を使用する必要があります。一般的な方法には、STUN、TURN、対称RTP、パブリックアドレスマッピング、ポートフォワーディング、SBC展開、またはSIPサーバーを介したメディアリレーがあります。最適な選択は、ネットワークトポロジと、システムがプライベートネットワーク内、パブリックネットワーク全体、または複数の支店間のいずれに展開されているかによって異なります。

ファイアウォールルールにはRTPトラフィックを含める必要がある

ファイアウォールポリシーも一方向音声の頻繁な原因です。多くの管理者はSIPシグナリングポートのみを開き、RTPポート範囲を忘れています。その結果、電話は登録でき、通話は作成できますが、音声パケットはファイアウォールを通過できません。

RTPは通常UDPポートを使用します。ポート範囲は、電話、PBX、SIPサーバー、SBC、またはメディアプラットフォームの構成によって異なります。多くのSIP環境では、RTPはUDP 16384-32768などの範囲、またはシステム管理者が定義した別のカスタム範囲を使用する場合があります。正確な範囲は、電話構成とサーバー構成の両方で確認する必要があります。

信頼性の高い双方向音声を得るには、ファイアウォールルールで必要なUDPメディアポートを双方向に許可する必要があります。展開に複数のVLAN、VPNトンネル、支店ルーター、クラウドサーバー、またはパブリックIPマッピングが含まれる場合は、各ネットワークセグメントを確認する必要があります。単一のブロックされたセグメントでも、一方向音声または音声なしの症状を引き起こす可能性があります。

RTPルーティングには明確なメディアパスが必要

IP電話の音声はRTPストリームによって伝送されます。RTP宛先アドレス、送信元アドレス、ポート、またはルーティングパスが正しくない場合、音声は一方向にしか機能しない可能性があります。これはパブリックネットワークシナリオだけでなく、プライベートLAN内部でも発生する可能性があります。

たとえば、電話とサーバーで異なるRTPポート範囲を使用している場合や、サーバーがメディアプロキシを経由することを期待しているのに、エンドポイントが直接別の電話にメディアを送信しようとする場合があります。一部のシステムはエンドポイント間の直接メディアをサポートしますが、他のシステムはすべてのRTPトラフィックがサーバーまたはSBCを通過することを要求します。このモードが正しく設定されていないと、一方向音声が発生する可能性があります。

展開中に、プロジェクトチームは音声パスがエンドポイント間、エンドポイント対サーバー、またはエンドポイント対SBCのいずれであるかを確認する必要があります。コールフロー内のすべてのデバイスは、到達可能なIPアドレスと互換性のあるRTPポート設定を使用する必要があります。

SIP ALGは通話を助けることも壊すこともある

多くのルーターとファイアウォールにはSIP ALG機能が含まれています。これはSIPパケットを検査および変更して、SIPトラフィックがNATをより簡単に通過できるように設計されています。理論的には便利に聞こえます。実際には、SIP ALGがSIPまたはSDP情報を誤って変更し、一方向音声、通話失敗、または不安定な登録を引き起こすことがあります。

ネットワークがすでに適切なSBC、パブリックアドレスマッピング、STUN、またはメディアリレーメカニズムを使用している場合、SIP ALGは不要になるか、有害になる可能性があります。多くのトラブルシューティング事例では、ルーターまたはファイアウォールでSIP ALGを無効にすることで一方向音声の問題を解決できます。

正しい選択はネットワーク設計によって異なります。SIP ALGを使用する場合は、慎重にテストする必要があります。システムがすでに制御されたNATトラバーサル方式を備えている場合は、SIP ALGを無効にすることが多くの場合より良い選択肢です。

コーデックネゴシエーションは一貫している必要がある

IP電話は通常、G.711、G.729、G.722などの複数の音声コーデックをサポートしています。これらのコーデックはSIPネゴシエーション中に選択されます。双方が互換性のあるコーデックを共有しない場合、通話に音声がなかったり、歪んだ音声、不安定なメディア動作が発生する可能性があります。

コーデックの不一致は常に一方向音声の最初の原因とは限りませんが、それでも確認する必要があります。これは、異なるベンダーの電話、ソフトフォン、ゲートウェイ、PBXプラットフォーム、録音システムを一緒に使用する場合に特に重要です。

実用的な解決策は、すべてのデバイスで共通のコーデックを優先することです。たとえば、G.711はそのシンプルさと音質からLAN環境でよく使用され、帯域幅が制限されている場合は圧縮コーデックが使用される場合があります。コーデック戦略は実際のネットワーク状態に一致させる必要があります。

電話側の設定は無視できない

一部の一方向音声の問題は、エンドポイント設定によって引き起こされます。IP電話のRTPポート設定、NATモード、SIPアカウント設定、メディアリレーオプション、ローカルネットワークインターフェース設定、またはコーデックの優先順位が間違っている可能性があります。場合によっては、電話がミュートになっている、受話器ケーブルが緩んでいる、またはスピーカーとマイクの設定が間違っていることもあります。

問題が1台または数台の電話だけで発生している場合は、エンドポイントの比較が役立ちます。エンジニアは正常に動作する電話と問題のある電話を比較し、SIPアカウント設定、ネットワークアドレス、RTPポート範囲、コーデックリスト、NATトラバーサルモード、ファームウェアバージョン、オーディオデバイスの状態を確認できます。

この方法は、すぐにグローバルサーバー設定を変更するよりも迅速であることがよくあります。問題が1つのエンドポイントに限定されている場合、根本原因は通常、そのエンドポイントまたはそのローカルネットワークに近い場所にあります。

サーバーとメディアプロキシの設定はすべての通話に影響する

SIPサーバーの構成も一方向音声を引き起こす可能性があります。メディアサーバーアドレス、RTPプロキシモード、外部IPアドレス、内部IPアドレス、ポート範囲、直接メディアポリシー、NAT処理、リレー設定はすべてRTPパスに影響を与える可能性があります。

これらの設定は慎重に調整する必要があります。グローバルサーバーの変更は同時に多くのユーザーに影響を与える可能性があるためです。一部の電話でのみ一方向音声が発生する場合は、コアサーバーパラメータを変更する前に、ネットワークトポロジとエンドポイント構成を分析することをお勧めします。

問題が複雑な場合は、パケットキャプチャとサーバーログが役立ちます。SIP/SDP情報とRTPパケットフローを確認することで、エンジニアはどのIPアドレスとポートがアドバタイズされているか、RTPストリームがどこに送信されているか、相手側がそれを受信しているかを確認できます。

マルチネットワークインターフェースがメディアを誤った方向に送信する可能性がある

一部のIP電話、SIPサーバー、ゲートウェイ、または通信プラットフォームには、複数のネットワークインターフェースがあります。たとえば、サーバーにはLAN用のインターフェース、パブリックネットワーク用のインターフェース、管理ネットワーク用のインターフェースがある場合があります。メディアサービスが誤ったインターフェースを選択すると、RTPパケットが誤ったパスに送信される可能性があります。

これにより、シグナリングは正常に見えても音声が正しく戻らない状況が発生する可能性があります。デバイスはSDPで間違ったIPアドレスをアドバタイズしたり、予期しないネットワークインターフェースからRTPパケットを送信したりする可能性があります。

これを防ぐために、プロジェクトチームは正しいバインドアドレス、ルーティングテーブル、デフォルトゲートウェイ、メディアインターフェース、NATマッピングを確認する必要があります。マルチNIC環境は展開時に明確に文書化する必要があります。

実用的なトラブルシューティングワークフロー

構造化されたトラブルシューティングプロセスは、ランダムなパラメータ変更よりも優れています。まず、問題がすべての通話で発生するのか、特定の電話のみで発生するのかを確認します。次に、影響を受ける通話が内部、外部、サイト間、VPNベース、またはパブリックネットワーク通話であるかを確認します。第三に、SIP登録と通話設定が正常であることを確認します。

その後、RTPに焦点を当てます。ファイアウォールポリシー、RTPポート範囲、NATトラバーサル設定、SIP ALGステータス、コーデックネゴシエーション、メディアリレーモード、サーバーの外部IP設定を確認します。問題が依然として不明な場合は、パケットキャプチャを使用して、RTPパケットが双方向に送受信されているかどうかを確認します。

適切なトラブルシューティングは通話パスに基づいています。完全なパスが明確になれば、一方向音声の問題ははるかに見つけやすくなります。

安定した双方向音声の計画

最善の解決策は、設計段階で一方向音声の可能性を減らすことです。小規模なLAN展開の場合は、ネットワークをシンプルに保ち、電話、PBX、ゲートウェイが一貫したRTP設定を使用するようにします。マルチサイト展開の場合は、電話を設置する前にNATトラバーサル、ファイアウォールルール、VPNルーティング、SBCの配置を計画します。

パブリックネットワークまたはクラウドPBX展開の場合は、通常、メディアリレーまたはSBCを使用してRTPパスを制御することをお勧めします。これにより、NAT関連の問題の多くを回避し、異なるネットワーク環境間の互換性を向上させることができます。

ドキュメントも重要です。SIPポート、RTPポート範囲、コーデックポリシー、NAT方式、サーバーIPアドレス、メディアプロキシ設定、ファイアウォールルールを将来のメンテナンスのために記録する必要があります。

結論

IP電話システムにおける一方向音声は、通常、単一の固定された問題によって引き起こされるわけではありません。NAT変換、RTPポートのブロック、誤ったファイアウォールポリシー、SIP ALGの干渉、コーデックの不一致、エンドポイント設定、サーバーのメディア設定、またはマルチネットワークインターフェースルーティングが原因である可能性があります。

適切な解決策は、SIPシグナリングとRTPメディアの違いを理解することから始まります。登録とダイヤルは正常に機能しても、音声伝送は失敗する場合があります。メディアパスを段階的に確認することで、プロジェクトチームは問題をより迅速に特定し、より安定したIP音声通信システムを構築できます。