内容

はじめに

前提条件

要件

使用するコンポーネント

Network Topology

問題

確認

解決方法

ソフトウェアメディアターミネーションポイント(MTP)

メディアフローアラウンド

メディアアンチトロンボーン

ネゴシエートされたメディアIP/ポートでSTUNパケットを送信するように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

注：ルータがIOS-XEを使用する場合は、次のコマンドを実行してRx/Txカウンタを検証します。

voice service voip

media bulk-stats

コール量が多いときにこのコマンドを実行することは推奨されません。CPU使用率が30 %未満のときに、このコマンドを実行してください。

解決方法

ソフトウェアメディアターミネーションポイント(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が含まれていることを確認します。

1. 注：ハードウェアMTPは、ダミーのRTPストリームを送信できません。 トランクに関連付けられたMRGLがソフトウェアMTPのみを起動することを確認します。ソフトウェアMTPはG711コールのみをブリッジできます。この回避策が機能するには、エンドツーエンドのコールフローでG711を使用する必要があります。

次の図は、WiresharkでのダミーRTPペイロードの表示を示しています。

メディアフローアラウンド

メディアフローアラウンドでは、シグナリングパケットはCUBEで終端および発信されますが、メディアパケットはCUBEをバイパスし、エンドポイント間で直接フローします。

voice service voip

media flow-around

メディアフローアラウンドを使用したコール

注意：コールのメディアを終了できないため、CUBEの機能に影響を与える可能性があります。RTPはCUBEをバイパスし、エンドポイント間を直接流れます。この場合、ITSP間で直接フローします。

Media Flow-Throughのダイヤルピアコンフィギュレーションモードは、グローバルコンフィギュレーションでMedia Flow-Aroundが設定されている場合は有効になりません。

コンフィギュレーション

1. グローバル設定でメディアフローアラウンドを設定します。

2. メディアフロースルーを使用した音声クラスメディアの作成

3. Media Flow-Throughが使用されることが予想されるすべてのダイヤルピアにVoice-Class Mediaを適用します。

4. この設定がないダイヤルピアは、グローバルに設定されているため、メディアフローアラウンドに分類されます。

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

メディアアンチトロンボーンを使用したコール

注：メディアアンチトロンボーンを設定する前に、http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/media-path.htmlで制限事項を検証してください。

ネゴシエートされたメディア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へのコールの送信に使用されるダイヤルピア、またはその両方で実行できます。