cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2619
Views
0
Helpful
4
Replies

CSF client unregistering with following code intermittently: ReasonForOutOfService=111][UNKNOWN_PARAMNAME:ReasonForOutOfServiceText=Application-Requested-Destroy]

Jay Schulze
Level 1
Level 1

Client is using jabber. And complaining about it resetting. And when I look in syslog I see the following. After which the phone will re-register.

 

LastOutOfServiceInformation: %[DeviceName=CSFNZSELYERMO][DeviceIPv4Address=10.211.137.25 / 0][IPv4DefaultGateway=10.211.137.254][DeviceIPv6Address=][IPv6DefaultGateway=][ModelNumber=CSF][NeighborIPv4Address=][NeighborIPv6Address=][NeighborDeviceID=][NeighborPortID=][DHCPv4Status=1][DHCPv6Status=3][TFTPCfgStatus=1][DNSStatusUnifiedCM1=1][DNSStatusUnifiedCM2=1][DNSStatusUnifiedCM3=3][VoiceVLAN=0][UnifiedCMIPAddress=syd02tl001ccm01.tl001.ciscocc.telstra.com][LocalPort=4294967295][TimeStamp=1529008493][ReasonForOutOfService=111][UNKNOWN_PARAMNAME:ReasonForOutOfServiceText=Application-Requested-Destroy][UNKNOWN_PARAMNAME:ActiveInterface=Wired][LastProtocolEventSent=][LastProtocolEventReceived=Rcvd:SIP/2.0 200 OK Cseq:105 REGISTER

 

After which CUCM closes the tcp connection. Does anyone know what could be the cause for this? And why is it using such a crazy local port?

 

Thanks.

4 Replies 4

Ratheesh Kumar
VIP Alumni
VIP Alumni

Hi there

 

 

 

You should check the below Enhancement bug. However, you should narrow down why your device is getting reset. Is the CSF getting reset internally or connecting via MRA. Check the TCP connectivity, DNS configs, Firewalls, Also worth upgrading your J4W to the latest version.

 

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCux22594

 

Symptom:
A phone re-registers to CUCM and we see a LastOutOfServiceInformation alarm with a ReasonForOutOfService:111.

Conditions:
A phone re-registers to CUCM and we see a LastOutOfServiceInformation alarm with a ReasonForOutOfService:111.

Workaround:
N/A

Further Problem Description:
Please update the RTMT alert reference to account for any missing enum values pertaining to LastOutOfServiceInformation including ReasonForOutOfService:111

 

 

 

Hope this helps!

Cheers
Rath!


***Please rate helpful posts***

 

 

 

Thanks.

 

Yeah I saw that defect. My understanding tho is it is really just cosmetic and deals with the alarm definitions.

Prashant Sharma
Cisco Employee
Cisco Employee

Hi Jay

As per syslog output, it looks CUCM closed the active connection to CSF client.
"[ReasonForOutOfService=111][UNKNOWN_PARAMNAME:ReasonForOutOfServiceText=Application-Requested-Destroy]"
There could be multiple reasons for that:
SIP profile parameter not set as per the recommended value and CUCM is not receiving the response for register message or  continuous flap register/re-register messages.
Verify the applied SIP profile parameter as per Standard SIP profile.
As per Logs Output I see the connection "ActiveInterface =Wired" probably Wired users, however I have seen this output for WiFi users as well.
Let me know if all users are affected or few are facing this issue.

If Users connected over wifi are impacted then it could be an issue with any of the roaming WAP.
Try connecting affected users over LAN and see the behaviour, if there is wi fi issue then you have isolated your issue to WAP.
If you isolated an issue to WAP, collect PCAP from Source and Destinations and probably you will see TCP-Sync out of sequence, I have seen firewall causing such issues in some cases for Newly/Upgraded AP, check accordingly.
If users are still affected after connecting over LAN, collect PRT, PCAP and detailed CCM logs to verify the registrations flap cause.

 

 

Regards,

Prassha3

 

Kindly rate my contributions if you find it helpful.

Thanks Prassha.

Yes they are using standard sip profile.

It seems this is happening to all users using CSF. That is what I assumed as well at first maybe it was switching between wired and wireless. Verifying what connection they are using on LAN.

They way I read the syslog message is it is not liking a param it returned. I have captures so going to look at the 200ok. You can see this is cseq 105 so obviously the first couple were ok. So I need to look at what is different between a bad and good 200ok.