Solved: KeepAlive issue between CUCM and 7925g's.

sean.demura · ‎07-12-2012

Relevant Cisco Equipment:

(3) Cisco Call Manager 6.1.3-10000-16 (Appliance)

(4) Cisco 7925g 1.4.3.4

3825 Call Routers

1242AG

1252

3500e

3500i

WSM 7.0.235.0

6500 MDF Switches

Nexus 7k cores

Hello,

We are currently experiencing some fairly interruptive drop outs with our Cisco 7925g phones. This issue started happening 2 months ago. At the time there were absolutely no changes to our network. The problem seemingly appeared out of nowhere.

The problem is, is that quite often the wireless phones will drop their registration from the Call Managers and re-register.

I have tracked it down to a KeepAlive issue between the call managers and the phones.

Packet Captures between wireless phone and call manager. These results are the same regardless of registered CM or 7925g phone.

Time Source Destination Protocol Length Info

1326 03:43:16.214298 10.111.114.139 10.111.115.22 SKINNY 78 KeepAliveMessage

1327 03:43:16.214382 10.111.115.22 10.111.114.139 SKINNY 78 KeepAliveAckMessage

1328 03:43:22.498677 10.111.114.139 10.111.115.22 TCP 66 ibm-cics > cisco-sccp [ACK] Seq=1765 Ack=2649 Win=9504 Len=0 TSval=22329960 TSecr=1112450

1329 03:43:47.482195 10.111.114.139 10.111.115.22 SKINNY 78 KeepAliveMessage

1330 03:43:47.482269 10.111.115.22 10.111.114.139 SKINNY 78 KeepAliveAckMessage

1331 03:43:53.837325 10.111.114.139 10.111.115.22 TCP 66 ibm-cics > cisco-sccp [ACK] Seq=1777 Ack=2661 Win=9504 Len=0 TSval=22333093 TSecr=1115576

1332 03:44:18.871530 10.111.114.139 10.111.115.22 SKINNY 78 KeepAliveMessage

1333 03:44:18.871603 10.111.115.22 10.111.114.139 SKINNY 78 KeepAliveAckMessage

1334 03:44:30.392933 10.111.115.22 10.111.114.139 SKINNY 78 [TCP Retransmission] KeepAliveAckMessage

1335 03:44:31.264809 10.111.114.139 10.111.115.22 SKINNY 78 [TCP Retransmission] KeepAliveMessage

1336 03:44:31.264830 10.111.115.22 10.111.114.139 TCP 78 [TCP Dup ACK 1334#1] cisco-sccp > ibm-cics [ACK] Seq=2673 Ack=1789 Win=7504 Len=0 TSval=1119955 TSecr=22336836 SLE=1777 SRE=1789

1337 03:44:31.280092 10.111.114.139 10.111.115.22 TCP 66 ibm-cics > cisco-sccp [ACK] Seq=1789 Ack=2673 Win=9504 Len=0 TSval=22336838 TSecr=1118715

1338 03:44:31.281835 10.111.114.139 10.111.115.22 TCP 78 [TCP Dup ACK 1337#1] ibm-cics > cisco-sccp [ACK] Seq=1789 Ack=2673 Win=9504 Len=0 TSval=22336838 TSecr=1119868 SLE=2661 SRE=2673

1339 03:44:48.140267 10.111.114.139 10.111.115.22 SKINNY 78 KeepAliveMessage

1340 03:44:48.140294 10.111.115.22 10.111.114.139 TCP 66 cisco-sccp > ibm-cics [ACK] Seq=2673 Ack=1801 Win=7504 Len=0 TSval=1121642 TSecr=22338523

1341 03:44:48.140365 10.111.115.22 10.111.114.139 SKINNY 78 KeepAliveAckMessage

1342 03:45:06.951765 10.111.114.139 10.111.115.22 TCP 66 ibm-cics > cisco-sccp [ACK] Seq=1801 Ack=2685 Win=9504 Len=0 TSval=22340405 TSecr=1121642

1343 03:45:19.468323 10.111.114.139 10.111.115.22 SKINNY 78 KeepAliveMessage

1344 03:45:19.468379 10.111.115.22 10.111.114.139 SKINNY 78 KeepAliveAckMessage

1345 03:45:50.453591 10.111.115.22 10.111.114.139 SKINNY 78 [TCP Retransmission] KeepAliveAckMessage

1346 03:46:20.484995 10.111.115.22 10.111.114.139 TCP 66 cisco-sccp > ibm-cics [FIN, ACK] Seq=2697 Ack=1813 Win=7504 Len=0 TSval=1130877 TSecr=22341656

1347 03:46:47.174688 10.111.114.139 10.111.115.22 SKINNY 90 KeepAliveMessage KeepAliveMessage

1348 03:46:47.174711 10.111.115.22 10.111.114.139 TCP 54 cisco-sccp > ibm-cics [RST] Seq=2685 Win=0 Len=0

1349 03:46:51.383429 10.111.114.139 10.111.115.22 TCP 74 eicon-server > cisco-sccp [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=22350849 TSecr=0 WS=1

1350 03:46:51.383458 10.111.115.22 10.111.114.139 TCP 74 cisco-sccp > eicon-server [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSval=1133966 TSecr=22350849 WS=1

1351 03:46:51.390157 10.111.114.139 10.111.115.22 TCP 66 eicon-server > cisco-sccp [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSval=22350850 TSecr=1133966

1352 03:46:51.840486 10.111.114.139 10.111.115.22 SKINNY 110 RegisterTokenReq

No. Time Source Destination Protocol Length Info

3825 08:28:33.154988 10.111.114.139 10.111.115.22 SKINNY 78 KeepAliveMessage

3826 08:28:33.155064 10.111.115.22 10.111.114.139 SKINNY 78 KeepAliveAckMessage

3827 08:28:41.626195 10.111.114.139 10.111.115.22 TCP 66 esl-lm > cisco-sccp [ACK] Seq=1757 Ack=2661 Win=9504 Len=0 TSval=24041955 TSecr=2824130

3828 08:29:34.173199 10.111.115.22 10.111.114.139 TCP 66 cisco-sccp > esl-lm [FIN, ACK] Seq=2661 Ack=1757 Win=7504 Len=0 TSval=2830232 TSecr=24041955

3829 08:29:50.583203 10.111.115.22 10.111.114.139 TCP 66 cisco-sccp > esl-lm [FIN, ACK] Seq=2661 Ack=1757 Win=7504 Len=0 TSval=2831873 TSecr=24041955

3830 08:30:21.876130 10.111.114.139 10.111.115.22 SKINNY 90 [TCP Previous segment not captured] KeepAliveMessage KeepAliveMessage

3831 08:30:21.876157 10.111.115.22 10.111.114.139 TCP 54 cisco-sccp > esl-lm [RST] Seq=2661 Win=0 Len=0

3832 08:30:23.353968 10.111.114.139 10.111.115.22 TCP 74 nrcabq-lm > cisco-sccp [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=24052128 TSecr=0 WS=1

3833 08:30:23.353993 10.111.115.22 10.111.114.139 TCP 74 cisco-sccp > nrcabq-lm [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSval=2835150 TSecr=24052128 WS=1

3834 08:30:23.360529 10.111.114.139 10.111.115.22 TCP 66 nrcabq-lm > cisco-sccp [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSval=24052128 TSecr=2835150

3835 08:32:24.078317 10.111.114.139 10.111.115.22 SKINNY 110 RegisterTokenReq

3836 08:32:24.078340 10.111.115.22 10.111.114.139 TCP 66 cisco-sccp > nrcabq-lm [ACK] Seq=1 Ack=45 Win=5792 Len=0 TSval=2847222 TSecr=24064200

3837 08:32:24.078465 10.111.115.22 10.111.114.139 SKINNY 78 RegisterTokenAck

3838 08:32:24.099484 10.111.114.139 10.111.115.22 TCP 66 nrcabq-lm > cisco-sccp [ACK] Seq=45 Ack=13 Win=5840 Len=0 TSval=24064203 TSecr=2847222

3839 08:32:24.571792 10.111.114.139 10.111.115.22 SKINNY 170 AlarmMessage

3840 08:32:24.604454 10.111.115.22 10.111.114.139 TCP 66 cisco-sccp > nrcabq-lm [ACK] Seq=13 Ack=149 Win=5792 Len=0 TSval=2847275 TSecr=24064250

3841 08:32:24.674400 10.111.114.139 10.111.115.22 SKINNY 142 RegisterMessage

From one of our Call Routers

Log Buffer (4096 bytes):

IP:10.111.114.136 Socket:1 DeviceType:Phone has unregistered normally.

Jul 12 08:11:58.065: %IPPHONE-6-REG_ALARM: Name=SEP588D09D3583B Load=CP7925G-1.4.3.4 Last=TCP-timeout

Jul 12 08:11:58.065: %IPPHONE-6-REGISTER_NEW: ephone-2:SEP588D09D3583B IP:10.111.114.136 Socket:1 DeviceType:Phone has registered.

Jul 12 08:11:58.065: %IPPHONE-6-REG_ALARM: Name=SEP588D09D3583B Load=CP7925G-1.4.3.4 Last=TCP-timeout

Jul 12 08:13:28.739: %IPPHONE-6-UNREGISTER_ABNORMAL: ephone-2:SEP588D09D3583B IP:10.111.114.136 Socket:1 DeviceType:Phone has unregistered abnormally.

Jul 12 08:15:32.733: %IPPHONE-6-REG_ALARM: Name=SEP588D09D334FB Load=CP7925G-1.4.3.4 Last=TCP-timeout

Jul 12 08:15:32.733: %IPPHONE-6-REGISTER_NEW: ephone-1:SEP588D09D334FB IP:10.111.114.139 Socket:2 DeviceType:Phone has registered.

Jul 12 08:15:32.733: %IPPHONE-6-REG_ALARM: Name=SEP588D09D334FB Load=CP7925G-1.4.3.4 Last=TCP-timeout

Jul 12 08:17:02.743: %IPPHONE-6-UNREGISTER_ABNORMAL: ephone-1:SEP588D09D334FB IP:10.111.114.139 Socket:2 DeviceType:Phone has unregistered abnormally.

Jul 12 08:43:12.367: %IPPHONE-6-REG_ALARM: Name=SEP588D09D3583B Load=CP7925G-1.4.3.4 Last=CM-aborted-TCP

Jul 12 08:43:12.567: %IPPHONE-6-REGISTER_NEW: ephone-2:SEP588D09D3583B IP:10.111.114.136 Socket:3 DeviceType:Phone has registered.

Jul 12 08:45:14.509: %IPPHONE-6-UNREGISTER_NORMAL: ephone-2:SEP588D09D3583B IP:10.111.114.136 Socket:3 DeviceType:Phone has unregistered normally.

Jul 12 08:47:47.824: %IPPHONE-6-REG_ALARM: Name=SEP588D09D334FB Load=CP7925G-1.4.3.4 Last=TCP-timeout

Jul 12 08:47:47.824: %IPPHONE-6-REGISTER_NEW: ephone-1:SEP588D09D334FB IP:10.111.114.139 Socket:1 DeviceType:Phone has registered.

Jul 12 08:49:18.777: %IPPHONE-6-UNREGISTER_ABNORMAL: ephone-1:SEP588D09D334FB IP:10.111.114.139 Socket:1 DeviceType:Phone has unregistered abnormally.

Jul 12 09:09:36.375: %IPPHONE-6-REG_ALARM: Name=SEP588D09D334FB Load=CP7925G-1.4.3.4 Last=TCP-timeout

Jul 12 09:09:36.375: %IPPHONE-6-REGISTER_NEW: ephone-1:SEP588D09D334FB IP:10.111.114.139 Socket:3 DeviceType:Phone has registered.

Jul 12 09:11:06.801: %IPPHONE-6-UNREGISTER_ABNORMAL: ephone-1:SEP588D09D334FB IP:10.111.114.139 Socket:3 DeviceType:Phone has unregistered abnormally.

Jul 12 09:41:16.673: %IPPHONE-6-REG_ALARM: Name=SEP588D09D334FB Load=CP7925G-1.4.3.4 Last=TCP-timeout

Jul 12 09:41:16.873: %IPPHONE-6-REGISTER_NEW: ephone-1:SEP588D09D334FB IP:10.111.114.139 Socket:1 DeviceType:Phone has registered.

Jul 12 09:41:57.606: %IPPHONE-6-REG_ALARM: Name=SEP588D09D3583B Load=CP7925G-1.4.3.4 Last=TCP-timeout

Jul 12 09:41:57.810: %IPPHONE-6-REGISTER_NEW: ephone-2:SEP588D09D3583B IP:10.111.114.136 Socket:4 DeviceType:Phone has registered.

Jul 12 09:43:18.992: %IPPHONE-6-UNREGISTER_NORMAL: ephone-1:SEP588D09D334FB IP:10.111.114.139 Socket:1 DeviceType:Phone has unregistered normally.

Jul 12 09:44:01.448: %IPPHONE-6-UNREGISTER_NORMAL: ephone-2:SEP588D09D3583B IP:10.111.114.136 Socket:4 DeviceType:Phone has unregistered normally.

Jul 12 10:12:30.079: %IPPHONE-6-REG_ALARM: Name=SEP588D09D334FB Load=CP7925G-1.4.3.4 Last=TCP-timeout

Jul 12 10:12:30.079: %IPPHONE-6-REGISTER_NEW: ephone-1:SEP588D09D334FB IP:10.111.114.139 Socket:1 DeviceType:Phone has registered.

Jul 12 10:14:45.258: %IPPHONE-6-UNREGISTER_NORMAL: ephone-1:SEP588D09D334FB IP:10.111.114.139 Socket:1 DeviceType:Phone has unregistered normally.

Jul 12 10:44:00.593: %IPPHONE-6-REG_ALARM: Name=SEP588D09D334FB Load=CP7925G-1.4.3.4 Last=TCP-timeout

Jul 12 10:44:00.593: %IPPHONE-6-REGISTER_NEW: ephone-1:SEP588D09D334FB IP:10.111.114.139 Socket:1 DeviceType:Phone has registered.

Jul 12 10:44:53.302: %IPPHONE-6-REG_ALARM: Name=SEP588D09D3583B Load=CP7925G-1.4.3.4 Last=CM-aborted-TCP

Jul 12 10:44:53.506: %IPPHONE-6-REGISTER_NEW: ephone-2:SEP588D09D3583B IP:10.111.114.136 Socket:3 DeviceType:Phone has registered.

Jul 12 10:46:15.755: %IPPHONE-6-UNREGISTER_NORMAL: ephone-1:SEP588D09D334FB IP:10.111.114.139 Socket:1 DeviceType:Phone has unregistered normally.

Jul 12 10:46:56.044: %IPPHONE-6-UNREGISTER_NORMAL: ephone-2:SEP588D09D3583B IP:10.111.114.136 Socket:3 DeviceType:Phone has unregistered normally.

From RTMT

Jul 12 10:38:32 GTLIN22CCM Error Cisco CallManager : 4907: Jul 12 14:38:32.740 UTC : %CCM_CALLMANAGER-CALLMANAGER-3-DeviceUnregistered: Device unregistered. Device name.:SEP588D09D353EE Device IP address.:10.111.114.145 Protocol.:SCCP Device type. [Optional]:484 Device description [Optional].:GTC-MIS-Wireless-5404-IP1212 Reason Code [Optional].:13 Device MAC address [Optional].:588D09D353EE Cluster ID:StandAloneCluster Node ID:GTLIN22CCM

Jul 12 10:42:54 GTLIN22CCM Error Cisco CallManager : 4940: Jul 12 14:42:54.102 UTC : %CCM_CALLMANAGER-CALLMANAGER-3-DeviceUnregistered: Device unregistered. Device name.:SEP588D09D334FB Device IP address.:10.111.114.139 Protocol.:SCCP Device type. [Optional]:484 Device description [Optional].:GTC-MIS-Wireless-5404-IP1215 Reason Code [Optional].:13 Device MAC address [Optional].:588D09D334FB Cluster ID:StandAloneCluster Node ID:GTLIN22CCM

Jul 12 10:44:15 GTLIN22CCM Error Cisco CallManager : 4951: Jul 12 14:44:15.433 UTC : %CCM_CALLMANAGER-CALLMANAGER-3-DeviceUnregistered: Device unregistered. Device name.:SEP588D09D3583B Device IP address.:10.111.114.136 Protocol.:SCCP Device type. [Optional]:484 Device description [Optional].:GTC-MIS-Wireless-5404-new Reason Code [Optional].:13 Device MAC address [Optional].:588D09D3583B Cluster ID:StandAloneCluster Node ID:GTLIN22CCM

From an affected phone:

2012-07-12 09:10:51:0470 CP-7925G user.info modprobe: insmod -s -k eth0

2012-07-12 09:10:54:0460 CP-7925G user.err SCCP: Skinny_get_tftpIp: Could NOT getGNetutilVarVal!

2012-07-12 09:10:54:0460 CP-7925G user.err SCCP: Skinny_get_alt_tftpIp: Could NOT getGNetutilVarVal!

2012-07-12 09:10:59:0450 CP-7925G user.err java: KNI native open0 BEGINS

2012-07-12 09:10:59:0460 CP-7925G user.err java: Calling pcsl_serversocket_open with port as 13322

2012-07-12 09:10:59:0470 CP-7925G user.err java: Calling pcsl_serversocket_open retuned

2012-07-12 09:10:59:0570 CP-7925G user.err java: jwcNativeApi():notifyMidletStateChange():System Application Suite not found!!

2012-07-12 09:10:59:0570 CP-7925G user.err java: NtvMdltMgr_GetNtvMdlt(-1): Invalid mdlt ref

2012-07-12 09:10:59:0570 CP-7925G user.err java: NtvMdlt_Active(-1):Invalid Midlet reference

2012-07-12 09:41:55:0370 CP-7925G user.err SCCP: pri-tcp timeout<-47>

2012-07-12 09:41:55:0540 CP-7925G user.err netd: SCCP Requested a network status check

2012-07-12 09:41:56:0050 CP-7925G user.info modprobe: insmod -s -k eth0

2012-07-12 09:44:01:0380 CP-7925G user.err SCCP: Skinny_get_IPconnect: Could NOT getGNetutilVarVal!

2012-07-12 09:44:01:0380 CP-7925G user.err SCCP: fallback to CCM<ac:4 sb:-1 re:0>

2012-07-12 09:44:01:0530 CP-7925G user.err netd: SCCP Requested a network status check

2012-07-12 09:44:01:0780 CP-7925G user.info modprobe: insmod -s -k eth0

2012-07-12 09:44:04:0040 CP-7925G user.err SCCP: Skinny_get_tftpIp: Could NOT getGNetutilVarVal!

2012-07-12 09:44:04:0040 CP-7925G user.err SCCP: Skinny_get_alt_tftpIp: Could NOT getGNetutilVarVal!

2012-07-12 10:13:28:0510 CP-7925G user.err SCCP: pri-tcp timeout<-47>

2012-07-12 10:13:28:0570 CP-7925G user.err netd: SCCP Requested a network status check

2012-07-12 10:13:28:0810 CP-7925G user.info modprobe: insmod -s -k eth0

2012-07-12 10:13:59:0000 CP-7925G user.err SCCP: pri-tcp timeout<-47>

2012-07-12 10:13:59:0060 CP-7925G user.err netd: SCCP Requested a network status check

2012-07-12 10:13:59:0490 CP-7925G user.info modprobe: insmod -s -k eth0

2012-07-12 10:14:01:0940 CP-7925G user.err SCCP: Skinny_get_tftpIp: Could NOT getGNetutilVarVal!

2012-07-12 10:14:01:0940 CP-7925G user.err SCCP: Skinny_get_alt_tftpIp: Could NOT getGNetutilVarVal!

2012-07-12 10:44:52:0970 CP-7925G user.err SCCP: no data[0]<0:8:0>

2012-07-12 10:44:52:0980 CP-7925G user.err SCCP: no data[0]<0:8:0>

2012-07-12 10:44:52:0990 CP-7925G user.err SCCP: no data[0]<0:8:0>

2012-07-12 10:44:53:0040 CP-7925G user.err netd: SCCP Requested a network status check

2012-07-12 10:44:53:0280 CP-7925G user.info modprobe: insmod -s -k eth0

2012-07-12 10:46:56:0120 CP-7925G user.err SCCP: Skinny_get_IPconnect: Could NOT getGNetutilVarVal!

2012-07-12 10:46:56:0120 CP-7925G user.err SCCP: fallback to CCM<ac:4 sb:-1 re:0>

2012-07-12 10:46:56:0230 CP-7925G user.err netd: SCCP Requested a network status check

2012-07-12 10:46:56:0510 CP-7925G user.info modprobe: insmod -s -k eth0

2012-07-12 10:46:58:0760 CP-7925G user.err SCCP: Skinny_get_tftpIp: Could NOT getGNetutilVarVal!

2012-07-12 10:46:58:0760 CP-7925G user.err SCCP: Skinny_get_alt_tftpIp: Could NOT getGNetutilVarVal!

2012-07-12 11:10:09:0220 CP-7925G user.err SCCP: no data[0]<0:8:0>

2012-07-12 11:10:09:0230 CP-7925G user.err SCCP: no data[0]<0:8:0>

2012-07-12 11:10:09:0340 CP-7925G user.err netd: SCCP Requested a network status check

2012-07-12 11:10:09:0600 CP-7925G user.info modprobe: insmod -s -k eth0

2012-07-12 11:10:40:0090 CP-7925G user.err SCCP: pri-tcp timeout<-47>

2012-07-12 11:10:40:0160 CP-7925G user.err netd: SCCP Requested a network status check

2012-07-12 11:10:40:0540 CP-7925G user.info modprobe: insmod -s -k eth0

2012-07-12 11:10:42:0790 CP-7925G user.err SCCP: Skinny_get_tftpIp: Could NOT getGNetutilVarVal!

2012-07-12 11:10:42:0800 CP-7925G user.err SCCP: Skinny_get_alt_tftpIp: Could NOT getGNetutilVarVal!

We currently have 3 Call Managers (1 Publisher, 2 Subscribers), which manage about 1500 phones, most of which are 7962’s. The only wireless phones are the 7925g’s. The issue described above happens at random intervals, and happens on all of our wireless phones. The issue is becoming quite troublesome as our Helpdesk are missing calls left and right.

When the phones are in use, calls are not dropped and roaming while talking works fine. It seems to all boil down to the Call Managers not responding to KeepAlive Ack’s in an appropriate manner. In some cases the packet captures show a RTT for KeepAliveAck’s upwards of 60 seconds!

Regardless of Wireless Controller/AP setup (a-only, b/g only, a/b/g auto) does not have any effect on our issue. Wireless coverage is good. Wireless settings were configured according the 7925g Deployment Guide. The issue is prevalent even in an office where the AP is at most 10 feet from any wireless phone. Cisco WCS reports a ‘invalid qos parameter (203)’ error on the monitoring pages, but I’ve been assured by the lead network engineer that this error has been in WCS for a long time.

I have messed with changing out the preferred Call Managers from one to the other, created separate device pools - all of which are no help.

From what I have read online, I don’t understand why we are having the KeepAlive issue with the phones. The wireless links are far from saturated, and the wireless phones associate with their own SSID. Because of the lack of saturation, QoS wouldn’t be/shouldn’t be an issue.

Also, Following CSCsx97591, I set the Disable NonRegistered SCCP KeepAlives to False (previously set to true), does not help any, and if anything the problem seems to be exacerbated by it.

I would also like to point that SRST is working and configured properly. I had put one phone on a separate device pool that only talked to one call manager. When the issue happens on that phone, it will failover into SRST mode and register with one of our call routers. After a period of time it falls back over to the call manager. From what I understand the phones configured with multiple call managers should then be bouncing back and forth between which call manager the phone registers with, but it doesn’t. If it loses its registration and reregisters, it reregisters with the same call manager it fell off with.

To summarize all of this, I can see there is a KeepAlive/TCP Ack timeout issue that is causing our 7925g phones to unregister at random intervals. No network changes were made when the problem started. Only wireless phones are affected; desk phones work perfectly. Wireless coverage is good across our property.

Any help would be greatly appreciated.

sean.demura · ‎08-01-2012

Ended up finding out the issue had to with WPA2 session timeouts.

For whatever reason we had the timeouts configured for 30 minutes, which means every 30 minutes the phones are forced to re-auth with the AP. This process was taking long enough that the KeepAlive handshake between the phones and the call managers would fail, resulting in an abnormal unregister.

I've since bumped the value up to 12 hours and magically, the phones don't drop.

Now I get to battle some QoS and/or WiFi interference issues. yay!

View solution in original post

testeven · ‎07-12-2012

Hi Sean,

Just as a test, if you have already increased the keep-alive timers can you configure the setting in the phone itself called 'Call Power Safe Mode' set to none. Also have you tried rebooting your APs and see if the problem clears?

Regards,

Tere.

If you find this post helpful, please rate!

Regards, Tere. If you find this post helpful, please rate! :)

sean.demura · ‎07-14-2012

Tere,

The Call Power Safe mode option doesn't make a difference whether it's enabled or not, Since the problem has started we've upgraded the firmware on both our WCS and our access points to no avail.

-Sean

nstrech · ‎07-23-2012

Sean,

Did you ever find a solution? We're seeing the exact same keep alive issue with our new 7925 phone, we almost match your equipment list exactly. It's a very random issue but a handful of phones will reregister with CUCM every 5-10 min.

Nate

sean.demura · ‎07-23-2012

Nate,

The issue is still present. I have to TACs open with Cisco at the moment, one for wireless and one for call manager... the problem I'm having at the moment is that each side is blaming the other.

Hopefully we can get this figured out!

sean.demura · ‎08-01-2012

Ended up finding out the issue had to with WPA2 session timeouts.

For whatever reason we had the timeouts configured for 30 minutes, which means every 30 minutes the phones are forced to re-auth with the AP. This process was taking long enough that the KeepAlive handshake between the phones and the call managers would fail, resulting in an abnormal unregister.

I've since bumped the value up to 12 hours and magically, the phones don't drop.

Now I get to battle some QoS and/or WiFi interference issues. yay!

wireless wlc · ‎10-11-2012

Hi Sean,

Where did you change the wpa2 session timeout ? on the phone ? I dont know of such an option in the WLC. Please let me know.

regards

Joe

Pavel Rostovcev · ‎03-18-2015

Hello. You can see here http://mrncciew.com/2013/05/05/wlc-config-for-vowlan/

sirivincent · ‎10-16-2012

Hi Sean,

I have got the same issue on 7925G (upgrade on the last bin 1.4.3SR1.2.LOADS)

Please can you send us the process to change the WPA2 seesion timeout on WLC?

Thanks,

Vincent