CUBE を通した MMoH の操作、設定、およびトラブルシューティング ガイド
内容
概要
このドキュメントでは、Cisco Unified Border Element（CUBE）を介した Multicast Music-on-Hold（MMoH）の操作、設定、およびトラブルシューティングについて説明します。
このドキュメントでは Multicast Music-on-Hold（MoH）を中心に扱いますが、ほとんどの部分で MoH の一般的な機能方法について説明します。この追加情報により、初心者が MMoH に固有の問題を認識し、理解するための基本的な知識を習得できます。
前提条件
要件
このドキュメントに特有の要件はありません。
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
背景
MoH の概要
MoH は、発信者が通話を保留にすると必ず再生されます。通話の保留は、通話転送などの補足サービス プロセスが実行されるときに、ユーザまたはネットワークが開始します。前者はユーザ開始保留またはユーザ保留と呼ばれます。後者はネットワーク開始保留またはネットワーク保留と呼ばれます。
次に、MoH が時分割多重（TDM）ゲートウェイと連携する方法について確認します。次の図は、通話保留シナリオに関係するコンポーネントと接続を示しています。
コールを保留にするには、2ステップのプロセスが必要です。次の図は、関連する2ステップを示しています。
MoH ソース
コールを保留するユーザをホルダと呼び、保留にしたユーザ（およびMoHを聞いたユーザ）をホルディと呼びます。各側が再生する音楽の特定の側面を決定します。
保留音のソースは holder が決定します。この決定は次の階層に従って行われます。
- ドメイン名（DN）で設定された保留音のソース
- デバイスで設定された保留音のソース
- デバイス プロファイルの保留音のソース（ユーザ保留音のソースのみ）
- グローバル レベルの保留音のソース（サービス パラメータまたはサンプル）
保留音のソースには、ユーザ保留とネットワーク保留の 2 種類があります。保留音のソースを参照するときには、そのソースはユーザ保留とネットワーク保留のいずれかです。
MoH エンドポイント
MoH を使用するため、CUCM 側のエンドポイントは MoH サーバです。コーデックによる判別（相互リージョン コーデック設定に基づく）は、以下に基づくため、理解しておくことが重要です。
- MoH サーバ リージョン
- トランク／ゲートウェイ リージョン
一般的には、MoH サーバに専用リージョンを割り当てることが推奨されます。これにより、リージョンと他のすべてのリージョン間の内部リージョン コーデックは、g.711（または MoH 用に外部へストリーミングするその他のコーデック）になります。
CUCM の観点から、通話に含まれるエンドポイントは、2 台の電話機ではなく、次のとおりです。
- CUCM に登録された IP フォン
- ゲートウェイ/CUBE
したがって CUCM は、対象のゲートウェイ/CUBE を指すトランクをエンドポイントとして扱い、保留音ストリームのレンダリング方法を判別するために、関連付けられているリソースを調査します。
MoH VoIP プロトコル
MoH は定義上は片通話です。そのシグナリングの方法は、使用される VoIP プロトコルによって異なります。たとえば SIP では、direction 属性を介して送信されます。H.323 では CUCM は、ネットワーク アドレスとして 00000000 を指定し、H.245 Open Logical Channel Ack（OLCAck）メッセージの MoH サーバのポート（tsapIdentifier）として 0 を指定します。
CUBE を含む通話フローでは、CUCM は CUBE とインターネット テレフォニー サービス プロバイダー（ITSP）間のコール レッグを認識しません。 CUCM は、IP 電話と SIP トランク間のコール レッグ（CUBE につながる）にのみ関係します。
MoH のシグナリングのプロセスは、範囲を削減した新しい通話のシグナリングと同様です。SIP ではたとえば、通話はすでに存在するダイアログのコンテキスト内で行われます。[1]
メディア ストリームの無効化
前述の 2 ステップ プロセスの最初のステップでは、メディア ストリームを無効にします。
次の図は、SIP でメディア ストリームを無効にする方法を示しています。
SIPの実装は、一方または両方の属性(?a=?および？C=IN ?)は、メディアストリームが無効であることを示すために使用されます。
次の図は、H.323 でメディア ストリームを無効にする方法を示しています。
MoH への接続
前述の 2 ステップ プロセスの 2 番目のステップでは、MoH に接続します。オーディオ ストリームが無効になったら、CUCM は片方向 MoH 通話を発信するため、holdee は MoH ソースをリッスンします。
このプロセスの一環として CUCM は、holdee のメディア機能と、トランクに関連付けられているメディア リソース グループ リスト（MRGL）を考慮に入れてから、ストリーミングのパラメータを判別します。その結果、このシグナリングは必ず Delayed Offer（DO）[2]（SIP 内）になります。
INVITE トランザクションの実際の数値はさまざまです。たとえば CUCM は、1 つの DO INVITE トランザクションのみで holdee を MoH に接続します。あるいは、holdee のメディア機能を収集するために DO INVITE が使用され、それに続けて holdee を実際に MoH に接続するために EO INVITE が使用されます。
次の図は、SIP のトランザクションを示します。
次の図は、H.323 のトランザクションを示します。
次の図は、インターワーキング環境のシグナリング メッセージ シーケンスを示します（たとえば CUBE の片側は SIP、反対側は H.323 です）。
通話にメディア リソースを使用する場合
メディア リソース（MediaTermination Point（MTP）／トランスコーダ）は、ほとんどの部分の CUBE と IT サービス プロバイダー（ITSP）間のコール レッグを保護します。CUBE 経由の通話でメディア リソースを使用すると、ほとんどの場合、MoH のシグナリングには、CUCM とメディア リソース間の Skinny Client Control Protocol（SCCP）メッセージが含まれます。これは CUBE トランクではなく、保留中のメディア リソースであることに注意してください。MTP／トランスコーダが MoH をリッスンするようにとのシグナル通知を受けたら（SIP を想定）、CUCM は SIP UPDATE メッセージを CUBE に送信します。これにより branch パラメータが更新され、新しいトランザクション（MOH 通話）が識別されます。
通話の再開
再開プロセスは保留プロセスと同様ですが、順序が逆になります。
- 現在のオーディオ ストリームは無効になります。
- holdee を保留中の電話に再接続するために、別の DO re-INVITE が送信されます。
SDP 属性
Session Description Protocol(SDP)のX-cisco-media:umoh属性は、クラスタ間トランク(ICT)を介したMoHシグナリングを簡素化するために導入されました[3]。異なるプロトコルを使用するエンドポイント間の相互動作により、CUCM は多くの場合、非直感的で不適切な中間シグナリングを実行します。曖昧さを回避し、シグナリングのコンテキストを明示的にするために、X-cisco-media という独自の SDP 属性が使用されます。
CUCM バージョン 8.5 以降では、MoH がこの属性を Unicast Music on Hold（UMoH）または MMoH に設定するようにとのシグナル通知 [4] を受けることがあります。これにより、偽のポート値への依存が軽減され、held-party に対する MoH シナリオが示されます。
CUBE 上の MoH
CUBE を使用する場合も基本プロセスは変わりません。ただし、Cisco IOS? までは [5] CUBE が MoH を変換しないことを考慮することが重要です。バージョン 15.3T。これは、トランスコーダが不要となるように、CUCM-to-CUBE レッグでのコーデック選択に影響する要素を注意深く扱う必要があることを示します。
コーデックの考慮事項
一般的に、CUCM-to-CUBE レッグで使用されるコーデックにはいくつかの要素が影響しますが、MoH の場合は以下の考慮事項が適用されます。
- MoHをトランスコードできません。[5]
- G.711 と組み合わせた場合にのみ MoH の音質がよくなる。
MMoH
MMoH はシステム リソースと帯域幅を節約します。マルチキャストでは、保留音を提供するために、複数のユーザが同じオーディオ ソース ストリームを使用できます。MMoH は、帯域幅節約が重要である社内ネットワークでは理想的です。
CUBE がインターネットを介して MMoH を ITSP に受け渡す場合の懸念事項や問題点を次に示します。
- マルチキャスト トラフィックの範囲 - シスコはマルチキャスト保留音に 239.0.0.0 ～ 239.255.255.255 の範囲を使用します。この範囲は管理スコープ アドレスと呼ばれます。このブロックはプライベートと見なされます。つまり、企業ネットワークで使用され、社外には転送されません。境界ルータは通常、これに応じて設定されます。
- VPN 経由のマルチキャスト - デフォルトでは、IP セキュリティは MMoH をサポートしません。
次に、CUBE がどのように MMoH をサポートするかを示します。
- CUBE が MoH サーバから MMoH パケットを受信します。
- CUBE がパケットをユニキャスト IP パケットに変換します。
- CUBE がパケットを ITSP に転送します。
SIP 方向属性の操作
RFC 3264 に次のような説明があります。
「セッション記述に、受信（送信）のみとしてリストされているマルチキャスト メディア ストリームが含まれている場合は、発信側と受信側を含む参加者が、そのストリームで受信（送信）のみを実行します。これはユニキャスト ビューの場合とは異なります。ユニキャスト ビューでは、方向性に、発信側から受信側までのメディア フローが反映されます。RFC 2327 [1] では、この説明だけでなく、提案されたマルチキャスト ストリームのセマンティクスについて詳しく説明しています」
したがって、CUCM がマルチキャスト IP アドレスを使用して re-INVITE を送信すると、方向属性が recvonly に設定されます。ただし、CUBE はマルチキャスト パケットをユニキャスト パケットに変換するため、ITSP によりレッグで方向属性を sendonly に設定する必要があります。
次の図にこのロジックを示します。
アドレス操作
ITSP 送信者を IMoH ソースに接続するために送信される DO[6] re-INVITE では、CUBE がそれ自体の IP アドレスを SIP SDP C=IN フィールドで送信します。これはユニキャスト アドレスです。
次の図は、エンドツーエンドのビューを示しています。
フラッシュからのストリーミング
TDM ゲートウェイでは、追加の WAN 帯域幅の節約が、ゲートウェイからマルチキャスト保留音をストリーミングすることによって実現されます。したがって、MoH サーバが本社にあり、ゲートウェイが WAN 接続を経由するリモート支店にある場合、MoH を送信するマルチキャスト トラフィックは、WAN（本社から支店）を通過して貴重な WAN 帯域幅を使用する必要はありません。
CUBE は、ローカル フラッシュから、またはアナログ TDM インターフェイスを介して送信される MMoH をストリーミングできないトランク側デバイスです。ただし WAN 帯域幅を実現することは可能です。これには、MMoH ストリームの送信元としてリモート支店で別の音声対応ルータを使用します。このルータは、フラッシュから MMoH をストリーミングします。CUBE には、それらのパケットを受信し、変換し、ユニキャスト パケットとして渡すための信号を送信できます。
ライブ フィードからのストリーミング
ライブ フィードからストリーミングするには、前のセクションで説明したように CUBE が回線側デバイスでないため、別のルータを設定する必要があります。
MMoH の設定
このセクションでは、CUBE、CUCM、および L3 対応スイッチで MMoH を設定する方法について説明します。
CUBE での MMoH の設定
CUBE で MMoH を設定するには、次のコマンドを使用します。
ccm-manager music-on-hold
ip multicast-routing
CUCM での MMoH の設定
CUCM で MMoH を設定するには、次の手順に従います。
- MoH ソース、MoH サーバ、およびメディア リソース グループ（MRG）でマルチキャスト機能を有効にします。
- 手順 1 で設定した MRG を使用して、MRG をトランクに割り当てます。
- IP 音声ストリーミング アプリケーション サービス パラメータでコーデックを設定します。
L3 対応スイッチでの MMoH の設定
L3 対応スイッチで MMoH を設定するには、次のコマンドを使用します。
ip routing
ip multicast-routing
通話に MTP を使用する場合
MTP はマルチキャスト保留音をサポートしていません。holdee は dead-air[7] のみを受信します。
パフォーマンスに関する考慮事項
MMOH パケットはすべて、Cisco IOS で交換されるプロセスです。これは、小規模な展開の場合は問題ではありませんが、大規模な展開の場合は CUBE のパフォーマンスに大きく影響します。
制約事項
MMoH を使用する場合の制限事項を次にリストします。
- CUBE は Cisco IOS バージョン 15.2(2)T 以降である必要があります。
- MMoH は AS54xx ではサポートされていません。
- MMoH は ISR-G1（28xx、38xx シリーズ）ではサポートされていません。
- サポートされるコーデックに注目してください。
トラブルシュート
このセクションでは、MMoH のトラブルシューティングについて説明します。
Show コマンドと debug コマンド
show コマンドと debug コマンド、およびそれらの意味を次にリストします。
- Show ccm-manager music - CUBEがマルチキャスト音楽パケットのリッスン場所を認識していること、およびパケットを受信しているかどうかを確認するのに役立ちます。.
R1#show ccm-manager music
Current active multicast sessions : 1
Multicast RTP port Packets Call Codec Incoming
Address number in/out id Interface
===================================================================
239.176.201.1 16384 956/956 237 g711ulaw Se0/1/0 - Show ip igmp members - マルチキャスト保留音をリッスンするように指示する信号を受け取った CUBE がマルチキャスト グループに正常に参加したかどうかを確認するために使用します。
- これら 3 つのコマンドは、エンドポイントのネゴシエートされたコーデック、IP アドレス、およびポート番号を確認するために使用されます。
Show call active voice compact
最初のコマンドからの出力例を次に示します。
Show voip rtp conn
Show sip callsR1#show call active voice compact
<callID> A/O FAX T<sec> Codec type Peer Address IP R<ip>:<udp>
Total call-legs: 2
236 ANS T53 g711ulaw VOIP P1003 239.176.201.1:16384
237 ORG T53 g711ulaw VOIP P919789362814 200.200.200.2:17808 - Show call active voice brief - このコマンドは、通話が保留中のときに rx/tx カウントが増分されるかどうかを確認するために使用します。
0 : 236 29262010ms.1 (*22:34:23.659 UTC Fri May 10 2013)
+4190 pid:1000 Answer 1003 connected
dur 00:01:38 tx:919/147040 rx:918/146880 dscp:0 media:0 audio tos:0xB8 video tos:0x0
IP 239.176.201.1:16384 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
0 : 237 29262010ms.2 (*22:34:23.659 UTC Fri May 10 2013)
+4190 pid:2000 Originate 919789362814 connected
dur 00:01:38 tx:8910/1425600 rx:919/147040 dscp:0 media:0 audio tos:0xB8 video tos:0x0
IP 200.200.200.2:17808 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 - Show perf query class "Cisco MOH Device" - この CUCM CLI コマンドは、MoH リソースが割り振られているかどうか、およびその種類（ユニキャストまたはマルチキャスト）をすばやく確認するために使用します。 このコマンドは、複数の通話が保留になっている場合は役立ちません。通話が保留にされて再開されると、カウントが動的に変化するためです。
admin:show perf query class "Cisco MOH Device"
==>query class :
- Perf class (Cisco MOH Device) has instances and values:
MOH_2 -> MOHHighestActiveResources = 0
MOH_2 -> MOHMulticastResourceActive = 0
MOH_2 -> MOHMulticastResourceAvailable = 250000
MOH_2 -> MOHOutOfResources = 1
MOH_2 -> MOHTotalMulticastResources = 250000
MOH_2 -> MOHTotalUnicastResources = 250
MOH_2 -> MOHUnicastResourceActive = 0
MOH_2 -> MOHUnicastResourceAvailable = 250 - Debug ccm-manager music-on-hold - このコマンドは、コール レッグがどのように変更されるか（たとえば、最新の音声を無効にし、MoH を接続したとき）をトレースするために使用します。また、CUBE が CUCM からの指示どおりに Internet Group Management Protocol（IGMP）グループに参加するかどうかを検証することもできます。
- Debug ip packet - このコマンドは、Wireshark の代わりに確認のために使用されます。ただしこのコマンドは、ただちに CPU に過大な負荷をかけることがあります。そのため、確実に必要な場合にのみ使用してください。コンソールのロギングをオフにしてから実行し、実行時間は 1 秒以内に留めてください。
シナリオ 1
症状 - 公衆電話交換網（PSTN）からの通話が、双方向オーディオを使用して正常に確立される。ただし IP フォンが PSTN 発信者を保留にしてから通話を再開したため、片通話となり、結果としてIP フォン側では PSTN からの音声は聞こえるが、PSTN ユーザは IP フォンの音声が聞こえない。
まず、問題となっている SIP トランクで [Require SDP Inactive Exchange for Mid-Call Media Change] が無効になっていないことを確認します [5]。つまり CUCM が、存在するメディア パスを分断する目的で、SDP で a=inactive を指定した re-INVITE を送信できるようにします。
通話が保留になったら、CUCM は、SIP トランクに対して [Send send-receive SDP in mid-call INVITE] チェックボックスが有効になったときにメディア パスを分断するために、非アクティブ SDP を指定した re-INVITE を送信しなくなります [8]。この設定は、メディア モードが非アクティブに設定された後、完全な（send-recv）オファーを提供できなくなったデバイスについてのみ確認されます。
次の図は、使用可能なチェックボックスを示しています。
シナリオ 2
症状 - 通話が保留になったときに、発信者側に MMoH ではなく、呼び出し音のみが聞こえる。
通常、これは CUCM が MMoH を割り当てなかったことを示します。
- show perf query class(Cisco MOH Device)を使用します。を使用して、MOHOutOfResources カウントが増分されているかどうかを検証します。
- MMoH ソース、サーバ、およびグループでマルチキャストが有効になっていることを確認します。
シナリオ 3
症状 - 通話が保留になったときに無音状態になる。
次の点を確認します。
- 音声パスにある CUBE およびその他のルータでマルチキャスト ルーティングが有効になっている。
- 音声パスの L3 スイッチで IP ルーティングおよびマルチキャスト ルーティングが有効になっている。
- CUCM の MoH サーバで ttl（ホップ カウント）が、ホップに十分対応できる大きさに設定されている。
- トランスコーダが必要にな場合に、正常に割り当てられている。
- IP 音声ストリーミング アプリケーションで設定されているコーデックのリストで、MoH に使用されるコーデックがサポートされている。
シナリオ 4
症状 - [Call hold & Resume] でフローアラウンド モードに設定されている通話が失敗する。
フローアラウンドをサポートするには、re-INVITE を送信するか、IPIPGW からアップデートを送信する必要があります。ただし、これは現在サポートされていません。そのため、DO-EO 通話でのフローアラウンドはサポートされていません。マーケティングからこのような通話フローの要件が発生した場合は、サポートを検討してください。Cisco のバグ SIP SIP SS DO-EO: [Call hold & Resume] のフローアラウンド モードの通話が失敗するが、将来の機能拡張の検討事項としてマークされます。
関連情報
[1] 1 つのダイアログ内で別の会話を開始するには、どうすればよいですか。SIP では、ダイアログとは 3 つの tupe、<To タグ、From タグ、および Call-ID> を指します。この 3 つの tupe は、保留中に変更されることはありません。
[3] クラスタ間トランク
[5] トランスコーディングは、Cisco IOS バージョン 15.3T 以降の MMoH に対して機能します。
[7] Cisco Unified Communications Manager機能およびサービスガイド、リリース8.6(1)
[8] これらは、SIPトランクを設定するために使用されるSIPプロファイルの設定です。
フィードバック