内容

概要

ビルトインブリッジを使用した基本的なMediaSenseコールフロー

MediaSenseに記録がない

IP Phoneがトラフィックを送信することの確認

パケットキャプチャの実行

トラブルシュート

重要事項

概要

このドキュメントでは、組み込みブリッジのコール録音でエラーが発生した場合のMediaSenseのトラブルシューティング方法について説明します。

ビルトインブリッジを使用した基本的な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台の電話機間でコールが設定され、コールは組み込みブリッジ経由で分岐し、組み込みブリッジは2つのReal-time Transport Protocol(RTP)ストリームをMediaSenseサーバに送信します。

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ページを表示することです。これは、CUCMの電話の設定ページで手動で有効にするか、Bulk Adminを使用して有効にします。

ストリーム1は、他のIP Phoneまたはゲートウェイのリモートアドレスを持つメインコールです。これは2つのストリームで構成されます。1つ目はIP電話で受信される音声で、2つ目は相手側に送信される音声です。

MediaSenseが両方のコールレッグを記録していることを確認するには、[Stream 2]と[Stream 3]をクリックして、ページが複数回更新されたときに送信者パケットが増加することを確認します。リモートアドレスは、Stream 2とStream 3の両方のMediaSenseサーバを示す必要があります。MediaSenseサーバへのストリームが2つある理由は、一方がStream 1で受信した音声(Receiver Packets)で、もう一方がStream 1のもう一方の端に送信した音声(Sender Packets)であるためです。

注：前に説明したコールフロー図を参照すると、ステップ3はストリーム1で、ステップ5の各レッグはストリーム2とストリーム3を参照します。

次のキャプチャは、Stream 1を示しています。

次のキャプチャは、Stream 2を示しています。

注：ページの[Remote Address] セクションのIPアドレスとポートに注目することが重要です。これは、テスト電話コールのパケットキャプチャを取得する場合に非常に重要です。

次のキャプチャは、Stream 3を示しています。

Stream 2とStream 3のデータを確認する際には、次の点を確認する必要があります。

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

- 各ストリームのポート番号は一意です。

- ページを更新すると、Sender Packetsの数が増加します。

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

パケットキャプチャの実行

IP PhoneがRTPパケットを送信するかどうかが依然として不明な場合は、パケットキャプチャを実行し、ストリームを再生します。

パケットキャプチャを実行する前に、CUCMのIP Phone設定で次の設定が有効になっていることを確認します。

- PCポートへのスパン

- PC音声VLANアクセス

- PCポート

次に、設定を適用し、IP Phoneをリセットします。これが完了したら、Wiresharkを開き、30秒間のパケットキャプチャを実行します。該当するIP PhoneのStream 2とStream 3のリモートアドレスとポートを必ず記録してください。以下に、いくつかの例を示します。

- ストリーム2:10.201.227.147/40676

- ストリーム3:10.201.227.147/33358

パケットキャプチャが完了したら、パケットキャプチャを開き、各ストリームについて次の手順を実行します。

1. ip.addr == 10.201.227.147 && udp.port == 40676でフィルタリングします。

2. [Analyze] > [Decode As] に移動します。

3. ポップアップウィンドウでRTPを選択し、OKをクリックします。

4. [Telephony] > [RTP] > [Stream Analysis] に移動します。

5. RTPストリーム分析で、[Player] > [Decode] > [Play] に移動し、コールの両方のレッグが聞こえることを確認します。

6. もう一方のストリームとポートに対してステップ1 ～ 4を繰り返します。

トラブルシュート

パケットキャプチャを実行し、MediaSenseが正しく設定されていること、およびIP Phoneが有効なRTPストリームをMediaSenseサーバに送信していることを確認した後で、引き続き問題が発生する場合は、サーバと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ログを検索します。