UC320 Reload reason "SIP Triggered"

[Matthew Needs]

Hi All,

Can I ask if there is a list of explanations for random UC320 reloads? I couldnt see anything in the manual. We have a customer who has experienced a few "SIP triggered" reloads as per the reload reason on their SPA handsets.. Id like a more detailed explanation as to what could have caused them? Some are obvious like "VLAN change".. Points to CDP or LLDP issues. But SIP Triggered is not so obvious to me..

For this particular customer I have notice that under Config -> Ports and Trunks -> Outbound Trunks there where SIP trunks selected that may not be in service right now. The SIP trunks where configured as an overflow for the customers primary four channels of ISDN on a Mediatrix box. I wonder if when the customer had hit channel 5 the UC tried the SIP but crashed due to them being down for some reason? Bit of a hunch really but does this sound feasable?..

I have unticked the SIP trunks from Outbound Trunks and the crash problem seems to have stopped? However, we are monitoring things just in case..

Thanks in advance for any input.

Matt

[rbordner]

Matt,

What version of firmware is the UC320W running?  In version 2.2.2(1) the reloads have been reduced when a configuration changed is applied.

Also please look at Status -> Devices and look at System Uptime and System OS Uptime counters and match the counter to any of the SIP Triggered reload reasons.

In addition when is the Automatic Maintenance window configured?  This will also cause the system to reload.

Finally are the phones rebooting with "VLAN Change" reason codes?  There is  a PMF to disable LLDP on the SPA phones to avoid this issue.

https://supportforums.cisco.com/docs/DOC-16301

Regards,

Randy

[Matthew Needs]

Hi Randy,

Thanks for the reply. Answers to your questions below.

The reloads seem to be quite random.. My apologies, I should have made it clear but the problem seems to be the SPA handsets rebooting not the whole system. This happens without config changes and we are already running 2.2.1(1).

The "OS Uptime" is stable but the "System uptime" is resetting after the SPA reload.

System maintenance is set to 2am Sunday. I understand that only causes the one reload correct?

The LLDP off PMF is already applied.. I was just using the "VLAN Change" reload reason as another example really.. We aren't seeing this particular reload on site.. I just wondered if there was a doc listing the reload reasons and possible causes?

The UC has been stable for 19hrs now so we'll see how we get on today when it's in full use..

Kind Regards

Matt

[Matthew Needs]

OK - I've seen another reload this morning.. This looks like a bug to me..

The system is setup for an AA front end.. With four BRI channels via Mediatrix. The system is rebooting with a S111 reboot reason? And it looks like it happens after a T38 fax request? Could be a coincidence until I see another crash..

May 17 09:34:24 UC320W user.debug voice:

SAA_DBG:<<<

May 17 09:34:24 UC320W user.debug voice: [11:0]AAA:RTP Tx Up (pt=8->011010ac:16456, ptime=240)

May 17 09:34:24 UC320W user.debug voice: [0:0]RTP Rx 1st PKT @16460(3)

May 17 09:34:24 UC320W user.debug voice: initPlayPromptFromFile 0 6 8

May 17 09:34:25 UC320W user.debug voice: ++++ signaling events: 69 622 41d3e574

May 17 09:34:25 UC320W user.debug voice: [11:0]CC:ALLOC T38 0

May 17 09:34:25 UC320W user.debug voice: SIP:Peer Request T38

May 17 09:34:25 UC320W user.debug voice: [11:0]AAA:RTP Tx Dn

May 17 09:34:25 UC320W user.debug voice: [11:0]AAA:RTP Rx Dn

May 17 09:34:25 UC320W user.debug voice: System going down with reboot reason: S111

May 17 09:34:25 UC320W user.warn kernel: Closing phone channel-0

May 17 09:34:25 UC320W user.warn kernel: Closing phone channel-1

May 17 09:34:25 UC320W user.warn kernel: Closing phone channel-2

May 17 09:34:25 UC320W user.warn kernel: Closing phone channel-3

May 17 09:34:25 UC320W user.warn kernel: Closing phone channel-4

May 17 09:34:25 UC320W user.warn kernel: Closing pcm device

May 17 09:34:26 UC320W user.debug kernel: sysevt_comm_sendto: (60, rc)=>

May 17 09:34:27 UC320W user.debug kernel: sysevt_comm_sendto: (60, rc)=>

May 17 09:34:28 UC320W user.warn kernel: >>update group 224.168.168.168 cache vif range as 12~13

May 17 09:34:34 UC320W user.warn kernel: Opening phone channel-0

May 17 09:34:34 UC320W user.warn kernel: PHONE_PLAY_START

May 17 09:34:34 UC320W user.warn kernel: CPLD indication triggered -

[Matthew Needs]

We have now raised this issue with SBSC TAC. I have now seen the T38 Fax inbound happen a few times followed by a reload..  It's coming in via the SIP trunks which would explain the "SIP Triggered" reload reason. This happens even though we have a divert on the SIP lines. It looks like faxes arent being diverted by the SIP provider.

I have deleted the SIP trunks for now as a workaround to stablise the system. We will continue to monitor things...

Will keep the forum posted.

Matt

[rbordner]

Matt,

Please PM me the case number once the supporty team provides it to you.  I will open a defect on the S111 reboot reason code you experienced and assign the case number to the defect.

Thanks,

Randy

[Matthew Needs]

Hi Randy,

I've sent you the details by private message..

An interesting bit of info for you to note is that since we have disabled the SIP trunks the SPA phones seem to have stopped resetting? Even though the UC is still indicating a reset via the "System Uptime" output?? Very strange.. My guess is that when we re-enable the SIP and fire a T38 fax call at the SIP trunks the SPA's would reset.. It seems there is perhaps something different in the way the Mediatrix/UC deals with the T38 fax calls?

Thanks

Matt

[Matthew Needs]

OK - Just to update this thread.. Disabling the SIP trunks was a red herring. The UC was still reloading the IPT's with reload reason S111 with only the Mediatrix connected. Bug ID CSCua00176 has now been created by CCO for this issue. We have found that disabling the customers AA front end stopped the SPA's from reloading. Another noteworthy piece of info is that by default, a fax call directed via Gamma SIP trunks or a Mediatrix box is converted to T38. This can be disabled by contacting your SIP provider or going here on the Mediatrix box.

In the Telephony -> CODECS section -> Disable T38

As it turned out, our customer needed to temporarily transfer any rogue incoming fax calls until various service provider number ports had taken place. We had to disable the T38 conversion feature as the UC320/SPA's dont recognize T38 and drop the calls before it can be transferred by the user to the FXS (FAX) port. By disabling T38 you can effectively "fool" the UC320 into thinking the fax call is just another voice call. And therefore transfer the call onwards.

I wonder if disabling T38 would also be a workaround for the SIP T38 reload issue if the AA where enabled? We are yet to test this but just an idea if anyone is struggling out there.. A UC320 fix release is in the pipeline according to Cisco.

It would be nice if the AA was clever enough to recognise a fax call and pass it onto the relevant FXS port? Just an idea Cisco..

My best

Matt