内容

概要

前提条件

要件

使用するコンポーネント

背景

MoH の概要

メディア ストリームの無効化

MoH への接続

通話にメディア リソースを使用する場合

通話の再開

SDP 属性

CUBE 上の MoH

コーデックの考慮事項

MMoH

SIP 方向属性の操作

アドレス操作

フラッシュからのストリーミング

ライブ フィードからのストリーミング

MMoH の設定

通話に MTP を使用する場合

パフォーマンスに関する考慮事項

制約事項

トラブルシュート

Show コマンドと debug コマンド

シナリオ 1

シナリオ 2

シナリオ 3

シナリオ 4

関連情報

概要

このドキュメントでは、Cisco Unified Border Element（CUBE）を介した Multicast Music-on-Hold（MMoH）の操作、設定、およびトラブルシューティングについて説明します。

このドキュメントでは Multicast Music-on-Hold（MoH）を中心に扱いますが、ほとんどの部分で MoH の一般的な機能方法について説明します。この追加情報により、初心者が MMoH に固有の問題を認識し、理解するための基本的な知識を習得できます。

注：原則は同じですが、Cisco Unified Border Element サービス プロバイダー エディション（CUBE-SP）や、Cisco Unified Communications Manager（CUCM）を含まない環境での CUBE の使用については、このドキュメントでは扱いません。

前提条件

要件

このドキュメントに特有の要件はありません。

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。

背景

注：H.323 について説明したいくつかのシナリオを除き、Session Initiation Protocol（SIP）シグナリングを、このドキュメントのほとんどで使用しています。

MoH の概要

MoH は、発信者が通話を保留にすると必ず再生されます。通話の保留は、通話転送などの補足サービス プロセスが実行されるときに、ユーザまたはネットワークが開始します。前者はユーザ開始保留またはユーザ保留と呼ばれます。後者はネットワーク開始保留またはネットワーク保留と呼ばれます。

次に、MoH が時分割多重（TDM）ゲートウェイと連携する方法について確認します。次の図は、通話保留シナリオに関係するコンポーネントと接続を示しています。

コールを保留にするには、2ステップのプロセスが必要です。次の図は、関連する2ステップを示しています。

ヒント：MoH の設定を通じて並べ替えをするとき、および問題をトラブルシューティングするときには、この 2 ステップ プロセスを考慮に入れてください。

MoH ソース

コールを保留するユーザをホルダと呼び、保留にしたユーザ（およびMoHを聞いたユーザ）をホルディと呼びます。各側が再生する音楽の特定の側面を決定します。

保留音のソースは holder が決定します。この決定は次の階層に従って行われます。

1. ドメイン名（DN）で設定された保留音のソース

2. デバイスで設定された保留音のソース

3. デバイス プロファイルの保留音のソース（ユーザ保留音のソースのみ）

4. グローバル レベルの保留音のソース（サービス パラメータまたはサンプル）

保留音のソースには、ユーザ保留とネットワーク保留の 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 を指定します。

注：MMoH の場合は CUCM は、ネットワーク アドレスとしてマルチキャスト アドレス（239.1.1.1 など）を送信します。

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 通話）が識別されます。

通話の再開

再開プロセスは保留プロセスと同様ですが、順序が逆になります。

1. 現在のオーディオ ストリームは無効になります。

2. 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 上の MoH

CUBE を使用する場合も基本プロセスは変わりません。ただし、Cisco IOS? までは [5] CUBE が MoH を変換しないことを考慮することが重要です。バージョン 15.3T。これは、トランスコーダが不要となるように、CUCM-to-CUBE レッグでのコーデック選択に影響する要素を注意深く扱う必要があることを示します。

注：ここで参照されているトランスコーダは、CUCM の場合とは対照的に、CUBE によって挿入されます。 CUCM の場合、CUBE は destination であり、MOH のサーバと CUBE 間のパスにトランスコーダは含まれません。

コーデックの考慮事項

一般的に、CUCM-to-CUBE レッグで使用されるコーデックにはいくつかの要素が影響しますが、MoH の場合は以下の考慮事項が適用されます。

- MoHをトランスコードできません。[5]

- G.711 と組み合わせた場合にのみ MoH の音質がよくなる。

注：コーデックの考慮事項についてはすでに多数の優れたドキュメントが存在するため、このドキュメントではこのトピックの説明は省略します。

MMoH

注：このドキュメントでこれまで説明してきたほとんどの情報は、MoH がユニキャストとマルチキャストのどちらの IP パケットでストリーミングされるかに関連していました。

MMoH はシステム リソースと帯域幅を節約します。マルチキャストでは、保留音を提供するために、複数のユーザが同じオーディオ ソース ストリームを使用できます。MMoH は、帯域幅節約が重要である社内ネットワークでは理想的です。

CUBE がインターネットを介して MMoH を ITSP に受け渡す場合の懸念事項や問題点を次に示します。

- マルチキャスト トラフィックの範囲 - シスコはマルチキャスト保留音に 239.0.0.0 ～ 239.255.255.255 の範囲を使用します。この範囲は管理スコープ アドレスと呼ばれます。このブロックはプライベートと見なされます。つまり、企業ネットワークで使用され、社外には転送されません。境界ルータは通常、これに応じて設定されます。

- VPN 経由のマルチキャスト - デフォルトでは、IP セキュリティは MMoH をサポートしません。

次に、CUBE がどのように MMoH をサポートするかを示します。

1. CUBE が MoH サーバから MMoH パケットを受信します。

2. CUBE がパケットをユニキャスト IP パケットに変換します。

3. 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 フィールドで送信します。これはユニキャスト アドレスです。

次の図は、エンドツーエンドのビューを示しています。

注：CUBE は MMoH をサポートするために Cisco IOS バージョン 15.2(2) 以降を実行する必要があります。

フラッシュからのストリーミング

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 を設定するには、次の手順に従います。

1. MoH ソース、MoH サーバ、およびメディア リソース グループ（MRG）でマルチキャスト機能を有効にします。

2. 手順 1 で設定した MRG を使用して、MRG をトランクに割り当てます。

3. IP 音声ストリーミング アプリケーション サービス パラメータでコーデックを設定します。

注：詳しい設定手順については、『Cisco Unified Communications System 9.0 SRND - メディア リソース』の記事の「保留音」セクションを参照してください。

L3 対応スイッチでの MMoH の設定

L3 対応スイッチで MMoH を設定するには、次のコマンドを使用します。

ip routing

ip multicast-routing

通話に MTP を使用する場合

MTP はマルチキャスト保留音をサポートしていません。holdee は dead-air[7] のみを受信します。

注：トランスコーダも MTP です。

パフォーマンスに関する考慮事項

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 calls
最初のコマンドからの出力例を次に示します。
R1#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）オファーを提供できなくなったデバイスについてのみ確認されます。

次の図は、使用可能なチェックボックスを示しています。

注：詳細については、Cisco Bug ID CSCub64284 を参照してください。

シナリオ 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] のフローアラウンド モードの通話が失敗するが、将来の機能拡張の検討事項としてマークされます。

関連情報

- Cisco UBE でのマルチキャスト保留音サポート

- CallManager 保留音の FAQ

- テクニカル サポートとドキュメント – Cisco Systems

[1] 1 つのダイアログ内で別の会話を開始するには、どうすればよいですか。SIP では、ダイアログとは 3 つの tupe、<To タグ、From タグ、および Call-ID> を指します。この 3 つの tupe は、保留中に変更されることはありません。

[2] DO - 遅延オファー。

[3] クラスタ間トランク

[4] CUCM 8.5 以降。

[5] トランスコーディングは、Cisco IOS バージョン 15.3T 以降の MMoH に対して機能します。

[6] DO - 遅延オファー。

[7] Cisco Unified Communications Manager機能およびサービスガイド、リリース8.6(1)

[8] これらは、SIPトランクを設定するために使用されるSIPプロファイルの設定です。