Cisco CallManager に登録されている TC エンドポイントのコール障害のトラブルシューティング

概要

このドキュメントでは、Cisco CallManager に登録されている Tandberg Codec（TC）エンドポイントで発生する一般的なコール失敗の問題のいくつかと、その解決策について説明します。

前提条件

要件

次の項目に関する知識が推奨されます。

H.323 デバッグ ログをキャプチャ する方法

注: 保護しますソケット ホスト（SSH）セッション出力をキャプチャ されます確認して下さい。

1. コーデック CLI への SSH はこれらのコマンドを入力し、:
   • ログ ctx H.323Packet デバッグ 9
   • ログ 出力の（これは SSH セッション ターミナルセッション 画面にすべてのログを出力します。）
2. コールを開始し、問題を再現して下さい。
3. ログ 出力を入力し、コマンドを離れて ctx H.323Packet デバッグを記録 して下さい。

セッション開始プロトコル（SIP）デバッグ ログをキャプチャ する方法

注: SSH セッション出力をキャプチャ されます確認して下さい。

1. コーデック CLI への SSH はこれらのコマンドを入力し、:
   • ログ ctx SIPPacket デバッグ 9
   • ログ 出力の（これは SSH セッション ターミナルセッション 画面にすべてのログを出力します。）
2. コールを開始し、問題を再現して下さい。
3. ログ 出力を入力し、コマンドを離れて ctx SIPPacket デバッグを記録 して下さい。

パケット キャプチャ エンドポイントを集める方法 TC エンドポイントから記録 します

1. Web GUI から > ログファイル 『Diagnostics』 を選択 し、フルパケット キャプチャとの拡張ロギングを有効に して下さい。
2. コールを開始し、問題を再現して下さい。 パケットキャプチャが 3 分の間しか有効に することができないことに注目して下さい。
3. Web GUI から > ログファイル 『Diagnostics』 を選択 し、完全なログ アーカイブおよびパケットキャプチャをダウンロードして下さい。

必要な他の情報

• 含まれるすべてのデバイスとのコールフローを完了して下さい
• 着番号および発番号
• 問題の日時は発生しました

使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

本書の情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。 稼働中のネットワークで作業を行う場合、コマンドの影響について十分に理解したうえで作業してください。

問題： CallManager の探索空間（CSS） /Partition 問題を呼出すこと当然の接続失敗

Cisco Unified Communications Manager （CUCM）に登録されている 2 つのエンドポイント間のコールは CUCM の CSS/Partition 問題が原因で失敗するかもしれません。

呼出すエンドポイント SIP ログをキャプチャ して下さい。 CUCM から来るエンドポイント SIP ログでこの "404 見つけられなかった」メッセージが現れます:

 |SIP/2.0 404 Not Found
 Via: SIP/2.0/TCP 172.16.2.55:5060;branch=z9hG4bK26e12a6fbed832;received=172.16.2.55
 Call-ID: 77fec00-564180a1-1eec8b-370210ac@172.16.2.55
 CSeq: 101 INVITE
 From: <sip:1502@172.16.2.55>;tag=158127671
 To: <sip:4659@172.16.2.53>;tag=654ba920aeef9e74
 User-Agent: Cisco-CUCM10.5
 Content-Length: 0

解決策

呼出すエンドポイントの CSS および呼出されたエンドポイントのパーティションをチェックするためにこれらのステップを完了して下さい。 呼出すエンドポイントの CSS を持っています呼出されたエンドポイントのパーティションを確認して下さい。

エンドポイントのデバイスおよび回線 レベルで CSS を割り当てることができます:

1. Device > Phone の順に選択 し、エンドポイントを選択し、ラインをクリックし、回線 レベルで Calling Search Space （CSS）をチェックして下さい。 この例では、CSS は回線 レベルで設定されません。 ただし CSS がディレクトリ番号 レベルにあれば、CSS のどちらかは呼出 し 番号の partiton がなければなりません:

   

2. 電話レベルで asigned CSS をチェックして下さい。 疑わしい呼出すエンドポイントを Device > Phone の順に選択 し、選択して下さい:

   

3. 呼出 し 番号のパーティションをチェックして下さい。 Device > Phone の順に選択 し、呼出されたデバイスを選択し、ラインをクリックし、ルート Partion をチェックして下さい:

   

4. 両エンドポイントの Partiton および CSS を確認した後、呼び出し側のデバイスの CSS に呼出されたデバイスのパーティションがあるかどうか確認して下さい:

   

   そうでなかったら、これは "404 検出されなかった」エラーの原因である可能性があります。

問題： 15 分後に SIP コール ドロップする（またはあらゆる特定時以降に）

普通は特定時 間隔のコール ドロップはファイアウォールで、ルータ設定される、SIP タイマーか TCP タイムアウトによって等引き起こされます。

解決策

丁度 15 分の呼出し切断が、見られるよくある問題 ネットワーク（ファイアウォール、ルータ）で設定される TCP タイムアウトのであるより少しよりとき SIP セッションはタイマー切れます。 デフォルトで CallManager で、SIP セッションはタイマー 1800 秒に設定 されます切れます。

これを確認するために、統一された CM Administration > システム > サービスパラメータ > Cisco Call Manager サービスを > 探される 『Cisco』 を選択 して下さい- SIP セッションはタイマー切れます。

CUCM に登録されているすべてのエンドポイントはこのタイマーを使用します。 エンドポイントが別のリモートエンドポイントのコールにあるとき、パーティの 1 つはセッションをリフレッシュしなければなり、再勧誘かアップデートを送信します。 このリフレッシュはセッション タイマー（1800/2 = 900 の半分が秒 = 15minutes）切れる前に送信 されなければなりません。 受け取ったリフレッシュ メッセージがない場合コールは切断されています。

頭文字のセッション タイマーがあるように誘います確認して下さい。 リフレッシュは（誘って下さい/アップデート）今回が切れる前に受け取る必要があります:

|INVITE sip:+1234@10.108.64.22:5060;transport=tcp SIP/2.0
 Via: SIP/2.0/TCP 10.110.68.38:5060;branch=z9hG4bK00eed555
 Call-ID: dbfe0000-4491f669-9fd00-16406c0a@10.108.64.22
 CSeq: 1 INVITE
 Contact: <sip:30048@example.com;gr=urn:uuid:f7a3a098-ead8-5512-85ef-26ae544d6547
   >;isfocus;x-cisco-tip
 From: "TP Conference 30048 - Test" <sip:30048@10.110.68.6>;tag=86251172C3B60000
 To: <sip:1234@10.108.64.22>;tag=25983910~226bf657-9d6c-4ad9-98a2-cf842fe1d733-52629917
 Max-Forwards: 70
 Route: <sip:proxy-call-id=53a00ced-68e1-4ecd-872b-1edbb9abc75b
 @10.110.68.6:5060;transport=tcp;lr>
 Route: <sip:proxy-call-id=53a00ced-68e1-4ecd-872b-1edbb9abc75b
 @10.110.68.6:5060;transport=tcp;lr>
 Allow: INVITE,ACK,CANCEL,OPTIONS,UPDATE,INFO,SUBSCRIBE,NOTIFY,BYE
 User-Agent: TANDBERG/518 (TC6.2.0.20b1616)
 Supported: timer,outbound,record-aware,X-cisco-callinfo
 Session-Expires: 1800;refresher=uac

最初のユーザ エージェント クライアント /User エージェント サーバ（UAC/UAS）ネゴシエーションに基づいて、エンドポイントの 1 つは再勧誘を送信 するときセッションをリフレッシュします。 リフレッシャが UAC である場合、コールの発信側にセッションをリフレッシュする責任があります。 リフレッシャが UAS である場合、サーバはセッションをリフレッシュしなければなりません。 SIP デバッグ ログを両エンドポイントから集め、これらの項目をチェックして下さい:

例： B.をパーティを楽しむためにパーティ A から CUCM になされるコール。 リフレッシャが UAC ついていたらパーティ B の A および UAS をパーティを楽しんで下さい:

1. A を CUCM に再勧誘/アップデートを送信しなければなりませんパーティを楽しんで下さい。
2. CUCM は B.をパーティを楽しむために再勧誘/アップデートを送信しなければなりません。
3. パーティ B は再勧誘を受け取り、200 OK のそのメッセージに応答します。
4. CUCM は 200 A.をパーティを楽しむために OK を送信 しなければなりません。

1 つのエンドポイントが CUCM に再勧誘メッセージを送る場合、CUCM は他のパーティに再勧誘を送信 します。 ただし、これがリモート側によってそして受け取られなければこれはいくつかのネットワークデバイスが理由で中間そうなったものである可能性があります。 再勧誘/応答が SIP インスペクションかネットワーク設定による側の 1 つに到達しないことは非常に可能性のあるです。

エンドポイントが再勧誘を始めない場合、それはエンドポイントにおける問題である可能性があります。 更に調査するために Cisco 技術的な Assitance センター（TAC）を含んで下さい。

問題： 特定時以降の H.323 コール ドロップ

H.323 コール コール ドロップ特定の時間に間隔の SIP と同様に、ネットワークまたはファイアウォール タイムアウト 設定が通常原因で発生して下さい。

解決策

H.323 コールでは、ラウンドトリップ遅延 要求（RTDR）メッセージはシーケンス番号と共に 30 秒毎にエンドポイント間の送信 されます。 各要求に関しては、応答は予期されます。

Cisco エンドポイントは H.245 マルチメディア システム コントロールメッセージの一部である RTDR/Round トリップ遅延 応答メッセージを利用します。 この keps アクティブ コール 管理のために使用されるコールの間に稼働した H.245 TCP セッション。 エンドポイントが RTDR のための応答を最初に受け取り、無応答がコールの間に受け取られれば、エンドポイントはコールを終了します。

このシナリオでは、H.323 デバッグ ログを集めればエンドポイントは問題を特定するために順序をログオンします。 H.323 デバッグ ログから、RTDR 要求および応答メッセージがあるように確認し、廃棄するかどうか調べて下さい。

この出力例では、エンドポイントはリモートエンドポイントに RTDR 要求を送信 し、リモート エンドから応答を受け取りません。 従ってそれはコールを切断します:

 014-09-23T21:37:01+10:00 corevcs1 tvcs: UTCTime="2014-09-23 11:37:01,
 711"Module="network.H.323" Level="DEBUG":  Dst-ip="10.0.20.11"  
 Dst-port="11012" Sending H.245 PDU: value MultimediaSystemControlMessage
 ::= request : roundTripDelayRequest : {   sequenceNumber 120

要求および応答は sequenceNumbers とトラッキングすることができます。

エンドポイント ログからのこの例は切断のための原因を示したものです:

2977610.83 H.323Call I: H.323_call_handler::handleDiscInd(p=349, s=1) 
Received disconnectindication (Cause: 12:18, H.323 cause: 3:18)- 
NetworkRejected Q85012977610.84 MC I: RemoteParticipant::
reevalRefMode(p=349,ch=2) set ref [Video (2): vid-off0x0@0.0  0k ] 
q= auto, t60=600012977610.84 ModesController I: ModesController::
resetRateLimit(ch=2)12977610.84 MC I: RemoteParticipant::modeChanged
(p=349, ch=2): ModesController wants torun mode: Video (2): vid-off 0x0@0.0  0k

問題： メディア リソース資源配分失敗による接続失敗

ビデオ コールの場合には、メディア リソース alocation 失敗が原因で失敗するコールは見られます。 たとえば、呼出すことおよび呼出されたエンドポイントがよくあるコーデックをそしてサポートしなければトランスコーダが必要となります、なぜなら Call Manager でデュアルトーン マルチ周波数（DTMF）ミスマッチが Media Termination Point （MTP）必要となります。

解決策

ビデオにトランスコードすることのために、PVDM2 のトランスコーダがビデオをサポートしないのでパケット音声 デジタル モジュール（PVDM3）デジタル信号プロセッサ（DSP）トランスコーダが必要となります。 transcoder/MTP が利用できない場合、503サービスが利用できない メッセージはエンドポイントに送られます:

SIP/2.0 503 Service UnavailableVia: SIP/2.0/TCP 10.101.15.13:
5060;branch=z9hG4bK954956da2012413dfb6ef80d6bc9e373.1;rportFrom:
 <sip:3550@10.102.254.4>;tag=47c4717d0db85e1aTo:
 <sip:1281@10.102.254.4>;tag=176803~66dd1c7a-eac9-42af-a69b-
18da1695a800-31478649Date: 
Wed, 19 Feb 2014 16:10:05 GMTCall-ID: 
c05df2acedcafd063eb5cf947ebc1efcCSeq: 100 INVITEAllow-Events: 
presenceReason: Q.850;cause=47Content-Length: 0 

これを解決することは、メディア リソース グループ/Media Resource Group リスト（MRG/MRGL）設定をチェックし、ビデオ transcoder/MTP を確認するために利用可能です。 MRGL は電話レベルまたはデバイス プール レベルのデバイスに割り当てることができます:

1. CallManger で Device > Phone の順に選択 し、問題がある選択し、デバイス プールおよび MRGL 設定をチェックして下さいデバイスを:

   

2. 電話の MRGL 設定がどれもではない場合、トランスコーダがあることをデバイス プール設定をチェックしなければなりません。
3. System > Device プールを選択し、デバイスに割り当てられるデバイス プールを選択して下さい:

   

4. リソース > Media Resource Group リストを『Media』 を選択 し、電話レベル/デバイス プール レベルで割り当てられる MRGL を選択し、MRGs をチェックして下さい:

   

5. MRGs に注意し、また、リソース > メディア リソース グループを『Media』 を選択 して下さい、また、注目される MRGs を選択して下さい。 追加してもらいます PVDM3 ハードウェア transcoder/MTP を確認して下さい。

   

問題： 不十分な帯域幅による接続失敗

少なからずコールが CUCM のデバイスの領域/Location の不十分な帯域幅設定が理由で接続が解除されるシナリオがあります。 領域がサポート エンドポイントができない低帯域幅に設定 されるとき、帯域幅」か「不十分な帯域幅」から SIP メディア ネゴシエーションが起こった後「意味する CallManager は原因 125 の "488 受諾可能ではないメディアを」送信 します。

SIP がこのメッセージ記述され、探されるようにエンドポイントをログオンする caputure を必要とします:

1459.81 SipPacket I: PacketDump: Proto: SIP, Direction: Incoming, Name: 488 
Not Acceptable Media, CSeq: 100 INVITE, RemoteAddress: 10.106.85.219:5060, 
CallId: 207b6ddb148ddf900ae2e2f844115837, Time: 1459811
	1459.81 SipPacket   SIP/2.0 488 Not Acceptable Media
	1459.81 SipPacket   Via: SIP/2.0/TCP 10.106.85.231:56280;
branch=z9hG4bK64e2eb4a1a3afd5f956a1547eb1c05ad.1;rport
	1459.82 SipPacket   Call-ID: 207b6ddb148ddf900ae2e2f844115837
	1459.82 SipPacket   CSeq: 100 INVITE
	1459.82 SipPacket   From: <sip:4657@example.com>;tag=2d98ee2065ba492d
	1459.82 SipPacket   To: <sip:1112@10.106.85.219>;
tag=10543~8c84fc84-78bb-de4d-3ac7-da2a9cab63d5-19683975
	1459.83 SipPacket   Server: Cisco-CUCM10.5
	1459.83 SipPacket   Date: Sun, 07 May 2015 14:36:41 GMT
	1459.83 SipPacket   Allow-Events: presence
	1459.83 SipPacket   Warning: 370 10.106.85.219 "Insufficient Bandwidth"
	1459.83 SipPacket   Reason: Q.850 ;cause=125
	1459.83 SipPacket   Content-Length: 0
	1459.83 SipPacket   
	1459.83 SipStack I: SipDialog(ui=3,s=9) sendInviteRejToStack (488:Not Acceptable Media)
	1459.84 SipCall I: sip_call_handler::handleSIPMCallRej(3/9/-1): Call rejected
 (cause: Not Acceptable Media)
	1459.84 MainEvents I: CallDisconnectRequested(p=3) remoteURI='sip:1112@10.106.85.219'
 cause=[normal('') 'LocalDisconnect']
	1459.84 MainEvents I: ParticipantLeftConference(c=2,p=3)
	1459.85 APPL_Media ERROR: AudioCtrlImpl::execute_disconnectInputOutput 
No mixer for (p=1,ch=61)
	1459.85 MainEvents I: CallDisconnected(p=3) remoteURI='sip:1112@10.106.85.219' 
causeToLocal=[disconnected('Not Acceptable Media') 'RemoteDisconnect'] 
causeToRemote=[normal('') 'LocalDisconnect']

解決策

この問題が起こる場合、両エンドポイントで設定される領域をチェックし、その間の領域関係をチェックして下さい:

1. 両方のデバイスを Device > Phone の順に選択 し、選択して下さい。 デバイスに割り当てられるデバイス プールをチェックして下さい:

   

2. デバイス プールをチェックしたら、CUCM の System > Device プールを選択し、両方のデバイス プールで設定される領域をチェックして下さい:

   

3. システム > 領域情報 > 領域を選択し、領域関係をチェックして下さい。 領域の可聴周波ビデオ帯域幅をチェックし、エンドポイントが選択されるように可聴周波/ビデオ帯域幅で動作できるようにして下さい:

   

上のスクリーン ショットで 1 つのエンドポイントが領域「トランク領域に」あり、他が「ローカル エンドポイント領域に」あることが仮定されます。

もう一つの回避策はビデオ コール帯域幅のための帯域幅が不十分である場合可聴周波コールとしてビデオ コールを試みることです。 チェックし、設定するためにこのプロシージャを使用して下さい:

1. 問題の呼び出し側のデバイスを Device > Phone の順に選択 し、選択して下さい。 このスクリーン ショットのパラメータがチェックされるかどうか確認して下さい。 それがチェックを外される場合、ビデオ コールが帯域幅に関する問題の場合にはオーディオに戻って下るようにそれをチェックして下さい:

   

   この問題は CallManager のロケーション設定が理由で起こる可能性があります。

   場所は電話レベルまたはデバイス プール レベルで割り当てることができます（電話レベルは高優先順位を奪取 します）。

2. 電話水平なロケーション設定をチェックし、> 電話『Devices』 を選択 し、呼出す両方、呼出されたエンドポイントの位置をチェックし:

   

   位置はまたデバイス プール レベルで適用します。 従って、両エンドポイントのデバイス プールをまずチェックして下さい:

   

3. [System] > [Device Pool] を選択します。 デバイス プールで、両方で割り当てられる位置を呼出すことおよび呼出されたエンドポイント チェックして下さい。 この例で位置はデバイス プール レベルで割り当てられません。 電話のロケーション 設定は使用されます:

   

4. 十分な帯域幅が呼出すことおよび呼出されたエンドポイント 位置の間で設定されるかどうか確認して下さい。 この例1 エンドポイントでローカル エンドポイント位置にあると仮定され、他の 1 つは Hub_None 位置にあり、オーディオ/ビデオおよび immersive コールすべてのための帯域幅は無制限で設定されます:

   

切断のための他の原因がある可能性があります。 Cisco Unified Communications Manager 管理 ガイドのページを Call Detail Records 参照して下さい 178、切断 原因コードのための 10.0(1) をリリースして下さい。