cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4708
Views
15
Helpful
15
Replies

SIP SRST won't fallback to CUCM once connectivity restores

mohsin majeed
Level 2
Level 2

Hi,

- Branch site have sip phone 7841 model. Phones successfuly goes into SRST while WAN connectivity lost.

Phone keep registering in SRST and won't re-register to CUCM when WAN connectivity restores.

As workaround i have to give  "no voice register global"command and recofigure. So, phone register to CUCM again.

- Also i am not able to call to PSTN during SRST in service. Pots Dial-peer is configured with 9T to the analog voice ports.

 

Regards,

 

15 Replies 15

Manish Gogna
Cisco Employee
Cisco Employee

Couple of good links that will help you verify your config

https://supportforums.cisco.com/t5/ip-telephony/sip-srst-configuration-for-cisco-7841/td-p/2603331

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cusrst/admin/sccp_sip_srst/configuration/guide/SCCP_and_SIP_SRST_Admin_Guide/srst_overview.html

 

If the issue still persists you need to get a pcap from an IP phone while it tries to fall back to cucm from srst mode.

 

Manish

Hi,
Here is my configuration, can u plz suggest if i am doing any mistake.

Whenever WAN connectivity lost, phones register to the branch SRST successfully.

But, on restoring the connectivity phones don't register back to CM.

 

Any idea please

 

 

Regards,

 

There are many bugs related to phone firmware affecting proper registration/de-registrations of SIP phone in SRST, I would first upgrade your phones to latest firmware file to see if the issue gets resolved.

Hi Chris,

Upgraded to the latest firmware with no luck. Phones still stuck on SRST while WAN link restores.

 

You will need a pcap from the phone ( and preferably the corresponding pcap from cucm to which it is supposed to register ) to understand why it is happening.

 

Manish

- Do rate useful posts -

Nothing in your SRST config would prevent the phone from registering back with UCM, that behaviour is controlled by phone firmware. I agree with Chris that firmware is most likely the culprit here. There have been many issues with several models of phones not being able to transition back and forth from SRST properly on certain software loads. Can you post the firmware version you upgraded to?

 

In terms of logging and root cause analysis, as Manish mentioned the "full meal deal" of logs would be a PCAP from the phone and from CUCM. This would prove whether the phone is trying to re-establish TCP connecitivity with CUCM at all. If it is not even trying, then we have even more certainty that it is firmware related. I understand that sometimes it is difficult to get the PCAP from the phone side (which is the more valuable one to obtain in this case) if you don't have physical access. For the CUCM side, packet captures are super easy to run and download, for more on this read here.

 

In the absence of a PCAP, what you could grab is the console phone logs from the phone web interface. Enable web access on the phone, drop the phone into SRST, then restore network connectivity back to CUCM. After a few minutes grab the console logs for the time range you were testing. There should be some clues in that log whether or not the phone tried to re-establish a connection to UCM.

Here is how to grab the console logs from the 78XX phones:

  1. Enable web access for the phone in CUCM
  2. Navigate to the phone web interface (ip address of the phone)
  3. Navigate to Device Logs > Console Logs
  4. Right click and save all of the .txt logs under the "Current Logs in /var/log:" section. Screenshot below.

    7841 Phone Logs.png

Please let us know if this helps, or if you have more questions, and feel free to post any additional logs you capture! If there is one thing this community loves, it is the thrill of crunching through logs!! :)

 

- Jon

Hi Jonathan,

Thanks for your detailed reply,

I will collect the information and get back again.

 

Much appreciated.

 

Regards,

 

 

 

I have the same problem, did you find the solution? I would appreciate your answer.

Juan,

Open a new thread. It will be easier to help you that way.

carlosalmonte
Level 1
Level 1
Hi,
Did you ever get this resolved? I have the same issue too, also with 8851s and 8831s.

Thanks,
Carlos

Do you use FQDN by any chance ? What is the firmware on these phones ?


Hi Nipun,

Thanks for your reply.  Yes, we use FQDN.  I looked into bug CSCus18070:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCus18070/?reffering_site=dumpcr

However, rebooting the phones is not a good workaround.  I have tried firmwares 11.7, 12.0, and 12.1.

 

Thanks,

Carlos

 

I believe a more relevant defect for you scenario would be -
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvd03500/?reffering_site=dumpcr

It is fixed in 12.X but if you are still facing issue with that firmware, I would suggest opening up a TAC case.

Nipun,


The known fixed releases points to ES versions:

12.0(1)MN387
12.0(1)MN348
11.7(1)ES7
11.7(1)ES5


I have tried 10.0(1)SR1 and 12.1(1) with the same results.


Thanks,

Carlos
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: