8851 Phones not coming out of SRST

[permalldnit]

Hello,

I have a branch office with 58 x 8851 Cisco Phones (SIP) connected. Voice Gateway is a Cisco 2911 Router. Phones are plugged into a Cisco 3850 switchcore.

Branch and Main office are connected via a VPN between 2 x Fortinet Firewalls.

If the VPN goes down the phones go into SRST.

If I type show call-manager-fallback licenses I can see all 58 licenses used. Phones work fine in SRST.

When the link returns the phones display show that they are reregistering and registered. All looks good ,however:-

1) On Call Manager v10.5.1 I can see all the phones and they all say "unregistered"

2) Show Call-manager-fallback license shows 58 phones still with an SRST license

To get them out of SRST i have to either bounce the port on the switch or reboot the phones. I have seen there is another command where you can go into call-manager-fallback and type reset all or reset H.H.H (mac address) these commands don't work.

Does anyone have any idea what is potentially wrong?

I am thinking there is something either missing from the switch port or the voice gateway.

Thanks,

Glenn

[Georgios Fotiadis]

Your phones remain registered at SRST, that is for sure. Try the latest firmware as @Chris Deren had earlier suggested (cmterm-88xx-sip.12-0-1SR1-1.k3.cop.sgn).

[permalldnit]

Georgios,

Thanks for the prompt reply. We will try the latest firmware.

Can I ask if I need the line SIP PORT 5060 anywhere on my voice gateway?

Thanks,

Glenn

[permalldnit]

All phones are now running the latest firmware which I think was released at the end of November this year.

I put all phones into SRST this morning and then reconnected the link back to the remote Call Manager. No improvement all phones are still "unregistered" same error as before on the phone URL and still pointing to the voice gateway for the "ACTIVE" and 58 licenses still being used in sh call-manager-fallback licenses.

Incidentally I also have 3 x 7937's in the same office it seems as though they unregister and register so I think the problem is just SIP as the SCCP phones are fine.

Thanks,

Glenn

[markbatts]

I know this doesn't help much but I've had similar issue with this aswell.I have experienced it on 88xx and 99xx phones and have never successfully got to the bottom of it.

The best I can say is that it appears that phones that experience a lot of calls tend to be affected more.Do your phones with side modules ( BKEMs etc)

I would be very interested if you get figure this out.We actually had a bug logged against the 99xx phones for this but couldn't progress it as when the phones stopped coming out of SRST they also stopped producing phone logs which TAC needed.

[permalldnit]

Mark,

Generally the phones work ok its just when we need to use SRST. We run IPSEC tunnels between Fortinet Firewalls and the line has gone down twice since the firewalls have been in. Both times all the phones go into SRST but never come out. Each time we either bounce the ports or reboot all the phones.

I have searched the web for an answer with no joy apparently Cisco TAC want $1600 to open a case, which is a joke. At the moment I am leaning on the fact that it could be something blocking it on the firewalls. If I ever get an answer I will post it on here.

[carlosalmonte]

Hi,
Did you ever get this resolved? I am having the same issue. I also have my phones behind Fortinet firewalls, even though I have provided the security team all the ports that needed to be opened for communicating with CUCM.

Thanks,
Carlos

[permalldnit]

Carlos,

No still no joy with this. Have put it down to the fact that we are using a 2911 router and it only supports 50 SRST licenses and I have 80 phones in the office. I have run debugs and had Fortinet Support investigate but they cannot see anything wrong.

If you ever find an answer it would be great to know what it is. For now we are in talks to upgrade to CUCM 12 and we will be refreshing the routers and they will have more licenses.

Thanks,

Glenn

[Juan Ospina]

Hi Glen, 

So, I am having a similar, if not, the same issue. This is what I have found.  I think the issue is DNS related, but I have not been able to test out my solution yet.  Let me know if it helps.

Cisco Bug: CSCvd03500 - Phones do not fallback to Call Manager and stay register with Survivable Remote Site Telephony

Last Modified

Jul 30, 2018

Products (11)

• Cisco IP Phone 8800 Series
• Cisco IP Phone 8865
• Cisco IP Phone 8851
• Cisco IP Phone 7841
• Cisco IP Phone 7821
• Cisco IP Phone 8811
• Cisco IP Phone 8861
• Cisco IP Phone 7861
• Cisco IP Phone 8845
• Cisco IP Phone 8841

View all products in Bug Search Tool

Known Affected Releases

11.7(1)

Description (partial)

Symptom:
88xx phones get stuck in SRST during a failover scenario and cease querying DNS for CUCM IP due to DNS being unreachable across WAN along with CUCM

Conditions:
Phone loses connection to SRST while failed over and clears out DNS resolution cache and cannot reach DNS (for instance, DNS is colocated with CUCM and WAN is down), running 11-7-1 or older

[permalldnit]

Juan,

I have played around with DNS without any success. Have you made any head way?

Recently I tried looking into switching the ALG off on the Fortinet but this made no difference. To rule out the Fortinet firewalls causing the issue I put an 8851 in another office, put that into SRST and then restored the links. The 8851 came back up with no issues. All my Fortinets are configured the same and the ALG isn't switched off in that office. I now just think its down to the licensing on the router. I have 79 phones in the problematic location and I only have 50 SRST licenses. We will soon be upgrading the router and will have 100 licenses I think this will solve the issue.

As a side note the new 8851 I tested with is running active load - sip88xx.11-7-1-17

The problematic office now has the active load on the phones set to sip88xx12-0-1SR1-1 these were updated because TAC said that was the answer.

Cheers,

[jace.mortensen]

Hello all,

Was hoping to get an update as I have a client with exact symptoms, including the fact that Fortinet VPN tunnel is being used to these remote sites.  Only resolution so far is to reboot the 8800 phones.  We are running CUCM 12.0 and phone load 12.5.

Any input is greatly appreciated. 

All the best,

Jace

[permalldnit]

Jace,

Our issue was down to the fact that we didn't have enough SRST licences on our router in the office. We were running a Cisco 2911 and it only had 50 licenses, however, we had 80 phones.

We are now about to go to CUCM 12.5 and we are also putting a Call Manager in that office as its one of our major offices.

I notice you reboot all the phones, you can also login to the switches and run show cdp neighbors which will list the ports that the phones are plugged into. You can then bounce the ports which might be a quicker way of geting the phones back up.

Cheers,

Glenn

[Juan Ospina]

Hey Jace,

Took me a couple of days to figure out, but it’s the way the firewall handles SIP sessions that was the root cause of my issue. The following resolved my issue. Hope this helps.

SOLUTION(s):

Delete session helper for SIP

Config system session-helper – type “show” for list
edit 13 <- Usually
set name sip
set port 5060
set protocol 17


AND/OR


config voip profile
edit "default"
set comment "Default VoIP profile."
config sip
set register-rate 100
set invite-rate 100
set block-long-lines disable
set block-unknown disable

[jace.mortensen]

Thanks Glenn for your input and for originally opening this discussion and Juan for your details.

In our situation we have ample licenses so I believe the issue is more relative to the fortinet vpn tunnels/firewalls.  We have other sites using mpls or dedicated fiber that don't experience these symptoms of not releasing or sending "unregister requests" to SIP esrst 2901 gateway even though the WAN connectivity (or vpn tunnel) is up and call managers can ping the remote phones IPs.

I don't have administrative access to the fortinet side of this equation so will work with client to take Juan's advice.  I'll try to confirm here afterwards.

Salud!

Jace