Re: [cisco-voip] Voice-mail Failover CUC is not working
Hi mate, I remember something about this, I thought it was waiting for a fix in Jabber client, but can’t seem to find anything. Have you tried a profile to test the 2nd server as the primary mail store? i.e. just confirm it is actually working in non-failover. I like how bug was marked as 6, product enhancement. Cheers, Tim. From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Andrew Grech Sent: Thursday, 5 June 2014 5:03 PM To: Cisco VoIP Group Subject: [cisco-voip] Voice-mail Failover CUC is not working Hi All, I have just finished installing a subscriber Unity 10.x server. Then I changed my ports to distribute Incoming and outgoing calls. I tested a fail over and it worked fine, apart from the fact Jabber was unable to connect to the voice-mail sever. I then checked my presence template and added the new server. Like this post https://supportforums.cisco.com/discussion/11843221/failover-cuc-not-working#comment-9745211 Does anyone know if this bug is still valid for CUCM\Presence 10 \ Unity 10 jabber 10? Is there anything else I should be doing to finish off the cluster setup? Thanks Andrew ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
[cisco-voip] Intermittent phone resets
Hi, troubleshooting an issue where phones intermittently reset, either on hook or off hook (drops the call in progress). Logs and TAC claim it's a network issue, but has anyone seen similar problems on Call Manager 9.1? Basically, we want to rule out Call Manager as the culprit. Majority of phones using SIP, models 8891 and 9951, experiencing issues similar to those outlined here: https://supportforums.cisco.com/discussion/1084/ip-phones-randomly-rebooting Steps already taken: - upgrade to latest firmware - verify no POE errors on switch - cpu, memory on UCS servers ok - point phones to backup SUB, no change. Phones randomly reset when homed to Pub or Sub (both in separate locations). - Wireshark to see KeepAlives dropping 1.Phone logs show: SEP0DD3B4E9.cnf.xml.sgn (HTTP) 8:05:20p TCP connection timed out 8:07:22p Falling back to different CUCM 11:16:50p TCP connection timed out 11:18:51p Falling back to different CUCM 6:52:38p TCP connection timed out 6:54:39p Falling back to different CUCM 9:55:04a TCP connection timed out 9:57:05a Falling back to different CUCM 2.Call Manager logs show: - phone unregisters from Primary CUCM due to: [Reason=6] ConnectivityError - Network communication between the device and Unified CM has been interrupted. - phones fallback to secondary CUCM and then rehome to Primary CUCM: Reason code = 28, FallbackInitiated - The device has initiated a fallback and will automatically re-register to a higher-priority Unified CM. No action is necessary. 3. Call Manager syslogs display EndPointUnregistered: Apr 01 14:34:18 %UC_CALLMANAGER-3-EndPointUnregistered: %[DeviceName=SEP0DD3B4E9][IPAddress=10.1.10.211][Protocol=SIP][DeviceType=540][Description=User][Reason=6][IPAddrAttributes=0][LastSignalReceived=SIPConnControlInd][CallState=5286-call_initiated1][AppID=Cisco CallManager][ClusterID=NAregion][NodeID=CCMSub]: An endpoint has unregistered Apr 01 14:36:22 %UC_-3-LastOutOfServiceInformation: %[DeviceName=SEP0DD3B4E9][DeviceIPv4Address=10.1.10.211/24][IPv4DefaultGateway=192.168.51.1][DeviceIPv6Address=::][IPv6DefaultGateway=::][ModelNumber=CP-8961][NeighborIPv4Address=][NeighborIPv6Address=][NeighborDeviceID=][UNKNOWN_PARAMNAME:NeighborIPortID=][DHCPv4Status=1][DHCPv6Status=3][TFTPCfgStatus=1][DNSStatusUnifiedCM1=4][DNSStatusUnifiedCM2=4][DNSStatusUnifiedCM3=0][UNKNOWN_PARAMNAME:DNSv6StatusUnifiedCM1=0][UNKNOWN_PARAMNAME:DNSv6StatusUnifiedCM2=0][UNKNOWN_PARAMNAME:DNSv6StatusUnifiedCM3=0][VoiceVLAN=50][UnifiedCMIPAddress=10.1.10.5][LocalPort=50382][TimeStamp=1396377375][ReasonForOutOfService=18][LastProtocolEventSent=Sent:INVITE sip:915138521010@10.1.10.2;user=phone SIP/2.0 Cseq:101 INVITE CallId:b4e9b08c-a3ad023c-1fec1fa7-3b9727b1@10.1][LastProtocolEventReceived=Rcvd:SIP/2.0 202 Accepted Cseq:104 REFER CallId:b4e9b08c-a3ad026a-30d892f1-02c748ba@10.1.10.211][AppID=Cisco CallManager][ClusterID=NAregion][NodeID=CCMSub]: Information related to the last out-of-service event Apr 01 14:36:24 %UC_CALLMANAGER-6-EndPointRegistered: %[DeviceName=SEP0DD3B4E9][IPAddress=10.1.10.211][Protocol=SIP][DeviceType=540][PerfMonObjType=2][Description=User][UserID=User1][LoadID=sip8961.9-4-1-9][AssociatedDNs=5286,5285,5242,5237,5262,5217,5284,5294,5282,#86,][MACAddress=0DD3B4E9][IPAddrAttributes=0][ActiveLoadId=sip8961.9-4-1-9.loads][InactiveLoadId=sip8961.9-3-2SR1-1.loads][AppID=Cisco CallManager][ClusterID=NAregion][NodeID=CCMSub]: Endpoint registered Apr 01 14:36:24 %UC_CALLMANAGER-6-DeviceDnInformation: %[DeviceName=SEP0DD3B4E9][DeviceType=540][StationDesc=User][StationDn=5286,5285,5242,5237,5262,5217,5284,5294,5282,#86][AppID=Cisco CallManager][ClusterID=NAregion][NodeID=CCMSub]: List of directory numbers (DN) associated with this device 4. Switchport configuration: interface GigabitEthernet3/0/x switchport access vlan 10 switchport mode access switchport voice vlan 11 switchport port-security maximum 3 switchport port-security switchport port-security aging time 2 switchport port-security violation restrict switchport port-security aging type inactivity load-interval 30 spanning-tree portfast spanning-tree bpduguard enable Thanks, Tashi The information contained in this message is confidential and is intended only for the use of the individual or entity named above. It may contain proprietary or legally privileged information. Mistransmission shall not constitute a waiver of any rights or privileges. If you are not the designated recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is strictly prohibited. If you have received this message in error, please immediately notify the sender. Although this e-mail and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility
Re: [cisco-voip] Intermittent phone resets
We are experiencing very similar issues and are 99% convinced it is network related. We are running CUCM 6.1 and have just recently upgraded our network and since the beginning of that network upgrade (done in stages over the past year) we have been seeing exactly the same issue, especially the drop call in progress). TAC has been involved in trouble shooting but to date have found no confirmed issue.Once network upgrade is 100 % complete we will be moving to CUCM 10.x. All phones currently use SCCP and the majority of the failures are on 7911 but also occur on 7941's. I would think you can safely rule out CM 9.1. Thanks Terry From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Mar, Tashi Sent: June-05-14 11:42 AM To: cisco-voip@puck.nether.net Subject: [cisco-voip] Intermittent phone resets Hi, troubleshooting an issue where phones intermittently reset, either on hook or off hook (drops the call in progress). Logs and TAC claim it's a network issue, but has anyone seen similar problems on Call Manager 9.1? Basically, we want to rule out Call Manager as the culprit. Majority of phones using SIP, models 8891 and 9951, experiencing issues similar to those outlined here: https://supportforums.cisco.com/discussion/1084/ip-phones-randomly-rebooting Steps already taken: - upgrade to latest firmware - verify no POE errors on switch - cpu, memory on UCS servers ok - point phones to backup SUB, no change. Phones randomly reset when homed to Pub or Sub (both in separate locations). - Wireshark to see KeepAlives dropping 1.Phone logs show: SEP0DD3B4E9.cnf.xml.sgn (HTTP) 8:05:20p TCP connection timed out 8:07:22p Falling back to different CUCM 11:16:50p TCP connection timed out 11:18:51p Falling back to different CUCM 6:52:38p TCP connection timed out 6:54:39p Falling back to different CUCM 9:55:04a TCP connection timed out 9:57:05a Falling back to different CUCM 2.Call Manager logs show: - phone unregisters from Primary CUCM due to: [Reason=6] ConnectivityError - Network communication between the device and Unified CM has been interrupted. - phones fallback to secondary CUCM and then rehome to Primary CUCM: Reason code = 28, FallbackInitiated - The device has initiated a fallback and will automatically re-register to a higher-priority Unified CM. No action is necessary. 3. Call Manager syslogs display EndPointUnregistered: Apr 01 14:34:18 %UC_CALLMANAGER-3-EndPointUnregistered: %[DeviceName=SEP0DD3B4E9][IPAddress=10.1.10.211][Protocol=SIP][DeviceType=540][Description=User][Reason=6][IPAddrAttributes=0][LastSignalReceived=SIPConnControlInd][CallState=5286-call_initiated1][AppID=Cisco CallManager][ClusterID=NAregion][NodeID=CCMSub]: An endpoint has unregistered Apr 01 14:36:22 %UC_-3-LastOutOfServiceInformation: %[DeviceName=SEP0DD3B4E9][DeviceIPv4Address=10.1.10.211/24][IPv4DefaultGateway=192.168.51.1][DeviceIPv6Address=::][IPv6DefaultGateway=::][ModelNumber=CP-8961][NeighborIPv4Address=][NeighborIPv6Address=][NeighborDeviceID=][UNKNOWN_PARAMNAME:NeighborIPortID=][DHCPv4Status=1][DHCPv6Status=3][TFTPCfgStatus=1][DNSStatusUnifiedCM1=4][DNSStatusUnifiedCM2=4][DNSStatusUnifiedCM3=0][UNKNOWN_PARAMNAME:DNSv6StatusUnifiedCM1=0][UNKNOWN_PARAMNAME:DNSv6StatusUnifiedCM2=0][UNKNOWN_PARAMNAME:DNSv6StatusUnifiedCM3=0][VoiceVLAN=50][UnifiedCMIPAddress=10.1.10.5][LocalPort=50382][TimeStamp=1396377375][ReasonForOutOfService=18][LastProtocolEventSent=Sent:INVITE sip:915138521010@10.1.10.2;user=phone SIP/2.0 Cseq:101 INVITE CallId:b4e9b08c-a3ad023c-1fec1fa7-3b9727b1@10.1][LastProtocolEventReceived=Rcvd:SIP/2.0 202 Accepted Cseq:104 REFER CallId:b4e9b08c-a3ad026a-30d892f1-02c748ba@10.1.10.211][AppID=Cisco CallManager][ClusterID=NAregion][NodeID=CCMSub]: Information related to the last out-of-service event Apr 01 14:36:24 %UC_CALLMANAGER-6-EndPointRegistered: %[DeviceName=SEP0DD3B4E9][IPAddress=10.1.10.211][Protocol=SIP][DeviceType=540][PerfMonObjType=2][Description=User][UserID=User1][LoadID=sip8961.9-4-1-9][AssociatedDNs=5286,5285,5242,5237,5262,5217,5284,5294,5282,#86,][MACAddress=0DD3B4E9][IPAddrAttributes=0][ActiveLoadId=sip8961.9-4-1-9.loads][InactiveLoadId=sip8961.9-3-2SR1-1.loads][AppID=Cisco CallManager][ClusterID=NAregion][NodeID=CCMSub]: Endpoint registered Apr 01 14:36:24 %UC_CALLMANAGER-6-DeviceDnInformation: %[DeviceName=SEP0DD3B4E9][DeviceType=540][StationDesc=User][StationDn=5286,5285,5242,5237,5262,5217,5284,5294,5282,#86][AppID=Cisco CallManager][ClusterID=NAregion][NodeID=CCMSub]: List of directory numbers (DN) associated with this device 4. Switchport configuration: interface GigabitEthernet3/0/x switchport access vlan 10 switchport mode access switchport voice vlan 11 switchport port-security maximum 3 switchport port-security switchport port-security aging time 2 switchport port-security violation restrict switchport port-security aging type inactivity
Re: [cisco-voip] Intermittent phone resets
Just to add, we too are experiencing the same issue. Although I don't think we've had complaints of dropped calls. We first saw the issue when upgrading from v4.1 to v7.1 around two years ago, but because we didn't get complaints we had to prioritize. We're now seeing many more dropped phones. I'm not sure if the alerts were there in v4.1 and we just didn't have the alerts set up to come to us or not. It was a long time ago. We opened a TAC case, but unfortunately, we have not been able to work on it due to other pressing issues. I have to go back to our team to co-ordinate getting this going again. I'd like to resolve this. There should be no reason to have such a large number of de-registration events. We are primarily 7940/60 7912 phones with a number of 7911s, 7942, 7962 interspersed. I too am of the thought that it's not CUCM version dependent, but more so either switch configuration (loop detection) or firewall issues. The case owner said the only real way to figure things out is to get a packet capture from both the callmanager and the phones when it happens. Unfortunately, it's difficult to do so, since how do you guess where the phones are going to un-register from? We might have to do some sort of multi-vlan capture, but that is gonna be tough too. --- Lelio Fulgenzi, B.A. Senior Analyst, Network Infrastructure Computing and Communications Services (CCS) University of Guelph 519‐824‐4120 Ext 56354 le...@uoguelph.ca www.uoguelph.ca/ccs Room 037, Animal Science and Nutrition Building Guelph, Ontario, N1G 2W1 - Original Message - From: Tashi Mar t...@align.com To: Terry Oakley terry.oak...@rdc.ab.ca, Dennis Heim dennis.h...@wwt.com, cisco-voip@puck.nether.net Sent: Thursday, June 5, 2014 2:10:17 PM Subject: Re: [cisco-voip] Intermittent phone resets Hi all, appreciate the feedback. There are some SCCP phones (along with SIP) that reset too; TAC could not pinpoint any phone firmware or CUCM bugs either. Will find out the switch OS, but environment is all stacked 3750s at the core and access layers in both locations. Any chance you recall the bug ID? Definitely will check into: - Switch bug related to spanning tree and excessive Topology Change Notifications (TCN). They actually replaced some access switches, but that doesn’t mean the configuration was modified. - Circular buffer packet captures We did verify that the ASAs are not doing any SIP or SCCP inspection; voice traffic on this network does not pass through firewalls anyway. Thanks! Tashi Mar | IP Telephony Engineer From: Terry Oakley [mailto:terry.oak...@rdc.ab.ca] Sent: Thursday, June 05, 2014 2:02 PM To: Heim, Dennis; Mar, Tashi; cisco-voip@puck.nether.net Subject: RE: Intermittent phone resets What version of switches and OS were you using? Thanks Terry From: cisco-voip [ mailto:cisco-voip-boun...@puck.nether.net ] On Behalf Of Heim, Dennis Sent: June-05-14 11:50 AM To: Mar, Tashi; cisco-voip@puck.nether.net Subject: Re: [cisco-voip] Intermittent phone resets I had this awhile back, and it ended up being a bug on the switches related to spanning tree and excessive Topology Change Notifications (TCN). Dennis Heim | Collaboration Solutions Architect World Wide Technology, Inc. | +1 314-212-1814 twitter chatPhonevideo From: cisco-voip [ mailto:cisco-voip-boun...@puck.nether.net ] On Behalf Of Mar, Tashi Sent: Thursday, June 05, 2014 1:43 PM To: cisco-voip@puck.nether.net Subject: [cisco-voip] Intermittent phone resets Hi, troubleshooting an issue where phones intermittently reset, either on hook or off hook (drops the call in progress). Logs and TAC claim it’s a network issue, but has anyone seen similar problems on Call Manager 9.1? Basically, we want to rule out Call Manager as the culprit. Majority of phones using SIP, models 8891 and 9951, experiencing issues similar to those outlined here: https://supportforums.cisco.com/discussion/1084/ip-phones-randomly-rebooting Steps already taken: - upgrade to latest firmware - verify no POE errors on switch - cpu, memory on UCS servers ok - point phones to backup SUB, no change. Phones randomly reset when homed to Pub or Sub (both in separate locations). - Wireshark to see KeepAlives dropping 1. Phone logs show: SEP0DD3B4E9.cnf.xml.sgn (HTTP) 8:05:20p TCP connection timed out 8:07:22p Falling back to different CUCM 11:16:50p TCP connection timed out 11:18:51p Falling back to different CUCM 6:52:38p TCP connection timed out 6:54:39p Falling back to different CUCM 9:55:04a TCP connection timed out 9:57:05a Falling back to different CUCM 2. Call Manager logs show: - phone unregisters from Primary CUCM due to: [Reason=6] ConnectivityError - Network communication between the device and Unified CM has been interrupted. - phones fallback to secondary CUCM and then rehome to Primary CUCM: Reason code = 28, FallbackInitiated - The device has initiated
Re: [cisco-voip] Intermittent phone resets
I had a case where the guy had his CUCM server switch ports SPANed to some dedicated capture gear. He was able to get me captures from all his CUCM servers up to a week back. That was a pretty nice thing to have. Unfortunately, you're limited on the phone side in that you'll need to set it up for quite a few phones to increase your chances of catching it. On Thu, Jun 5, 2014 at 2:29 PM, Lelio Fulgenzi le...@uoguelph.ca wrote: Just to add, we too are experiencing the same issue. Although I don't think we've had complaints of dropped calls. We first saw the issue when upgrading from v4.1 to v7.1 around two years ago, but because we didn't get complaints we had to prioritize. We're now seeing many more dropped phones. I'm not sure if the alerts were there in v4.1 and we just didn't have the alerts set up to come to us or not. It was a long time ago. We opened a TAC case, but unfortunately, we have not been able to work on it due to other pressing issues. I have to go back to our team to co-ordinate getting this going again. I'd like to resolve this. There should be no reason to have such a large number of de-registration events. We are primarily 7940/60 7912 phones with a number of 7911s, 7942, 7962 interspersed. I too am of the thought that it's not CUCM version dependent, but more so either switch configuration (loop detection) or firewall issues. The case owner said the only real way to figure things out is to get a packet capture from both the callmanager and the phones when it happens. Unfortunately, it's difficult to do so, since how do you guess where the phones are going to un-register from? We might have to do some sort of multi-vlan capture, but that is gonna be tough too. --- Lelio Fulgenzi, B.A. Senior Analyst, Network Infrastructure Computing and Communications Services (CCS) University of Guelph 519‐824‐4120 Ext 56354 le...@uoguelph.ca www.uoguelph.ca/ccs Room 037, Animal Science and Nutrition Building Guelph, Ontario, N1G 2W1 -- *From: *Tashi Mar t...@align.com *To: *Terry Oakley terry.oak...@rdc.ab.ca, Dennis Heim dennis.h...@wwt.com, cisco-voip@puck.nether.net *Sent: *Thursday, June 5, 2014 2:10:17 PM *Subject: *Re: [cisco-voip] Intermittent phone resets Hi all, appreciate the feedback. There are some SCCP phones (along with SIP) that reset too; TAC could not pinpoint any phone firmware or CUCM bugs either. Will find out the switch OS, but environment is all stacked 3750s at the core and access layers in both locations. Any chance you recall the bug ID? Definitely will check into: - Switch bug related to spanning tree and excessive Topology Change Notifications (TCN). They actually replaced some access switches, but that doesn’t mean the configuration was modified. - Circular buffer packet captures We did verify that the ASAs are not doing any SIP or SCCP inspection; voice traffic on this network does not pass through firewalls anyway. Thanks! Tashi Mar | IP Telephony Engineer *From:* Terry Oakley [mailto:terry.oak...@rdc.ab.ca] *Sent:* Thursday, June 05, 2014 2:02 PM *To:* Heim, Dennis; Mar, Tashi; cisco-voip@puck.nether.net *Subject:* RE: Intermittent phone resets What version of switches and OS were you using? Thanks Terry *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net cisco-voip-boun...@puck.nether.net] *On Behalf Of *Heim, Dennis *Sent:* June-05-14 11:50 AM *To:* Mar, Tashi; cisco-voip@puck.nether.net *Subject:* Re: [cisco-voip] Intermittent phone resets I had this awhile back, and it ended up being a bug on the switches related to spanning tree and excessive Topology Change Notifications (TCN). *Dennis Heim | Collaboration Solutions Architect* World Wide Technology, Inc. | +1 314-212-1814 [image: twitter] https://twitter.com/CollabSensei [image: chat][image: Phone] +13142121814[image: video] *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net cisco-voip-boun...@puck.nether.net] *On Behalf Of *Mar, Tashi *Sent:* Thursday, June 05, 2014 1:43 PM *To:* cisco-voip@puck.nether.net *Subject:* [cisco-voip] Intermittent phone resets Hi, troubleshooting an issue where phones intermittently reset, either on hook or off hook (drops the call in progress). Logs and TAC claim it’s a network issue, but has anyone seen similar problems on Call Manager 9.1? Basically, we want to rule out Call Manager as the culprit. Majority of phones using SIP, models 8891 and 9951, experiencing issues similar to those outlined here: https://supportforums.cisco.com/discussion/1084/ip-phones-randomly-rebooting Steps already taken: - upgrade to latest firmware - verify no POE errors on switch - cpu, memory on UCS servers ok - point phones to backup SUB, no change. Phones randomly reset when homed to Pub or Sub (both in separate locations). - Wireshark to see KeepAlives dropping
Re: [cisco-voip] Intermittent phone resets
Just went through something similar with a client, however it was only happening to newly installed 8961s, which replaced their old 7940/60s. Extremely odd but for them it turned out to be patch cables between the patch panel and the switch. They worked fine on the 7940/60 but would intermittently drop for the new phones. They replaced their patch cables and the problem disappeared.??!!??!! On Thu, Jun 5, 2014 at 3:24 PM, AbdusSaboor Khan saboor.k...@gmail.com wrote: Hi, We had this issue so many time and found out every time different Solution: 1- We had the issue CUCM and need to upgrade it, for temp fix we had made the thsi change on Device Detect Unified CM Connection Failuremake it Delayed so the heartbeat can go after a while. 2- Second time it was cable issue on Switch and we have changed the cable on switch port for to be on safe side put changed the port as well as. 3- Third time it was the load not support so I made it a bit backward and phones works ok. Regards, Abdus Saboor On Thu, Jun 5, 2014 at 2:41 PM, Brian Meade bmead...@vt.edu wrote: I had a case where the guy had his CUCM server switch ports SPANed to some dedicated capture gear. He was able to get me captures from all his CUCM servers up to a week back. That was a pretty nice thing to have. Unfortunately, you're limited on the phone side in that you'll need to set it up for quite a few phones to increase your chances of catching it. On Thu, Jun 5, 2014 at 2:29 PM, Lelio Fulgenzi le...@uoguelph.ca wrote: Just to add, we too are experiencing the same issue. Although I don't think we've had complaints of dropped calls. We first saw the issue when upgrading from v4.1 to v7.1 around two years ago, but because we didn't get complaints we had to prioritize. We're now seeing many more dropped phones. I'm not sure if the alerts were there in v4.1 and we just didn't have the alerts set up to come to us or not. It was a long time ago. We opened a TAC case, but unfortunately, we have not been able to work on it due to other pressing issues. I have to go back to our team to co-ordinate getting this going again. I'd like to resolve this. There should be no reason to have such a large number of de-registration events. We are primarily 7940/60 7912 phones with a number of 7911s, 7942, 7962 interspersed. I too am of the thought that it's not CUCM version dependent, but more so either switch configuration (loop detection) or firewall issues. The case owner said the only real way to figure things out is to get a packet capture from both the callmanager and the phones when it happens. Unfortunately, it's difficult to do so, since how do you guess where the phones are going to un-register from? We might have to do some sort of multi-vlan capture, but that is gonna be tough too. --- Lelio Fulgenzi, B.A. Senior Analyst, Network Infrastructure Computing and Communications Services (CCS) University of Guelph 519‐824‐4120 Ext 56354 le...@uoguelph.ca www.uoguelph.ca/ccs Room 037, Animal Science and Nutrition Building Guelph, Ontario, N1G 2W1 -- *From: *Tashi Mar t...@align.com *To: *Terry Oakley terry.oak...@rdc.ab.ca, Dennis Heim dennis.h...@wwt.com, cisco-voip@puck.nether.net *Sent: *Thursday, June 5, 2014 2:10:17 PM *Subject: *Re: [cisco-voip] Intermittent phone resets Hi all, appreciate the feedback. There are some SCCP phones (along with SIP) that reset too; TAC could not pinpoint any phone firmware or CUCM bugs either. Will find out the switch OS, but environment is all stacked 3750s at the core and access layers in both locations. Any chance you recall the bug ID? Definitely will check into: - Switch bug related to spanning tree and excessive Topology Change Notifications (TCN). They actually replaced some access switches, but that doesn’t mean the configuration was modified. - Circular buffer packet captures We did verify that the ASAs are not doing any SIP or SCCP inspection; voice traffic on this network does not pass through firewalls anyway. Thanks! Tashi Mar | IP Telephony Engineer *From:* Terry Oakley [mailto:terry.oak...@rdc.ab.ca] *Sent:* Thursday, June 05, 2014 2:02 PM *To:* Heim, Dennis; Mar, Tashi; cisco-voip@puck.nether.net *Subject:* RE: Intermittent phone resets What version of switches and OS were you using? Thanks Terry *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net cisco-voip-boun...@puck.nether.net] *On Behalf Of *Heim, Dennis *Sent:* June-05-14 11:50 AM *To:* Mar, Tashi; cisco-voip@puck.nether.net *Subject:* Re: [cisco-voip] Intermittent phone resets I had this awhile back, and it ended up being a bug on the switches related to spanning tree and excessive Topology Change Notifications (TCN). *Dennis Heim | Collaboration Solutions Architect* World Wide Technology, Inc. | +1 314-212-1814 [image: twitter]
Re: [cisco-voip] Intermittent phone resets
Hi, quite likely you are running into CSCeg63177. We had the exact same behaviour. Would it be possible to increase the port security ageing timer to 5? cheers bernhard On Thu, Jun 5, 2014 at 8:10 PM, Mar, Tashi t...@align.com wrote: Hi all, appreciate the feedback. There are some SCCP phones (along with SIP) that reset too; TAC could not pinpoint any phone firmware or CUCM bugs either. Will find out the switch OS, but environment is all stacked 3750s at the core and access layers in both locations. Any chance you recall the bug ID? Definitely will check into: - Switch bug related to spanning tree and excessive Topology Change Notifications (TCN). They actually replaced some access switches, but that doesn’t mean the configuration was modified. - Circular buffer packet captures We did verify that the ASAs are not doing any SIP or SCCP inspection; voice traffic on this network does not pass through firewalls anyway. Thanks! Tashi Mar | IP Telephony Engineer *From:* Terry Oakley [mailto:terry.oak...@rdc.ab.ca] *Sent:* Thursday, June 05, 2014 2:02 PM *To:* Heim, Dennis; Mar, Tashi; cisco-voip@puck.nether.net *Subject:* RE: Intermittent phone resets What version of switches and OS were you using? Thanks Terry *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net cisco-voip-boun...@puck.nether.net] *On Behalf Of *Heim, Dennis *Sent:* June-05-14 11:50 AM *To:* Mar, Tashi; cisco-voip@puck.nether.net *Subject:* Re: [cisco-voip] Intermittent phone resets I had this awhile back, and it ended up being a bug on the switches related to spanning tree and excessive Topology Change Notifications (TCN). *Dennis Heim | Collaboration Solutions Architect* World Wide Technology, Inc. | +1 314-212-1814 [image: twitter] https://twitter.com/CollabSensei [image: chat][image: Phone] +13142121814[image: video] *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net cisco-voip-boun...@puck.nether.net] *On Behalf Of *Mar, Tashi *Sent:* Thursday, June 05, 2014 1:43 PM *To:* cisco-voip@puck.nether.net *Subject:* [cisco-voip] Intermittent phone resets Hi, troubleshooting an issue where phones intermittently reset, either on hook or off hook (drops the call in progress). Logs and TAC claim it’s a network issue, but has anyone seen similar problems on Call Manager 9.1? Basically, we want to rule out Call Manager as the culprit. Majority of phones using SIP, models 8891 and 9951, experiencing issues similar to those outlined here: https://supportforums.cisco.com/discussion/1084/ip-phones-randomly-rebooting Steps already taken: - upgrade to latest firmware - verify no POE errors on switch - cpu, memory on UCS servers ok - point phones to backup SUB, no change. Phones randomly reset when homed to Pub or Sub (both in separate locations). - Wireshark to see KeepAlives dropping 1.Phone logs show: SEP0DD3B4E9.cnf.xml.sgn (HTTP) 8:05:20p TCP connection timed out 8:07:22p Falling back to different CUCM 11:16:50p TCP connection timed out 11:18:51p Falling back to different CUCM 6:52:38p TCP connection timed out 6:54:39p Falling back to different CUCM 9:55:04a TCP connection timed out 9:57:05a Falling back to different CUCM 2.Call Manager logs show: - phone unregisters from Primary CUCM due to: [Reason=6] ConnectivityError - Network communication between the device and Unified CM has been interrupted. - phones fallback to secondary CUCM and then rehome to Primary CUCM: Reason code = 28, FallbackInitiated - The device has initiated a fallback and will automatically re-register to a higher-priority Unified CM. No action is necessary. 3. Call Manager syslogs display EndPointUnregistered: Apr 01 14:34:18 %UC_CALLMANAGER-3-EndPointUnregistered: %[DeviceName=SEP0DD3B4E9][IPAddress=10.1.10.211][Protocol=SIP][DeviceType=540][Description=User][Reason=6][IPAddrAttributes=0][LastSignalReceived=SIPConnControlInd][CallState=5286-call_initiated1][AppID=Cisco CallManager][ClusterID=NAregion][NodeID=CCMSub]: An endpoint has unregistered Apr 01 14:36:22 %UC_-3-LastOutOfServiceInformation: %[DeviceName=SEP0DD3B4E9][DeviceIPv4Address= 10.1.10.211/24][IPv4DefaultGateway=192.168.51.1][DeviceIPv6Address=::][IPv6DefaultGateway=::][ModelNumber=CP-8961][NeighborIPv4Address=][NeighborIPv6Address=][NeighborDeviceID=][UNKNOWN_PARAMNAME:NeighborIPortID=][DHCPv4Status=1][DHCPv6Status=3][TFTPCfgStatus=1][DNSStatusUnifiedCM1=4][DNSStatusUnifiedCM2=4][DNSStatusUnifiedCM3=0][UNKNOWN_PARAMNAME:DNSv6StatusUnifiedCM1=0][UNKNOWN_PARAMNAME:DNSv6StatusUnifiedCM2=0][UNKNOWN_PARAMNAME:DNSv6StatusUnifiedCM3=0][VoiceVLAN=50][UnifiedCMIPAddress=10.1.10.5][LocalPort=50382][TimeStamp=1396377375][ReasonForOutOfService=18][LastProtocolEventSent=Sent:INVITE
