原因: ビデオ通話が 15 分で切断される場合、一般的な問題はネットワークで構成されている TCP タイムアウト(ファイアウォール/ルーター)が SIP セッション期限切れタイマーより小さいです。 CallManager のデフォルトでは、SIP セッションの期限切れタイマーは 1800 秒に設定されます。

解決方法:

これを確認するには:

1. [CISCO UNIFIED COMMUNICATIONS MANAGER (CM) 管理を開きます。

2. [システムとサービス パラメータ] > をクリックします。
3. [サーバーとサービスの選択] の [サービス] ダイアログボックスドロップダウン リスト、Cisco Call Manager (アクティブ) を選択します。

4. SIP セッションの期限 が切れるタイマーを探します。

CUCM に登録されたデバイスはすべてこのタイマーを使用します。 デバイスが別のリモート デバイスとの通話中に、当事者の 1 人がセッションを更新し、再招待または更新を送信する必要があります。 この更新は、[セッションが期限切れタイマー] の半分より前に送信される必要があります ( 1800/2 = 900 秒 = 15 分)。 更新メッセージを受信していない場合は、通話が切断されます。

最初の INVITE でセッション タイマーを確認します。 更新 (INVITE / UPDATE)


をこの時間が終了する前に受信する必要があります。最初のユーザー エージェント クライアント /ユーザー エージェント サーバー (UAC/UAS) ネゴシエーションに基づいて、デバイスの 1 つが再招待を送信するときにセッションを更新します。 更新プログラムが UAC の場合、通話の開始者はセッションを更新する責任があります。 更新プログラムが UAS の場合、サーバーはセッションを更新する必要があります。 両方のエンドポイントから SIP デバッグ ログを収集し、これらの項目をチェックします。例

: パーティ A から CUCM 間の通話 B。最新表示が UAC のパーティ A と UAS のパーティ B:

1 の場合。     パーティ A は再招待/更新を CUCM に送信する必要があります。
2.     CUCM はパーティ B に再招待/更新を送信する必要があります。
3.     パーティ B は再招待を受け取り、200 OK でメッセージに応答します。
4.     CUCM はパーティ A に 200 OK を送信する必要があります。

1 つのデバイスが CUCM に再 INVITE メッセージを送信すると、CUCM は再 INVITE を他のパーティに送信します。 しかし、これがリモート側で受け取らない場合、これはの間にある一部のネットワーク デバイスが考えられます。 SIP 検査またはネットワーク設定のために、再招待/応答が側の 1 つには行っていない可能性が高い可能性があります。
デバイスで再招待が開始されない場合、デバイスに問題がある可能性があります。 さらに調査するために、Cisco Technical Assistance Center (TAC) を巻き込む。
 
Webex に行くゾーンの詳細構成領域で、[これはまだ行ってない場合] を試すリストで:
SIP UDP/IX フィルター モードを [デフォルトではなく] にオンにします]:
また、VCS-e でも SIP セッション タイマーをチェックしてください。

 
デフォルトでは、1800s [15 分] で、これは標準であり、ファイアウォールの TCP タイマーがここにも一致したことを確認しますが、VCS

でも効果があるかどうか確認するために、少し問題を起こしてください。これは SIP の構成構成> プロトコル>:


セッション更新間隔 (秒) がデフォルト値に設定されています。 3600 を試す場合があります。 しかし、この問題の実際の根本原因は、FWがセッションが使用されなくなったと思っている場合です。VCSは実際には問題はないと思い、セッションはまだ起動中と思っているがセッション/ポートでFIN/closeを受け取らない状態で、再使用を試み、通話は終了します。[case 2] は FW が接続を適切に閉じ、FIN/closeを送信し、VCSは通常の通話ドロップ/クリアを記録し、通話も終了します。 ここでセッション タイマーを変更すると、通話のステータスに関する通信の試行に対する ACK の受信に失敗した後、VCS がセッションをやめる場合を制御します。
 
問題を特定し、解決するのに少し役立ちます。 このタイマーの FW 設定によっては、この値を下げる必要がある場合があります。