CUBEでのヘアピンコールに関する音声が通らない問題のトラブルシューティング
はじめに
このドキュメントでは、Cisco Unified Border Element(CUBE)でのヘアピンコールに関する音声の無方向問題をトラブルシューティングする方法について説明します。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- Session Initiation Protocol（SIP）
- CUBEの設定および使用方法
- メディアフロースルーおよびフローアラウンド
使用するコンポーネント
このドキュメントの情報は、次のハードウェアとソフトウェアのバージョンに基づいています。
- Cisco Unified Communications Manager(CUCM):11.5.1.10000-5
- CUBE - 15.5(3)S5
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
Network Topology
問題
ヘアピンコールは、ITSPに転送または転送されて戻されるInternet Telephony Service Provider(ITSP)からの着信コールです。この結果、音声は流れず、IP電話からITSPへの通常のコールは正常に動作します。
SIP RFC 3264に従い、SIP User Agent Client(UAC)とSIP User Agent Server(UAS)間のメディアソケットネゴシエーションは、オファー/アンサーモデルのSession Description Protocol(SDP)を通じて行われ、すべてのVoice over IP(VoIP)製品メーカーがこれに続きます。
一部のITSPは、ファイアウォールの実装のためにSDPのIPアドレスとポート情報を考慮しないため、遠端（この場合はCUBE）でソケットを開始する必要があります。ITSPは遠端に対してReal-Time Transport Protocol(RTP)パケットを送信することを要求し、ITSPはRTPパケットを受信すると、受信したパケットの送信元IPにパケットを送信します。
IP PhoneとITSP間のコールでは、ヘアピン機能がないため、この問題は発生しません。これは、IP Phoneが必要なポートを開いた後にダミーのRTPパケットを送信するためです。
ITSPからコールが着信し、そのコールに返信されると、コールの発信側と受信側の両方が、コールのパス内の他者からストリームを受信しない限り、ストリームを送信しません。これはデッドロック状態です。
確認
接続が正常に確立されたことを確認するには、show voip rtp connectionsコマンドを実行します。
Max Ports Available: 19999, Ports Reserved: 101, Ports in Use: 4
Port range not configured, Min: 8000, Max: 48199
Ports Ports Ports
Media-Address Range Available Reserved In-use
Default Address-Range 19999 101 4
VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP
1 21 22 16424 16568 10.106.36.169 10.106.108.72
2 22 21 16426 24602 10.106.36.169 10.106.123.29
3 23 24 16428 24600 10.106.36.169 10.106.123.29
4 24 23 16430 16570 10.106.36.169 10.106.108.72
Found 4 active RTP connections
show call active voice briefコマンドを実行して、CUBEから見た4つすべてのコールレッグのRx/Txカウンタが0/0であることを確認します。
Total call-legs: 4 35E9 : 21 7441740ms.1 (*13:00:22.857 UTC Sat May 20 2017) +4080 pid:123 Answer 5655 connected dur 00:24:17 tx:0/0 rx:0/0 dscp:0 media:0 audio tos:0xB8 video tos:0x0 <<<< IP 10.106.108.72:16568 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a LostPacketRate:0.00 OutOfOrderRate:0.00 35E9 : 22 7441740ms.2 (*13:00:22.857 UTC Sat May 20 2017) +4080 pid:123 Originate 7961 connected dur 00:24:17 tx:0/0 rx:0/0 dscp:0 media:0 audio tos:0xB8 video tos:0x0 <<<< IP 10.106.123.29:24602 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a LostPacketRate:0.00 OutOfOrderRate:0.00 0 : 23 7441780ms.1 (*13:00:22.897 UTC Sat May 20 2017) +4020 pid:124 Answer 5655 connected dur 00:24:17 tx:0/0 rx:0/0 dscp:0 media:0 audio tos:0xB8 video tos:0x0 <<<< IP 10.106.123.29:24600 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a LostPacketRate:0.00 OutOfOrderRate:0.00 0 : 24 7441780ms.2 (*13:00:22.897 UTC Sat May 20 2017) +4010 pid:124 Originate 7961 connected dur 00:24:17 tx:0/0 rx:0/0 dscp:0 media:0 audio tos:0xB8 video tos:0x0 <<<< IP 10.106.108.72:16570 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a LostPacketRate:0.00 OutOfOrderRate:0.00
voice service voip media bulk-stats
解決方法
ソフトウェアメディアターミネーションポイント(MTP)
これは、この問題を解決するための推奨される方法です。CUCMソフトウェアMTPは、ダミーのRTPパケットを送信できます。ヘアピンコールでは、ソフトウェアMTPはダミーのRTPパケットをコールの発信側と受信側の両方に供給します。そのため、ITSPはこれらのパケットを受信し、ソフトウェアMTPにRTPで応答します。
Trunk ConfigurationページでMedia Termination Point Requiredチェックボックスにチェックマークが付いていることを確認します。Device > SIP trunkの順に移動し、そのトランクのMedia Resource Group List(MRGL)を選択して、少なくとも1つのソフトウェアMTPが含まれていることを確認します。
次の図は、WiresharkでのダミーRTPペイロードの表示を示しています。
メディアフローアラウンド
メディアフローアラウンドでは、シグナリングパケットはCUBEで終端および発信されますが、メディアパケットはCUBEをバイパスし、エンドポイント間で直接フローします。
voice service voip media flow-around
メディアフローアラウンドを使用したコール
Media Flow-Throughのダイヤルピアコンフィギュレーションモードは、グローバルコンフィギュレーションでMedia Flow-Aroundが設定されている場合は有効になりません。
コンフィギュレーション
- グローバル設定でメディアフローアラウンドを設定します。
- メディアフロースルーを使用した音声クラスメディアの作成
- Media Flow-Throughが使用されることが予想されるすべてのダイヤルピアにVoice-Class Mediaを適用します。
- この設定がないダイヤルピアは、グローバルに設定されているため、メディアフローアラウンドに分類されます。
Voice service voip
media flow-around
voice-class media 10 media flow-through dial-peer voice 1 voip Description ** Inbound dial-peer ** voice class media 10 dial-peer voice 2 voip Description ** Outbound dial-peer ** voice class media 10
メディアアンチトロンボーン
この機能はメディアフローアラウンドと同様に動作しますが、影響は少なくなります。まず、ループされたコールまたはヘアピンコールを検索します。ヘアピンコールが見つかった場合、この機能は特定されたコールに対して別のメディアネゴシエーションのラウンドをトリガーします。このネゴシエーションが終了すると、CUBEはメディアパスの一部ではなくなります。
CUBEとITSPの両方が、アンチトロンボーン機能をサポートする必要があります。
voice service voip media anti-trombone
メディアアンチトロンボーンを使用したコール
ネゴシエートされたメディアIP/ポートでSTUNパケットを送信するようにCUBEをイネーブルにします。
ネゴシエートされたメディアパスを介して送信される、ローカルに生成されたSTUN要求/パケット（これらのSTUNパケットは、同じメディアIP/ポート番号を持つUDPパケット）をCUBEが送信できるようにします。これらのデバイスが実際のアプリケーションデータを確認していない場合、メディアパス内のデバイスは、IP/ポート/トランスポートプロトコルを確認した後で、これらのSTUNパケットを取得した後パスをクリアできます。
音声サービスVOIP
stun
stun flowdata agent-id 1ブートカウント4
stun flowdata shared-secret 0 Password123$
voice class stun-usage 1（音声クラスstun使用1）
stun usage firewall-traversal flowdata
ダイヤルピア音声2000 voip
ITSP **から**着信ダイヤルピアの説明
voice-class stun-usage 1（音声クラスstun使用1）
これは、ITSPからのコールの受信に使用されるダイヤルピア、ITSPへのコールの送信に使用されるダイヤルピア、またはその両方で実行できます。
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
19-Jul-2023 |
初版 |
フィードバック