8851 MPP phone reboots

[mwiater]

I have around 500 8851 MPP phones on 11.3.5 registering with the NetSapiens platform. The phones can and do go into a state where all the buttons on the phone go yellow for up to 30 seconds, sometimes it's around 10 seconds. In some cases the screen says that they are rebooting, probably always but users are not recognizing change.

We use TLS and SRTP exclusively.

This seems to be happening at random times, including in call. 

Is there a support path other than this forum to report issues?

[Geovani]

Please raise a TAC case. 

[mwiater]

Thank you Geovani, how does one do that without a service contract on the phones?

[Ratheesh Kumar]

hi there 

You need a valid contract to open a TAC and get assistance. But this issue could be mostly with the network side of things. But you can also try upgrading a bunch of phones to the latest firmware and observe

Also discuss with your Cisco AM/SE, they can help you with the contract part

Hope this Helps

Cheers
Rath!

***Please rate helpful posts and if applicable mark "Accept as a Solution"***

[Geovani]

If you don't have a service contract, then you have to ask the communities, like you're doing  

Extremely difficult to know what's happening without logs. 

This can be a network issue, or, can also be that the provider is pushing changes to the phone, making the phones lose registration and reboot. 

Check with your service provider. I have seen cases where the provider has overlapping configuration files, causing the phones to download different configuration for the same parameter twice. 

[mwiater]

Thanks folks.

I am the service provider and I am reasonably confident that we are not pushing changes to the phones with different configurations.    We're running 11.3.5 which was the latest a month ago, reading the release notes for 11.3.6 does not suggest that it fixed random system reboots.

I'm trying to obtain logs from the phones and pinpoint the moment the phone reboots.  I'll come back when I feel like i have something from those logs.

Does psirt still exist for security reports and do they handle these phones or is there somewhere else to report security issues?

[Geovani]

Take a look at the provisioning files and compare them. 

Is this issue new? Did it start happening suddenly? Were there any changes on the network?

As for security advisories, please see https://tools.cisco.com/security/center/publicationListing.x

[mwiater]

We just deployed these 500 phones to this client 10 days ago, it's been happening randomly since day one.

We did see a problem where TRY_Backup_RSC being set to 503, but no alternate proxy config, would also reboot the phone. This setting is set by Netsapiens (I'm working on getting this removed).  I thought that I could unset this parameter with a profile rule b file, like so.

<device>       
<flat-profile>
<Group_1_Paging_Script ua="na">pggrp=224.0.1.116:34560;name=All;num=70001;listen=yes;</Group_1_Paging_Script>   
<Try_Backup_RSC ua="na"></Try_Backup_RSC>
</flat-profile>
</device>     

Am I allowed to put the same config item in the main provisioning file and then put it in a profile rule b file such that the item is configured per the profile rule b?

I appreciate the help you all are providing here. Thank you

[boteman]

I have discovered, and it has been confirmed by others who are knowledgeable, that the 8841/88xx family of phones REQUIRES all configuration parameters be specified in the XML configuration file or the phone does not behave as expected.

I tried to trim down the size of my master config file and had unexpected behavior, so I started over with the massive 2500+ line master XML file, then a second very small file named for each phone's MAC address that specifies the i.p. address, station name, and not much else. That seems to work for me.

I also found the BLF keys turning amber briefly, but I believe this was because the subscription timeout that I had originally set was much too short and did not allow the PBX sufficient time to renew the presence subscription. After making the timeout much longer I have not seen the amber BLF keys...so far.

[mwiater]

As i look at the web interface of some of the phones, I see it's taking my Try_Backup_RSC parameter update from the profile_rule_b file.  So that seems like it's doing what i want.

[Ratheesh Kumar]

Hi there

https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/213548-procedure-to-collect-the-phone-console-l.html

Try collecting the logs and start analyzing. Definitely the starting point

Hope this Helps

Cheers
Rath!

***Please rate helpful posts and if applicable mark "Accept as a Solution"***

[mwiater]

Thank you for that. 

These are MPP phones, so slightly different but yes i have been doing that against each phone when I get these reports. Thus far the reports have not been timely and the log data has cycled out.

I've been using some powershell to help speed things along,  iwr http://ip.addr.of.phone/log/messages  | Write-host to try to catch the problem in near real time.

I was able to capture some phone logs from when the phone reboot after the Try_backup_RSC=503 and the call flow contained a SIP 503