CMS H.323 Gateway のトラブルシューティング

[Yusuke Yoshinaga]

• はじめに
• CMS H.323 Gateway とは
• トラブルシューティングに必要な情報
• 基本情報
• 再現手順・条件
• 切り分け
• ログ取得
• ログ解析
• syslog
• ダンプファイル
• 既知不具合の調査
• 参考

はじめに

本ドキュメントでは、Cisco Meeting Server(CMS) のH.323 Gateway 機能のトラブルシューティングについて記載します。

CMS H.323 Gateway とは

CMS の機能の一つで、外部H.323 機器との接続を行います。Gatekeeper 機能はありません。

[注] Release Note の「Note about a single Edge solution for Cisco collaboration products」に記載のとおり、H.323 Gateway 機能は将来的に削除することを予定しており、CMS にH.323 接続する場合には、Expressway を経由することを推奨しています。

 

トラブルシューティングに必要な情報

基本情報

問題を調査するために必要となる以下の情報を収集してください。

• CMS のソフトウェアバージョン
  • MMP コマンド「version」やWeb Admin のStatus > General ページで確認可能
• 構成の把握
  
  • CMS と関連機器のネットワーク接続構成
  • 関連機器の機種やソフトウェアバージョン
• 問題が発生した日付と時刻
  • CMS の時刻が正しく設定されていること
• 事象の把握
  • 発生する問題の症状
    • H.323 コールが接続できない
    • H.323 コールが接続後しばらくして突然切断される
    • H.323 コールは接続できるが、資料共有が正しく動作しない
    • H.323 コールでCMS のIVR に接続できるが、スペースのCall ID を入力しても認識されない
    • 等
  • 端末側で何らかエラーを検出しているか
• CMS 設定
  • MMP コマンド「h323_gateway」の実行結果
  • Web Admin のConfiguration > Outbound calls の内容
  • Web Admin のConfiguration > Incoming calls の内容
  • SFTP で「live.json」ファイルを取得

再現手順・条件

以下のような確認を行い、問題が発生する手順や条件を絞り込んでください。

• コールの方向
  • CMS からの発信またはCMS での着信
• 再現率
  • 同一の手順を実施し、必ず再現するか
  • 100% の再現率でない場合、おおよその再現率
• H.323 端末の機種など、端末側の差異が問題事象に影響するか

切り分け

• MMP コマンド「h323_gateway restart」でH.323 Gateway を再起動して問題事象が改善するか
• 問題事象が発生する端末がSIP で問題なく接続可能か
• 問題事象が発生したものとは別スペースへのH.323 コールは接続可能か

ログ取得

CMS - H.323 ゲートウェイのログ取得方法 を参照し、下記手順にて取得してください。

• 事前準備
  • 問題事象が発生する条件・手順を明確にしてください。
  • 問題事象が発生する最小構成でログを取得することで、効率的に解析を行うことが可能となります。
  • CMS や関連機器のシステム時刻を正しく設定してください。
  • CMS や関連機器のアドレス、会議名等を記録してください。
  • ログを取得した際の各手順の日付と時刻を記録してください。

1. trace_level を3 とする
2. 問題事象が発生するコールを開始
3. 問題事象が発生したことを確認
4. コールを終了
5. trace_level を0 に戻す
6. ログファイルを収集

ログ解析

syslog

基本的なログの読み方 

SX20(192.168.1.1) からH.323 Gateway に着信し、IVR(86091) 経由でスペース(sample.cospace) に入室した際のログを抜粋した例を以下に示します。

Jul 12 15:21:47 user.info labcms h323_gateway: INFO : created incoming H.323 call 1 (10)

-> H.323 コールを着信(call 1 はH.323 Gateway が内部でコールに付与するID)

Jul 12 15:21:47 user.info labcms h323_gateway: INFO : incoming H.323 call SX20-lab (192.168.1.1) -> sip:86091@labcms.example.com (1) (load: 1/100 work: 0/24)

-> CMS H.323 Gateway は着信したH.323 コール(1) をSIP に変換して同CMS のCall Bridge に転送

Jul 12 15:21:47 user.info labcms host:server: INFO : call 20: incoming encrypted SIP call from "sip:SX20-lab@127.0.0.1" to local URI "sip:86091@labcms.example.com"

-> Call Bridge がH.323 Gateway からSIP コールを着信(call 20 はCall Bridge が内部でコールに付与するID)

Jul 12 15:21:59 local0.info labcms host:server:  INFO : participant "SX20-lab@127.0.0.1" joined space 7b1f1b63-cc84-4f44-bb0d-3ad8fdcba9d1 (sample.cospace)

-> 端末がスペースに参加完了

Jul 12 15:22:04 user.info labcms h323_gateway:  INFO : Call ended by: H.323 (1)

-> 端末がH.323 コール(1) を切断

Jul 12 15:22:04 user.info labcms host:server:  INFO : call 20: ending; remote SIP teardown - connected for 0:16

-> H.323 Gateway がCall Bridge とのSIP コール(call 20)を切断

Jul 12 15:22:04 local0.info labcms host:server:  INFO : participant "SX20-lab@127.0.0.1" left space 7b1f1b63-cc84-4f44-bb0d-3ad8fdcba9d1 (sample.cospace)

-> 端末がスペースから切断完了

接続失敗時のログの例

H.323 Gateway が着信コールを拒否した場合には、以下のようなログメッセージを記録します。

下記の例は、CMS が同時受付可能なH.323 コールの上限100 に達し、101 コール目の着信を拒否したことを示しています。

Jul 11 10:16:48 user.info labcms h323_gateway: INFO : incoming H.323 call rejected (reached call limit)

ダンプファイル

H.323 Gateway コンポーネントがクラッシュし、ダンプファイルが生成されている場合、その内容をCisco TAC で調査することが可能です。

下記ドキュメント

• CMS - コンポーネントがクラッシュした際のトラブルシューティング

既知不具合の調査

Bug Search Tool で、既知の不具合を調査することが可能です。

例) キーワード「h.323」Product「Cisco Meeting Server 1000」

リリースノートの「Resolved issues」「Open issues」で修正済・修正予定の主な不具合について確認することも可能です。

参考

• CMS H.323 Gateway の設定例: 英語版 / 日本語版
• CMS H.323 Gateway Deployment Guide
• SR Collection(事例集)
  • CMS で max480p30 に設定した H.323 コールが接続できない