UCM - CMS を利用した Ad Hoc 会議のトラブルシューティング

[sanakaza]

• はじめに
• 設定ガイド
• Ad Hoc会議の流れ
• よくある問題と確認事項
• 基本確認項目
• CUCM と CMS 間の SIP Trunk のステータスが Full Service にならない
• CUCM の Conference Bridge ステータスがRegistered にならない
• Ad Hoc 会議が開始しない
• Ad Hoc 会議参加者に映像や音声が流れない
• 関連ログ
• CUCM
• CMS
• 参考情報

はじめに

アドホック(Ad Hoc) 会議は、2拠点間で通話を行っているビデオ会議端末や電話機ユーザが、その場で3拠点以上の会議を開始したい場合に一時的に作成される多地点会議スペースです。Cisco Unified Communications Manager (CUCM) は Cisco Meeting Server (CMS) を多地点会議スペースのリソースとして利用することが可能です。

本ドキュメントでは CUCM および CMS を利用した Ad Hoc 会議に関連した問題のトラブルシュートについて記載します。

設定ガイド

Ad Hoc 会議を利用する場合は CUCM の Media Resources (Conference Bridge) に CMS を登録する必要があります。Conference Bridge 登録された CMS に対し、CUCM は会議スペースの作成・削除等を HTTPS (CMS API) で、コール制御を SIP で行います。

設定方法の詳細は下記のドキュメントを参照してください。

• Cisco Meeting Server および CUCM のアドホック会議の設定

Ad Hoc 会議の流れ

CUCM 登録のデバイス同士の 2者間の通話に他の参加者を追加することで Ad Hoc 会議が開始されます。下記は一般的な Ad Hoc 会議のシナリオです。

1. 2者間で通話中のコールを保留します
2. 追加したいデバイスにコールします
3. 元のコールに２コール目を "追加 (Merge)" します
4. 3拠点による Ad Hoc 会議が開始します
   
   

• さらに参加者を追加可能です
• 参加者が2拠点となった時点で Ad Hoc 会議は終了し、二者間の直接通話となります。

また、このシナリオでは各デバイス間で下記のような通信が行われています。

1. ユーザがコールの Merge を実施すると、CUCM は任意の会議番号をアサインし、CMS API 経由で CMS に会議スペースの作成をリクエストします
2. スペースが作成されると CUCM と CMS 間 (SIP trunk) で各参加デバイスごとの SIP コールが接続されます
3. 各参加デバイスと CMS 間で音声・ビデオストリームが送受信されます
   
   

• Ad Hoc 会議が終了すると CUCM と CMS 間の SIP コールが切断され、CUCM は CMS API で会議スペースの削除をリクエストします。

Ad Hoc 会議のコールフローの詳細、および CUCM のログに関する情報は下記のコミュニティ記事を参照してください。

UCM - CMS で AdHoc 会議を開催する際の Call Flow

 

よくある問題と確認事項

Ad Hoc 会議に関して、特に複数装置間の通信が関わる問題の切り分けやトラブルシュートを行う際に確認するべき項目を下記に記載します。

基本確認項目

• 各装置間のネットワークに疎通があり、SIP や HTTP、RTPトラフィックが許容されている
• 各装置が DNS サーバで正常に名前解決できる
• 各装置が NTP サーバと正常に時刻同期が取れている

CUCM と CMS 間の SIP Trunk のステータスが Full Service にならない

• SIP Destination (CMS 向け) ステータスが up となっている
  
• SIP Trunk の Destination アドレスとSIP ポートが正しく設定されている
• CUCM と CMS 間のネットワーク疎通があり SIP 通信が許容されている
• SIP が暗号化 (TLS) されている場合:
  • 有効な中間/ルート CA 証明が CallManager-trust store にアップロードされている
  • 証明書の SAN に SIP Trunk の Destination が含まれている
  • 該当 SIP Trunk に適用されている SIP Trunk Security Profile が正しく設定されている

CUCM の Conference Bridge ステータスが Registered にならない

• 適切な SIP Trunk が設定されている
• 証明書の SAN に 同一の Hostname/IP Address が含まれている
• Hostname が DNS サーバで正しく解決される
• HTTPS Interface Info に設定されている CMS ユーザに API アクセス権限があり、正しいパスワードが設定されている
• HTTPS ポートに CMS サーバの Web Admin ポートと同じポート番号が設定されている

Ad Hoc 会議が開始しない

• 上記 SIP Trunk と Conference Bridge のステータスが正常となっている
• 参加デバイスの Device/Device Pool に 適切な Media Resource/Group が紐づけられている
• Ad Hoc 会議が開始されたタイミングで CMS GUI の Configuration -> Spaces に スペースが作成される
  
• CMS のリソースに余裕があり、十分なライセンス数が適用されている

Ad Hoc 会議参加者に映像や音声が流れない

• CMS GUI の Status -> Calls に該当会議の参加デバイスが全て表示されている
  
• 各参加デバイスと CMS 間のネットワークにそれぞれ疎通があり、RTPトラフィック (UDP) が許容されている
• 各参加デバイスと CMS 間のネットワーク経路で顕著なパケットロスや遅延が発生していない

関連ログ

下記は Ad Hoc 会議関連の問題を切り分ける際に一般的に有用となるログです。事象内容により他のログ取得が必要な場合もあります。

各ログの取得方法は下記の関連記事を参照してください。

• CUCM - CUCMのトレースログを収集する方法
  CUCM - パケットキャプチャを収集する方法 (utils network capture-rotate)
• CMS - CMS のログを CMM(3.4 以降) から設定・生成・取得する方法
  CMS - パケットキャプチャの取得方法
  
  

CUCM

• Cisco CallManager
• Event Viewer-Application Log
• Event Viewer-System Log

• パケットキャプチャ

* Leaf クラスタ / SME 構成の CUCM の場合は関連するノード全てからからログを取得する必要があります。

CMS

• logbundle - ログ取得前に CMS GUI で下記項目の Detailed tracing を有効にします
  • SIP traffic tracing
  • API tracing
  • DNS tracing
• パケットキャプチャ

* クラスター構成の CMS の場合は関連するノード全てからからログを取得する必要があります。

参考情報

• Cisco Meeting Server および CUCM のアドホック会議の設定
• Configure Cisco Meeting Server and CUCM Ad hoc Conferences
• UCM - CMS で AdHoc 会議を開催する際の Call Flow

[sanakaza]

はじめに

アドホック(Ad Hoc) 会議は、2拠点間で通話を行っているビデオ会議端末や電話機ユーザが、その場で3拠点以上の会議を開始したい場合に一時的に作成される多地点会議スペースです。Cisco Unified Communications Manager (CUCM) は Cisco Meeting Server (CMS) を多地点会議スペースのリソースとして利用することが可能です。

本ドキュメントでは CUCM および CMS を利用した Ad Hoc 会議に関連した問題のトラブルシュートについて記載します。

設定ガイド

Ad Hoc 会議を利用する場合は CUCM の Media Resources (Conference Bridge) に CMS を登録する必要があります。Conference Bridge 登録された CMS に対し、CUCM は会議スペースの作成・削除等を HTTPS (CMS API) で、コール制御を SIP で行います。

設定方法の詳細は下記のドキュメントを参照してください。

• Cisco Meeting Server および CUCM のアドホック会議の設定

Ad Hoc 会議の流れ

CUCM 登録のデバイス同士の 2者間の通話に他の参加者を追加することで Ad Hoc 会議が開始されます。下記は一般的な Ad Hoc 会議のシナリオです。

1. 2者間で通話中のコールを保留します
2. 追加したいデバイスにコールします
3. 元のコールに２コール目を "追加 (Merge)" します
4. 3拠点による Ad Hoc 会議が開始します
   
   

• さらに参加者を追加可能です
• 参加者が2拠点となった時点で Ad Hoc 会議は終了し、二者間の直接通話となります。

また、このシナリオでは各デバイス間で下記のような通信が行われています。

1. ユーザがコールの Merge を実施すると、CUCM は任意の会議番号をアサインし、CMS API 経由で CMS に会議スペースの作成をリクエストします
2. スペースが作成されると CUCM と CMS 間 (SIP trunk) で各参加デバイスごとの SIP コールが接続されます
3. 各参加デバイスと CMS 間で音声・ビデオストリームが送受信されます
   
   

• Ad Hoc 会議が終了すると CUCM と CMS 間の SIP コールが切断され、CUCM は CMS API で会議スペースの削除をリクエストします。

Ad Hoc 会議のコールフローの詳細、および CUCM のログに関する情報は下記のコミュニティ記事を参照してください。

UCM - CMS で AdHoc 会議を開催する際の Call Flow

 

よくある問題と確認事項

Ad Hoc 会議に関して、特に複数装置間の通信が関わる問題の切り分けやトラブルシュートを行う際に確認するべき項目を下記に記載します。

基本確認項目

• 各装置間のネットワークに疎通があり、SIP や HTTP、RTPトラフィックが許容されている
• 各装置が DNS サーバで正常に名前解決できる
• 各装置が NTP サーバと正常に時刻同期が取れている

CUCM と CMS 間の SIP Trunk のステータスが Full Service にならない

• SIP Destination (CMS 向け) ステータスが up となっている
  
• SIP Trunk の Destination アドレスとSIP ポートが正しく設定されている
• CUCM と CMS 間のネットワーク疎通があり SIP 通信が許容されている
• SIP が暗号化 (TLS) されている場合:
  • 有効な中間/ルート CA 証明が CallManager-trust store にアップロードされている
  • 証明書の SAN に SIP Trunk の Destination が含まれている
  • 該当 SIP Trunk に適用されている SIP Trunk Security Profile が正しく設定されている

CUCM の Conference Bridge ステータスが Registered にならない

• 適切な SIP Trunk が設定されている
• 証明書の SAN に 同一の Hostname/IP Address が含まれている
• Hostname が DNS サーバで正しく解決される
• HTTPS Interface Info に設定されている CMS ユーザに API アクセス権限があり、正しいパスワードが設定されている
• HTTPS ポートに CMS サーバの Web Admin ポートと同じポート番号が設定されている

Ad Hoc 会議が開始しない

• 上記 SIP Trunk と Conference Bridge のステータスが正常となっている
• 参加デバイスの Device/Device Pool に 適切な Media Resource/Group が紐づけられている
• Ad Hoc 会議が開始されたタイミングで CMS GUI の Configuration -> Spaces に スペースが作成される
  
• CMS のリソースに余裕があり、十分なライセンス数が適用されている

Ad Hoc 会議参加者に映像や音声が流れない

• CMS GUI の Status -> Calls に該当会議の参加デバイスが全て表示されている
  
• 各参加デバイスと CMS 間のネットワークにそれぞれ疎通があり、RTPトラフィック (UDP) が許容されている
• 各参加デバイスと CMS 間のネットワーク経路で顕著なパケットロスや遅延が発生していない

関連ログ

下記は Ad Hoc 会議関連の問題を切り分ける際に一般的に有用となるログです。事象内容により他のログ取得が必要な場合もあります。

各ログの取得方法は下記の関連記事を参照してください。

• CUCM - CUCMのトレースログを収集する方法
  CUCM - パケットキャプチャを収集する方法 (utils network capture-rotate)
• CMS - CMS のログを CMM(3.4 以降) から設定・生成・取得する方法
  CMS - パケットキャプチャの取得方法
  
  

CUCM

• Cisco CallManager
• Event Viewer-Application Log
• Event Viewer-System Log

• パケットキャプチャ

* Leaf クラスタ / SME 構成の CUCM の場合は関連するノード全てからからログを取得する必要があります。

CMS

• logbundle - ログ取得前に CMS GUI で下記項目の Detailed tracing を有効にします
  • SIP traffic tracing
  • API tracing
  • DNS tracing
• パケットキャプチャ

* クラスター構成の CMS の場合は関連するノード全てからからログを取得する必要があります。

参考情報

• Cisco Meeting Server および CUCM のアドホック会議の設定
• Configure Cisco Meeting Server and CUCM Ad hoc Conferences
• UCM - CMS で AdHoc 会議を開催する際の Call Flow