コラボレーション : Cisco MediaSense

MediaSense 抜けたオーディオか呼び出し情報

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

概要

この資料は Cisco MediaSense と 2 つを発行します出会うかもしれないし、提供しますそれらについてのトラブルシューティング情報を記述したものです。 MediaSense はそれで指示されるすべての通信を聞き取り、記録するプラットフォームを記録するコールです。 音声またはデータのどれである場合もあるその情報がきちんと受け取られないし、受け取られない場合、望まれるか、または期待されるように MediaSense に現われないかもしれません。 ただし、それは頻繁に設定またはネットワーク関連の問題です。

Pavan デーブによって貢献される、Cisco TAC エンジニア。

抜けたオーディオ

コールの最初の型はオーディオがないが、データが受け取られるところにです。 この場合、問題はアクセス コントロール リスト(ACL)、Communcations Cisco Unified マネージャ(CUCM)、または Cisco Unified Border Element (CUBE)においての設定かネットワーク関連の問題に一般的にあります。

問題のこの型を確認する最もよい方法は Cisco 実時間監視 ツール(RTMT)によって、引っ張りログを、あります検索するべき抜けた可聴周波コール ログのセッションID がコール制御ログが有効に なることを確かめることです。

集まった後コール制御は記録 し、それらを開き、セッションID を捜し、diskusage の下のサイズが 0 ではないことを確認します。 ログが size="0" を示す場合、MediaSense はおそらくオーディオを受け取らなかったし、そこにそういうわけでありません。

この例では、セッションID は 78e146437088a93 です。

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

検索するとき、特定 の セッション ID のための diskusage を述べる行を検査して下さい。 このエリアでは、記録属性にサイズがあることに注意します。 この例は MediaSense を意味する size="0" が CUCM か CUBE から、オーディオを受け取らなかったことを示したものです。

抜けたオーディオのそれ以上のトラブルシューティング に 役立つ ヒントに関しては、エラー トラブルシューティングを記録する参照 CUCM MediaSense コール

損失しているか不正 な 呼び出し情報

コールの第 2 型はデータが現在または変えられるところにです。 これらのシナリオでは、問題は CUBE または CUCM のコンフィギュレーションが原因です。

問題のこの型を確認する最もよい方法はコール制御ログが確かめ、RTMT によってそれらに有効に なることをアクセスすることです。 検索するべき抜けた可聴周波コール ログのセッションID を持つためにように youd して下さい。

含んでいたりしかし制限されない、MediaSense が受け取る呼び出し情報すべてが含まれている CCBU_CALL_CONTROL-6-BORDER_MESSAGE の下でテキスト ブロックを捜して下さい:

  • 呼び出しの発生位置
  • コールのディレクトリ番号(DN)
  • コーデックおよび大いに詳細

それがであるはずであるものここに何かが一致する 情報がどこに変わるか判別するために CUCM または CUBE のコールフローを分析する必要があるかもしれません。

これら二つの例は損失しているか不正 な 呼び出し情報においてのこれら二つの異なる問題を示します。

Example 1: -切られる電話番号

この例では、セッションID 5148fb9543011 の期待値は 19725551234 を示しますが、MediaSense は検索及び演劇の 197255512 だけを示します。

0000030499: 10.201.227.36: Oct 10 2014 15:42:16.512 -0400: %CCBU_CALL_CONTROL-6-
BORDER_MESSAGE: {Thrd=Pool-ams-thread-9} %[message_string=HttpPostClient-9:
executing POST http://10.201.227.36:8640/ora/SipAdaptorService/SipAdaptor/
addOrUpdateSession HTTP/1.1
{"sessionData": {
"callControllerIP": "10.201.227.33",
"callControllerType": "Cisco-CUCM",
"endPoints": [
{
"clusterid": "StandAloneCluster",
"conference": false,
"device": "SEP123456ABCDEF",
"displayName": "Agent 2102",
"dn": "2102",
"startDate": 1412970136508,
"tracks": [{
"codec": "PCMU",
"location": "/recordedMedia",
"mediaState": "ACTIVE",
"startDate": 1412970136508,
"track": 0,
"type": "AUDIO"
}],
"type": "NEAR_END",
"xRefci": "37328298"
},
{
"clusterid": "StandAloneCluster",
"conference": false,
"device": "S0/SU1/DS1-1@PAVAN-2811",
"dn": "197255512",
"startDate": 1412970136508,
"tracks": [{
"codec": "PCMU",
"location": "/recordedMedia",
"mediaState": "ACTIVE",
"startDate": 1412970136508,
"track": 1,
"type": "AUDIO"
}],
"type": "FAR_END",
"xRefci": "37328299"
}
],
"operationType": "ADD",
"recordingServer": "10.201.227.36",
"rtspUrl": "rtsp://10.201.227.36/5148fb9543011",
"sessionName": "5148fb9543011",
"sipServer": "10.201.227.36",
"startDate": 1412970136508,
"state": "ACTIVE",
"version": 7

MediaSense が最後の 2 ディジットの第 19725551234 を除去される受け取ったことにこの場合、注意して下さい。 この情報が CUCM から来るので、それはです CUCM がまたそれ以上のアップから切られた数をコールフロー受け取ったかどうかまたは確認するために検知 する次のインポートこれが CUCM 自体で起これば。

、このシナリオで、CUCM が Cisco バグ ID CSCuq20108 に説明がある問題を引き起こしたことをトラブルシューティングを判別しました促進して下さい、:

If the From header sent to a recording server exceeds 231 characters, the header
will get truncated if escaped characters are found. if the From header contains
escaped characters "@", (i.e. %40), the dynamic buffer allocation doesn't account
for this resulting in characters getting truncated.

Example 2: -電話番号無し

この例では、DN は SIP_TRUNK_CVP と呼ばれるデバイスから完全に不在です。

0014107576: 10.201.227.136: Sep 02 2014 16:50:30.484 -0500: %CCBU_CALL_CONTROL-6-
BORDER_MESSAGE: {Thrd=Pool-ams-thread-222081} %[message_string=HttpPostClient-222082:
executing POST http://10.201.227.136:8640/ora/SipAdaptorService/SipAdaptor/
addOrUpdateSession HTTP/1.1
{"sessionData": {
"callControllerIP": "10.201.227.133",
"callControllerType": "Cisco-CUCM",
"endPoints": [
{
"conference": false,
"device": "SEP12356ABCDEF",
"displayName": "Agent 3102",
"dn": "3102",
"startDate": 1409694630483,
"tracks": [{
"codec": "PCMU",
"location": "/recordedMedia",
"mediaState": "ACTIVE",
"startDate": 1409694630483,
"track": 0,
"type": "AUDIO"
}],
"type": "NEAR_END",
"xRefci": "65826764"
},
{
"conference": false,
"device": "SIP_TRUNK_CVP",
"dn": "",
"startDate": 1409694630483,
"tracks": [{
"codec": "PCMU",
"location": "/recordedMedia",
"mediaState": "ACTIVE",
"startDate": 1409694630483,
"track": 1,
"type": "AUDIO"
}],
"type": "FAR_END",
"xRefci": "65826763"
}
],

このシナリオでは、ログは前例に非常に類似したである MediaSense に送信 される DN 情報がないことを示します。 更に解決するために、CUCM が情報を確認する正しく受け取る必要があり、次に CUBE をことをチェックします。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 118600