簡介
本檔案介紹可用於對組態進行疑難排解的資訊。
除了網路層級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
[an error occurred while processing this directive]
優勢
此機制可用於延遲敏感網路中。
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
[an error occurred while processing this directive]
至次要
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
[an error occurred while processing this directive]
需要日誌
要確定電話取消註冊的原因,請收集概述的資訊:
- Event Viewer Application and System Logs(事件檢視器應用程式和系統日誌) — 為電話註銷提供警報/錯誤代碼,並使用該代碼進行故障排除。
- 同時從電話和CUCM(主和備份)捕獲資料包 — 有助於從網路的角度隔離問題。
相關連結
從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
[an error occurred while processing this directive]
EndPointUnregistration的原因代碼可在系統錯誤消息文檔中找到。
讀取Wireshark日誌
收集兩端的Captures時,驗證電話傳送的keepalive是否實際到達CUCM。
TCP封包的序號有助於在監聽器擷取中輕鬆追蹤電話和CUCM之間的TCP流量。
從電話擷取
電話傳送序列號為2991996107的資料包,請驗證此資料包是否到達CUCM。
從CUCM捕獲
在電話監聽器捕獲中看到的序列號應在CUCM捕獲中看到。
案例研究1.2
問題描述
SCCP電話定期重新啟動。
疑難排解
事件檢視器應用程式日誌表明電話由於丟失keep alive(錯誤代碼為13)而一直重新啟動。
Event Viewer Message.
[an error occurred while processing this directive]
從IP電話和CUCM收集資料包捕獲。 在此案例中,從IP電話傳送的最後一個保持連線未到達CUCM。
Image.
[an error occurred while processing this directive]
由於以下原因,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分鐘一次,因此資料包一直被丟棄。