Cisco Webex ビデオプラットフォームセッションへの私のビデオコールは15分 (または任意の特定の時間の後) の後で落ちています

Cisco Webex ビデオプラットフォームセッションへの私のビデオコールは15分 (または任意の特定の時間の後) の後で落ちています。

Cisco Webex ビデオプラットフォームへのビデオコール接続は、15分後に切断されます。

SIP コールは設定された時間間隔の後で落ちています。

Cisco Webex ビデオプラットフォームへのエンドポイント接続は、15分後に切断されます。

ビデオ通話は15分後にドロップします。

 

この記事の原文は英語で書かれており、機械翻訳されています。 英語から多言語への機械翻訳の精度、正確性、または信頼性に関しては、明示的にも、暗黙にも、いかなるタイプの保証も行いません。 シスコは、コンテンツの不適切な翻訳または情報の使用によって生じた不正確な情報、エラー、または損害に対して責任を負いません。

メモ: CMR クラウドは Cisco Webex ビデオプラットフォームに名前を変更されました。 CMR クラウドの名前を引き続き参照しているリンクやテキストもありますが, 情報は従来どおり, 名称が変更されたサービスにも適用されます。

原因: ビデオコールがちょうど15分で切断するとき、一般的な問題はネットワークで設定される TCP タイムアウトが (ファイアウォール/ルータ) SIP セッション満了タイマーよりより小さいです。 CallManager のデフォルトでは、SIP セッションの有効期限タイマーは1800秒に設定されています。

解決策

これを確認する:

  1. シスコユニファイドコミュニケーションマネージャ (CM) の管理を開きます。
  1. をクリック システム > サービスパラメータ.
  2. サーバーとサービスの選択サービス ドロップダウンリストボックスで、[ シスココールマネージャ (アクティブ):
ユーザーにより追加された画像
  1. を探し SIP セッションの期限切れタイマー:
ユーザーにより追加された画像

CUCM に登録されるすべてのエンドポイントはこのタイマーを使用します。 エンドポイントが別のリモートエンドポイントとの呼び出しにある場合、いずれかのパーティがセッションを更新し、再招待または更新を送信することがあります。 この更新は、セッションの終了時間の半分 (1800/2 = 900 秒 = 15 分) 前に送信する必要があります。 受信した更新メッセージがない場合、呼び出しは切断されます。

最初の招待でセッションタイマーを確認します。 更新 (招待/更新) は、この時間が経過する前に受信する必要があります。
ユーザーにより追加された画像

最初のユーザーエージェントクライアント/User エージェントサーバー (UAC/UAS) ネゴシエーションに基づいて、エンドポイントの1つが再招待を送信するときにセッションを更新します。 再表示が UAC の場合、呼び出しのイニシエーターはセッションを更新する責任があります。 リフレッシュが UAS である場合、サーバはセッションをリフレッシュしなければなりません。 両方のエンドポイントから SIP デバッグログを収集し、これらの項目をチェックして下さい:

: パーティー B にパーティ A から CUCM になされるコール。復習がパーティー A とパーティ B の UAS の UAC である場合:

1.     パーティ A は CUCM に再招待/更新を送信するためにあります。
2.     CUCM はパーティ B に再招待/更新を送信するためにあります。
3.     パーティ B は再招待を受信し、200 OK でそのメッセージに応答します。
4.     CUCM はパーティー A に 200 OK を送信することがあります。

1つのエンドポイントが CUCM に再招待メッセージを送信する場合、CUCM はもう一方のパーティに再招待を送信します。 ただし、これがリモート側で受信されない場合は、その間にいくつかのネットワークデバイスがある可能性があります。 再招待/応答が SIP インスペクションかネットワーク設定による側面の1つに得ないことは非常に可能性のあるです。
エンドポイントが再招待を開始しない場合、エンドポイントに問題がある可能性があります。 さらに調査するためにシスコテクニカルアシスタンスセンター (TAC) に参加してください。
 
これが Webex に行くゾーンの高度な設定領域の [すでにない場合] を試してみるもののリストに:
を回し SIP UDP/IX フィルタモード 宛先 [デフォルトではありません]:
ユーザーにより追加された画像
同様に VCS e の SIP セッションタイマーをチェックして下さい。
 
デフォルトは 1800 [15 分] で、これは標準であり、ファイアウォールの TCP タイマーがここでも一致していることを確認する必要がありますが、VC でも効果があるかどうかを確認するためにこれを少しバンプすることができます。

これは 構成 > プロトコル > Sip:
ユーザーにより追加された画像

注: [セッションの更新間隔 (秒)] は既定値に設定されています。 3600を試すかもしれません。 しかし、ここでの問題の実際の根本は、FW がセッションがもはや使用されていないと考えているときです (ケース 1)、VCS が実際にそれが ok だと思って、セッションがまだアップしているが、そのセッション/ポートでフィン/クローズを受け取らず、それを再利用しようとしてコールが死ぬ[ケース 2] は、FW が適切に接続を閉じ、FIN/close を送信し、VCS は通常のコールドロップ/クリアを記録し、コールも死亡します。 ここでセッションタイマーを変更すると、コールのステータスに関して試行された通信の Ack を受信できなかった後に、VCS がセッションをあきらめたタイミングを制御するだけです。
 
それは私たちが問題を少し良く特定するのに役立ちます。 また、このタイマーの FW 設定によっては、この値を下げる必要があります。

この投稿記事は役に立ちましたか?