排除IP电话注销故障 — 案例研究

下载选项

PDF (1.2 MB)
在各种设备上使用 Adobe Reader 查看
ePub (667.9 KB)
在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上使用各种应用查看
Mobi (Kindle) (718.0 KB)
在 Kindle 设备上查看或在多个设备上使用 Kindle 应用查看

已更新: 2016 年 2 月 10 日

文档 ID:200410

非歧视性语言

此产品的文档集力求使用非歧视性语言。在本文档集中，非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言，文档中可能无法确保完全使用非歧视性语言。深入了解思科如何使用包容性语言。

关于此翻译

思科采用人工翻译与机器翻译相结合的方式将此文档翻译成不同语言，希望全球的用户都能通过各自的语言得到支持性的内容。请注意：即使是最好的机器翻译，其准确度也不及专业翻译人员的水平。 Cisco Systems, Inc. 对于翻译的准确性不承担任何责任，并建议您总是参考英文原始文档（已提供链接）。

简介

本文档介绍可用于排除配置故障的信息。

除网络级TCP保活机制外，Cisco IP电话还使用应用级保活机制。瘦呼叫控制协议(SCCP)和会话发起协议(SIP)设备的保持连接机制可确保设备在呼叫控制中保持注册。它们还用于通过呼叫控制重新建立设备连接。

先决条件

要求

本文档没有任何特定的要求。

使用的组件

本文档不限于特定的软件和硬件版本。

SCCP保持连接和故障切换机制

SCCP使用TCP协议进行传输，并使用端口2000和2443（用于安全）连接到Call Manager。SCCP电话在注册到Cisco Unified Communications Manager(CUCM)之前应与其建立TCP连接。随后，在端口2000上将发生TCP三次握手，以建立通信信道。电话通过向CUCM发送SYN（同步）来发起此连接，CUCM使用SYN、ACK（确认）做出响应。电话依次以ACK响应，TCP连接建立。

保活

有两种保持连接方法：应用级(SKINNY keep-alive)和网络级(TCP keep-alive)

故障转移

在理想情况下，SCCP电话会保持与主CUCM和第一个备份CUCM建立的TCP连接。SCCP电话将保持连接发送到它已建立TCP连接的所有CUCM。然后，主服务器响应SCCP保持连接。时间间隔是30秒到主服务器，60秒到备份服务器。

主CUCM以SCCP保持连接ACK（确认SCCP和TCP连接）作出回应。备份CUCM只向电话发送的keep-alive发送TCP ACK。当电话因呼叫管理器服务不可用或主CUCM的TCP连接本身不可用而无法备份CUCM时，它使用两种机制来检测主CM故障，它们是正常和延迟的。

正常故障切换

此方法使用一种算法来计算CUCM确认之前保持连接所花费的平均时间。

例如，如果CUCM对过去10000个保持连接所花费的平均时间是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保持连接

SIP电话注册到CUCM，并根据CUCM中的设置每120秒发送一次保持连接。当电话将初始寄存器发送到主CUCM时，它将Expires 计时器设置为3600秒（在电话上应用的SIP配置文件中默认设置）。CUCM通过根据Service参数中设置的值将计时器修改为120秒来发送ACK。

因此，电话每120秒发送一次保持连接（实际上是115秒，即120减去SIP配置文件中配置的增量值，默认为5秒）。在这种情况下，电话每115秒发送一次保持连接。

SIP电话将注册消息交换到备份CUCM，Expires 字段设置为0。

到主

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]

所需日志

要确定电话未注册的原因，请收集概述的信息：

事件查看器应用和系统日志 — 为电话取消注册提供警报/错误代码，并使用这些代码我们可以继续进行故障排除。

同时从电话和CUCM（主要和备份）捕获数据包 — 有助于隔离问题网络视角。

Cisco Call Manager跟踪。

从电话捕获

电话发送序列号为2991996107的数据包，验证此数据包是否到达CUCM。

从CUCM捕获

在CUCM捕获中应看到电话嗅探器捕获中显示的序列号。

案例研究1.2

问题说明

SCCP电话会按固定间隔继续重新启动。

故障排除

事件查看器应用程序日志指示由于缺少保持活动，电话继续重新启动，错误代码为13。

Event Viewer Message.

[an error occurred while processing this directive]

从IP电话和CUCM收集数据包捕获。在此场景中，从IP电话发送的最后一个保持连接未到达CUCM。

Image.

[an error occurred while processing this directive]

由于以下原因，“保活”被丢弃：

当电话发送ARP来获取CUCM的MAC地址时，响应来自具有ASA mac-address的ARP代理。显然，第一个响应并非来自CUCM。但是，由于电话首先收到帧，因此它使用另一台设备的MAC地址将帧发送到交换机。

当ASA上启用ARP代理时，通常会发生这种情况。

分辨率

在ASA上禁用ARP代理以解决问题。

案例研究2.

问题说明

Cisco IP电话型号8961电话每16分钟重置一次，并注册到辅助CUCM。2分钟后，电话将回退到主CUCM，此循环继续。

故障排除

从电话收集数据包捕获和CUCM跟踪。取消注册是因为IP电话丢失了SIP保持连接。

分析

SIP电话注册到CUCM，并且根据CUCM中的设置每120秒发送一次保持连接。

当电话发送初始注册时，它会将过期计时器设置为3600秒（在电话上应用的SIP配置文件中默认设置）。CUCM通过根据Service参数中设置的值将计时器修改为120秒来确认。

电话每120秒发送一次保持连接(保持连接间隔为115秒，即120减去SIP配置文件中配置的增量值（默认为5秒）。在这种情况下，电话每115秒发送一次keepalive。

在此问题场景中，电话以115秒的速度发送第一个keepalive，并在网络中丢弃。这会导致电话在0.01秒（100毫秒）内重新传输keepalive。它从CUCM获得对REGISTER请求的响应。

现在，电话以115秒的速度发送第二个keepalive，并在网络中丢弃。现在，电话将其REGISTER重试间隔增加到0.02秒（200毫秒）。

每次电话在115后发送keepalive数据包时，它都会被丢弃到网络中，这会使电话重新传输数据包。此外，电话的重试间隔也呈指数级增加。在几次此类保持连接后，电话重试次数将增加到14秒。

电话在14秒后重新传输，并从CUCM获得ACK。

下次电话发送保持连接时，它会丢失，然后电话在28秒后重新传输REGISTER请求。CUCM无法等待28秒，只等待15秒（在115秒后），然后发送注销信号。

保持连接时间和RTO总和为16分钟几秒。

由于来自CUCM的注销信号，16分钟后，电话注册到辅助CUCM，2分钟后，电话重新注册到主CUCM，然后继续。

保活丢弃的原因

当交换机端口配置了端口安全时，端口老化已配置了非活动计时器。计时器设置为比SIP保活计时器小一分钟。这导致交换机端口每一分钟刷新一次电话MAC。由于SIP保持连接间隔为每2分钟一次，因此数据包会不断被丢弃。

由思科工程师提供

Ramkumar Shanmugam
思科TAC工程师

此文档是否有帮助?

反馈

联系我们

提交支持案例
(需要思科服务合同)

排除IP电话注销故障 — 案例研究

下载选项

非歧视性语言

关于此翻译

目录

简介

先决条件

要求

使用的组件

SCCP保持连接和故障切换机制

保活

故障转移

正常故障切换

延迟故障切换

缺点

优势

SIP保持连接

到主

到辅助

所需日志

相关链接

从电话捕获

从CUCM捕获

案例研究1.2

问题说明

故障排除

分辨率

案例研究2.

问题说明

故障排除

分析

保活丢弃的原因

由思科工程师提供

此文档是否有帮助?

联系我们

本文档适用于以下产品