コラボレーション : Cisco MediaSense

エラー トラブルシューティングを記録する CUCM MediaSense コール

2016 年 10 月 27 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック

概要

エラーが組み込みブリッジのために記録するコールに現われるときこの資料に MediaSense を解決する方法を記述されています。

Pavan デーブおよびウィリアム ライアン ベネットによって貢献される、Cisco TAC エンジニア。

組み込みブリッジの MediaSense 基本的なコールフロー

このイメージは組み込みブリッジが使用されるとき MediaSense 基本的なコールフローを説明します: 

: IP Phone A に有効に なる記録があります。

これらのステップはコールフローを記述します:

  1. 右の IP Phone は左の IP Phone を呼出し、Cisco Unified Communications Manager (CUCM)によってコールを開始します。

  2. CUCM は宛先電話に場合を送り、コールセットアップを完了します。

  3. IP Phone A と IP Phone B 間の接続は今設定されます。

  4. IP Phone A の記録プロファイルはコールを受信するとすぐ、CUCM は MediaSense のセッションを設定する必要があると言います。 これはミリ秒ステップ 3 が始まった後完了します。

  5. コールは 2 台の電話の間で今設定されます、コールは組み込みブリッジによって分岐し、組み込みブリッジは MediaSense サーバに 2 つのリアルタイムトランスポートプロトコル (RTP)ストリームを送信します。

MediaSense の記録無し

MediaSense に記録がないことを示すエラーを受け取れば、ログを調べ、このセッションID を捜して下さい:

0000049583: 10.201.227.136: May 28 2014 11:27:09.022 -0400: %CCBU_COMMON-6-VSMS
 HTTP Info: {Thrd=Pool-capture-thread-2800} %[HTTP Response Body=<Session>
   <diskusage>
      <recording name="78e146437088a93-TRACK0" size="0" repository="/
recordedMedia" />
      <recording name="78e146437088a93-TRACK1" size="0"repository="/
recordedMedia" />
   </diskusage>
</Session>][HTTP Response Content Type=application/xml][HTTP Response Status
Code=200][logId=close-25668]: VSMS Received HTTP Response

この出力の size="0" はそのコールのためのサーバに記録されるオーディオがないことを示します。 これは一般的に RTP ストリームが電話から MediaSense サーバに到達しなかったことを意味します。 これが発生するとき、次 の ステップは電話が RTP トラフィックを送信 することを確認することです。

IP Phone 送信トラフィックを確認して下さい

IP Phone が RTP トラフィックを送信 することを確認する簡単は IP Phone Webページを表示することです。 これは Phone Configuration ページの内でまたはバルク Admin によって CUCM で手動で 有効に なります。

ストリーム 1 は他の IP Phone またはゲートウェイのリモートアドレスとの主要なコールです。 これは 2 つのストリームで構成されています: 第 1 は IP Phone で受け取られ、第 2 がもう一方の端に送信 されるオーディオのオーディオです。

MediaSense がコールレグの両方を記録することを確認するために、ページが複数回リフレッシュされるとき送信側パケットが増分することを確認するためにストリーム 2 およびストリーム 3 をクリックして下さい。 リモートアドレスはストリーム 2 およびストリーム両方 3.のための MediaSense サーバを示す必要があります。 2 つのストリームが MediaSense サーバへあるという原因はそれらの 1 つがストリーム 1 (レシーバ パケット)および他で受け取ったオーディオであるであるストリーム 1.のもう一方の端に(送信側パケット)送信 されるオーディオということであるといえます。

: 以前に記述されている呼び出しフローダイヤグラムについて、ステップ 3 はストリーム 1 であり、ステップ 5 の各レグはストリーム 2 およびストリーム 3.を示します。

このキャプチャはストリーム 1 を示します:

このキャプチャはストリーム 2 を示します:

: ページのリモートアドレス セクションの IP アドレスおよびポートに注意することは重要です。 これはテスト電話呼び出しのためのパケットキャプチャを奪取 するとき非常に重要です。

このキャプチャはストリーム 3 を示します:

ストリーム 2 およびストリーム 3 のデータを確認するとき、探すキー事柄は次のとおりです:

  • リモートアドレスは MediaSense サーバの IP アドレスです。

  • 各ストリームのポート番号はユニークです。

  • ページをリフレッシュするとき、送信側パケットの数は増加します。

これは RTP パケットが IP Phone によって送信されることを示します。

パケットキャプチャを行って下さい

IP Phone は RTP パケットを送信するかどうかそれでも不確実なら、次の企画はパケットキャプチャを行い、ストリームを再生することです。

パケットキャプチャを行う前に、CUCM のための IP Phone設定のこれらの設定が有効に なるようにして下さい:

  • PCポートへのスパン
  • PC Voice VLAN アクセス
  • PCポート

それから、設定を適用し、IP Phone をリセットして下さい。 これが完了する後、開いた Wireshark は 30秒 期間のパケットキャプチャを奪取 し。 ストリーム 2 および疑わしい IP Phone のストリーム 3 のためのリモートアドレス、またポートを記録するようにして下さい。 次に、例を示します。

  • ストリーム 2 - 10.201.227.147/40676
  • ストリーム 3 - 10.201.227.147/33358

パケットキャプチャが完了した、パケットキャプチャを開き、各ストリームのためのこれらのステップを完了して下さい:

  1. ip.addr == 10.201.227.147 && udp.port == 40676 によってフィルタリングして下さい

  2. 分析するべきナビゲート > デコードように

  3. ポップアップウィンドウで、RTP を『OK』 をクリック選択して下さい。

  4. テレフォニー > RTP > ストリーム 分析へのナビゲート。

  5. RTP ストリーム 分析では、プレイヤー > デコード > 演劇にナビゲート し、コールのレグが両方とも聞かれることを確認して下さい。

  6. 他のストリームおよびポートのためのステップ 1 〜 4 を繰り返して下さい。

トラブルシューティング

パケットキャプチャを行った、問題に出会い続ける MediaSense は正しく設定されること、そして IP Phone は MediaSense サーバに有効な RTP ストリームを、および送信すること確認する後そしてサーバと IP Phone 間のパスはチェックする必要があります。

パスにアクセス コントロール リスト(ACL)がないこと、そして RTP トラフィックをブロックしないし、フィルタリングしないようにして下さい。

重要事項

コールが CUCM と設定される疑わしい場合、詳しい CUCM への外観は記録 し、MediaSense をログオンします呼び出しID を見つけるために順序を開きます。 これはセッションID から見つけることができコール制御ログでこれに類似したに検知 します:

CallId: 74acba00-38c1ea2d-3a2937-f183000a@10.0.131.241
CallId: 74acba00-38c1ea2d-3a2938-f183000a@10.0.131.241

IP Phone が MediaSense が付いている 2 つのストリームを設定するので、オリジナル電話の各レグのための 1 つは、MediaSense セッションがきちんと設定されるかどうか確かめるために呼び出しID の 1 の CUCM ログを検索します。



Document ID: 117788