目錄

簡介

必要條件

需求

採用元件

SCCP保持連線和故障切換機制

Keep-alive

容錯移轉

正常故障轉移

延遲故障轉移

缺點

優勢

SIP保持連線

至主要

至次要

需要日誌

相關連結

從電話擷取

從CUCM捕獲

案例研究1.2

問題描述

疑難排解

解析

案例研究2.

問題描述

疑難排解

分析

保持連線丟棄的原因

簡介

本檔案介紹可用於對組態進行疑難排解的資訊。

除了網路層級TCP保持連線機制之外，Cisco IP電話還使用應用層級保持連線機制。適用於精簡型通話控制通訊協定(SCCP)和作業階段啟始通訊協定(SIP)裝置的保持連線機制可確保裝置持續使用通話控制進行註冊。它們還旨在通過呼叫控制重建裝置連線。

必要條件

需求

本文件沒有特定需求。

採用元件

本文件所述內容不限於特定軟體和硬體版本。

SCCP保持連線和故障切換機制

SCCP使用TCP協定進行傳輸，並使用埠2000和2443（對於安全埠）連線到Call Manager。SCCP電話應在註冊到Cisco Unified Communications Manager(CUCM)之前建立TCP連線。之後，將在埠2000上進行TCP 3次握手，以建立通訊通道。電話通過向CUCM傳送SYN（同步）來發起此連線，CUCM使用SYN、ACK（確認）進行響應。 電話反過來會使用ACK進行響應，然後建立TCP連線。

Keep-alive

有兩種保持連線的方法：應用層級(SKINNY keep-alive)和網路層級(TCP keep-alive)

容錯移轉

在理想情況下，SCCP電話保持建立到主CUCM和第一個備份CUCM的TCP連線。SCCP電話將保持連線傳送到已建立TCP連線的所有CUCM。然後，主伺服器響應SCCP保持連線。主伺服器的時間間隔為30秒，備份伺服器的時間間隔為60秒。

主CUCM使用SCCP keepalive ACK進行響應，確認SCCP和TCP連線。備份CUCM僅向電話傳送的保持連線傳送TCP ACK。當電話由於Call Manager服務不可用或主CUCM的TCP連線本身不可用而未能備份CUCM時，它使用兩種機制來檢測主CM故障，並且它們是正常和延遲的。

正常故障轉移

此方法使用一種演算法計算CUCM確認先前的keep-alive所用的平均時間。

例如，如果CUCM響應過去10000 keep-alive所用的平均時間為X秒，則電話將等待X秒，然後才會檢測到CUCM故障。然後，它將嘗試註冊到備份CUCM。

延遲故障轉移

在此機制中，電話會等待3個保持連線間隔來檢測主CUCM的故障。

缺點

資料包傳輸時間波動的網路，延遲故障轉移有助於避免不必要的註銷。

傳輸時間波動示例（注意ping響應的時間延遲）：

64 bytes from 10.106.97.150: icmp_seq=1 ttl=63 time=0.100 ms

64 bytes from 10.106.97.150: icmp_seq=2 ttl=63 time=200 ms

64 bytes from 10.106.97.150: icmp_seq=3 ttl=63 time=0.180 ms

64 bytes from 10.106.97.150: icmp_seq=4 ttl=63 time=0.678 ms

64 bytes from 10.106.97.150: icmp_seq=5 ttl=63 time=590 ms

64 bytes from 10.106.97.150: icmp_seq=6 ttl=63 time=0.100 ms

64 bytes from 10.106.97.150: icmp_seq=7 ttl=63 time=345 ms

64 bytes from 10.106.97.150: icmp_seq=8 ttl=63 time=456 ms

64 bytes from 10.106.97.150: icmp_seq=9 ttl=63 time=0.345 ms

優勢

此機制可用於延遲敏感網路中。

SIP保持連線

根據CUCM中的設定，SIP電話註冊到CUCM並每120秒傳送一次保持連線。當電話向主CUCM傳送初始註冊時，會將Expires計時器設定為3600秒（在電話上應用的SIP配置檔案中預設設定）。CUCM根據服務引數中設定的值將計時器修改為120秒，從而傳送ACK。

因此，電話每120秒傳送一次keep-alive（實際為115秒，即120減去SIP配置檔案中配置的增量值，預設值為5秒）。 在這種情況下，電話每115秒傳送一次keep-alive。

SIP電話將Register消息交換到Expires欄位設定為0的備份CUCM。

至主要

REGISTER sip:10.106.114.161 SIP/2.0

Via: SIP/2.0/TCP 10.106.114.185:53006;branch=z9hG4bKd451a4fa

From: <sip:5678@10.106.114.161>;tag=0024142ddf242c6644b6e5d2-f01c795a

To: <sip:5678@10.106.114.161>

Call-ID: 0024142d-df24000a-44da4e09-0de51424@10.106.114.185

Max-Forwards: 70

Date: Wed, 15 Jul 2015 12:42:56 GMT

CSeq: 11435 REGISTER

User-Agent: Cisco-CP7975G/9.3.1

Contact: <sip:9e9e1ffb-0206-4ea1-6d77-ba04a72017f7@10.106.114.185:53006;transport=tcp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0024142ddf24>";+u.sip!devicename.ccm.cisco.com="SEP0024142DDF24";+u.sip!model.ccm.cisco.com="437"

Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-6.0.0,X-cisco-xsi-8.5.1

Content-Length: 0

Expires: 3600

SIP/2.0 100 Trying

Via: SIP/2.0/TCP 10.106.114.185:53006;branch=z9hG4bKd451a4fa

From: <sip:5678@10.106.114.161>;tag=0024142ddf242c6644b6e5d2-f01c795a

To: <sip:5678@10.106.114.161>

Date: Wed, 15 Jul 2015 12:42:59 GMT

Call-ID: 0024142d-df24000a-44da4e09-0de51424@10.106.114.185

CSeq: 11435 REGISTER

Content-Length: 0

SIP/2.0 200 OK

Via: SIP/2.0/TCP 10.106.114.185:53006;branch=z9hG4bKd451a4fa

From: <sip:5678@10.106.114.161>;tag=0024142ddf242c6644b6e5d2-f01c795a

To: <sip:5678@10.106.114.161>;tag=1708299782

Date: Wed, 15 Jul 2015 12:42:59 GMT

Call-ID: 0024142d-df24000a-44da4e09-0de51424@10.106.114.185

CSeq: 11435 REGISTER

Expires: 120

Contact: <sip:9e9e1ffb-0206-4ea1-6d77-ba04a72017f7@10.106.114.185:53006;transport=tcp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0024142ddf24>";+u.sip!devicename.ccm.cisco.com="SEP0024142DDF24";+u.sip!model.ccm.cisco.com="437"

Supported: X-cisco-srtp-fallback,X-cisco-sis-6.0.0

Content-Length: 0

至次要

REGISTER sip:10.60.1.12:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.60.63.21:3784;rport;branch=z9hG4bKPjdcJ819aZtTCtmvr0VBheV6p0uL8aC.pG

Max-Forwards: 70

From: <sip:6836@10.60.1.12>;tag=5oI-ew53.DGjTDu5LB9orkdDpZlccNbv

To: <sip:6836@10.60.1.12>

Call-ID: HxTK.m6BH9qxjstVwexTbhVnUxNeuxle

CSeq: 18800 REGISTER

Expires: 0

Contact: <sip:e2b0f175-feae-d664-befa-b7cd0837fcc6@10.60.63.21:5060;transport=TCP>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-e0d1730ac1b1>";+u.sip!devicename.ccm.cisco.com="SEPE0D1730AC1B1";+u.sip!model.ccm.cisco.com="592";expires=0;cisco-keep-alive

Content-Length:  0

需要日誌

要確定電話取消註冊的原因，請收集概述的資訊：

- Event Viewer Application and System Logs（事件檢視器應用程式和系統日誌） — 為電話註銷提供警報/錯誤代碼，並使用該代碼進行故障排除。

- 同時從電話和CUCM（主和備份）捕獲資料包 — 有助於從網路的角度隔離問題。

- Cisco Call Manager跟蹤。

相關連結

從CUCM收集資料包捕獲

從IP電話收集捕獲

收集CUCM跟蹤

分析日誌和資料包捕獲

- 事件檢視器應用程式日志將列印EndPointUnregistered消息以及相關的原因代碼。

Example: 31 uc-ucm-01 local7 3 : 41679: uc-ucm-01.pcce.local Jul 02 2015 06:22:31 UTC :   %UC_CALLMANAGER-3-EndPointUnregistered: %[DeviceName=SEPE0D1730A8137][IPAddress=10.60.98.210][Protocol=SIP][DeviceType=592][Description=Phone][Reason=13][IPAddrAttributes=0][LastSignalReceived=SIPStationDPrimaryLineTimeout][AppID=Cisco CallManager][ClusterID=StandAloneCluster][NodeID=uc-ucm-01]: An endpoint has unregistered

EndPointUnregistration的原因代碼可在系統錯誤消息文檔中找到。

讀取Wireshark日誌

收集兩端的Captures時，驗證電話傳送的keepalive是否實際到達CUCM。

TCP封包的序號有助於在監聽器擷取中輕鬆追蹤電話和CUCM之間的TCP流量。

從電話擷取

電話傳送序列號為2991996107的資料包，請驗證此資料包是否到達CUCM。

從CUCM捕獲

在電話監聽器捕獲中看到的序列號應在CUCM捕獲中看到。

案例研究1.2

問題描述

SCCP電話定期重新啟動。

疑難排解

事件檢視器應用程式日誌表明電話由於丟失keep alive（錯誤代碼為13）而一直重新啟動。

Event Viewer Message.

從IP電話和CUCM收集資料包捕獲。  在此案例中，從IP電話傳送的最後一個保持連線未到達CUCM。

Image.

由於以下原因，Keep-alive被丟棄：

當電話傳送ARP以獲取CUCM的MAC地址時，響應來自具有ASA mac-address的ARP代理。顯然，第一個回應不是來自CUCM。但是，由於電話首先收到該幀，因此它會將該幀連同另一台裝置的MAC地址傳送給交換機。

這通常在ASA上啟用ARP代理時發生。

解析

禁用ASA上的ARP代理以解決問題。

案例研究2.

問題描述

Cisco IP電話型號8961電話每16分鐘重置一次，然後註冊到輔助CUCM。2分鐘後，電話回到Primary CUCM，此週期繼續。

疑難排解

從電話和CUCM跟蹤收集資料包捕獲。取消註冊的原因是IP電話未收到SIP keep-alive。

分析

SIP電話註冊到CUCM，並根據CUCM中的設定每120秒傳送一次保持連線。

當電話傳送初始註冊時，它將到期計時器設定為3600秒（在電話上應用的SIP配置檔案中預設設定）。CUCM根據服務引數中設定的值將計時器修改為120秒，以確認這一點。

電話每120秒傳送一次Keepalive（keep-alive間隔為115秒，即120減去SIP配置檔案中配置的增量值，預設值為5秒）。 在這種情況下，電話每115秒傳送一次keepalive。

在此問題情境中，電話在115秒傳送第一個keepalive，但它在網路中被捨棄。這會導致電話在0.01秒（100毫秒）內重新傳輸keepalive。 它從CUCM獲取REGISTER請求的響應。

現在，電話在115秒傳送第二個keepalive資料包，然後該資料包在網路中丟棄。現在，電話將其REGISTER重試間隔增加到0.02秒（200毫秒）。

每當電話在115之後傳送keepalive資料包時，都會在網路中丟棄，從而導致電話重新傳輸資料包。此外，電話還會以指數級增加其重試間隔。在少數幾次keep-alive後，電話重試次數增加到14秒。

電話在14秒後重新傳輸，並從CUCM獲得ACK。

下次電話傳送keep-alive時，它將丟失，然後電話在28秒後重新傳輸REGISTER請求。CUCM不能等待28秒，它只等待15秒（在115秒之後），然後傳送取消註冊訊號。

保持連線時間和RTO總計可達16分鐘幾秒。

由於CUCM發出註銷訊號，16分鐘後，電話註冊到輔助CUCM，2分鐘後，電話註冊回主，繼續操作。

保持連線丟棄的原因

當交換機埠配置了埠安全時，埠老化配置了非活動計時器。計時器已設定為一分鐘，比SIP keep-alive計時器小。這導致交換機埠每分鐘刷新一次電話MAC。由於SIP keep-alive間隔是每2分鐘一次，因此資料包一直被丟棄。