sip call failure

[802326933]

We have a problem were we have a cluster of 4 cxi 11 controllers and they decided to stop processing SIP calls! On looking at the logs "sip stat all" the number of "Non-Auth Calls" had reached nearly 60,000 - when this was cleared using "sip stat clear" to reset the counter to 0 it all burst into life again. The number of calls is gradually creeping up so wonder if this will happen again. Any ideas?

[martyn]

So this is for all calls coming from the outside world in or out of the system and not between the controllers?

What software release are the systems running?

[LoopyLou]

I would say it is going to happen again. I would investigate these non authorized calls.

[ralph]

I just heard that there is a memory leak that will cause all SIP trunks to fail in version 5.0.
The thought is this should generate an alarm and do a resource recovery but may not be.

Ralph

[802326933]

the SIP link is between a MCD running 5.0 SP1 and a Cisco call manager.

[802326933]

Ralph
Do you have any more info re this "memory leak" as we are running at 5.0?

Chris

[ralph]

No.  Sorry I don't.   I heard it brought up by another dealer who was having issues with the problem.

Ralph

[LoopyLou]

Not aware of the issue in any particular load of software. Have you investigated what is causing the Non-Auth calls? Maybe it thinks its being hacked and shuts down processing for a reason. Just a guess.

[x-man]

If its the same as BRI problems then enough faults will cause a critical alarm which shuts that bit down. As noted clearing the stats brings it back for a bit.

[Dutch]

Looking at the version an upgrade to MCD 5.0 SP2 PR2 might prove useful too since we experienced weird stuff on SIP reinvites with silent monitoring on MCD5.0 SP1 which an upgrade resolved. This is if you are sure you used the correct trunk settings to connect to the call manager and it's the best first step to take I think.

If that doesnt resolve them, you could also investigate the calls themselves. I have no idea if something might be visible on the SIP calls themselves for Un-Auth Calls. Although I am guessing they could show SIP/2.0 401 Unauthorized

To be sure it might be an idea to run a capture in wireshark.

If the calls happen frequently (assuming very frequently) maybe something will be visible with wireshark. As far as I know you can log onto the Mitel where the trunk is configured using PuTTY to the RTC IP on port 2002 and do StartWS to start a capture on the Mitel. StopWS will stop it. Nice thing is it doesnt incl. the RTP stream so the files won't be as big. Don't keep it running too long (depending on your cph).

After that FTP to the mitel and retrieve the .pcap file from the /vmail directory.

Or make a span port on the port the Mitel is connected to and do a trace on that and filter on SIP.

Making assumptions but if you indeed see SIP2.0/401 Unauthorized well from what I know it usually points to trunk configuration settings where reinvites or registration goes wrong.

TL:DR Upgrade and if it doesnt work run a capture

Dutch

[martyn]

To be sure it might be an idea to run a capture in wireshark.

If the calls happen frequently (assuming very frequently) maybe something will be visible with wireshark. As far as I know you can log onto the Mitel where the trunk is configured using PuTTY to the RTC IP on port 2002 and do StartWS to start a capture on the Mitel. StopWS will stop it. Nice thing is it doesnt incl. the RTP stream so the files won't be as big. Don't keep it running too long (depending on your cph).

After that FTP to the mitel and retrieve the .pcap file from the /vmail directory.

A much easier way in 5 is just to do SIP TCPDUMP ON from the maintenance command and then once done SIP TCPDUMP OFF and then collect the pcap file from the vmail directory via FTP.

[Dutch]

Thanks nice one Martyn. Didn't know that one

[802326933]

Thank you everyone, will try next week and see what shows up. (at the moment clearing the stats for now!)

Chris