この質問がかなり「突飛」であることは承知していますが、SonicWALL の背後で SIP 経由の VOIP に成功した人はいますか。一方向のオーディオ受信に問題があります。
基本的に、電話をかける人（または電話を受ける人）は私の声を聞くことができますが（PBX と同じ LAN 上の電話から）、私たちは彼らの声を聞くことができません。パケット キャプチャでは、RTP トラフィックが Sonic に戻ってきて PBX 宛になっていることが示されていますが、PBX に到達できません。私の理解では、SonicWALL は対称 NAT を使用しており、このタイプの NAT では STUN が機能しないため、これが問題になっています。
回避策はありますか、または成功した人はいますか?
答え1
SIP トランクの場合は、PBX の IP が「外部」 IP であることを伝え、sonicwall で tcp/5060 と udp/[rdp 範囲] を PBX に転送することで、回避できる可能性があります。rtp 範囲は PBX で設定できます。必要な SIP エンドポイントは 1 つだけ (PBX - すべての電話は PBX 経由で外部と通信します) なので、stun などの「巧妙な」操作は必要ありません。
RTP トラフィックが実際に SonicWall に到達していて、RFC 1918 アドレスに送信されているためブラックホールに落ちているだけではないのであれば、最初の部分は既に完了しているようです。
答え2
Sonicwall のメイン メニューには「VoIP」タブがあります。「一貫性のある NAT を有効にする」が選択されていますか? 選択すると役立ちます。SIP 変換は必要ありませんが、スクリーンショットまたはその画面を投稿していただければ、いくつかのことを試すことができます。
答え3
SIP アルゴリズムがサポートされていること、および標準 SIP ポート (5060) を使用していることを確認するか、使用している SIP ポートを「監視」するように SIP アルゴリズムを変更します。
一方向オーディオの原因は、ファイアウォール/ルーターが着信 UDP メッセージ/オーディオをどこに送信するかがわからないため、ドロップされるからです。
SIP ALG が有効になっている場合、電話の通話と音声の送信先が追跡されます。
答え4
私の VoIP システムでも同じ問題が発生しましたが、回復するために使用できるトピックが 2 つあります。
- VoIP NAT トラバーサルのトピックをご覧ください。
- サービスの NAT を忘れて、代わりに VPN またはトンネルを使用します。
私はMikrotikを使用してP2P(IP-IP)トンネルの問題を解決し、静的ルートの問題を解決しました。