cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1901
Views
5
Helpful
9
Replies

Random SIP trunk calls getting rejected by UC540

alove
Level 1
Level 1

Hello,

I have a strange issue with a customer's UC540 - some calls are getting rejected from the UC - not all.  We are using BabyTEL as the ITSP - are using them at a few other sites with no problems.  We have a Cisco pro support call opened and they are looking but I wanted to find out if anyone else has any ideas. 

Cisco support thinks we may be maxing out the max sessions to CUE (6 on the UC540) but apparently there is nothing in CCA or CLI that will show how many connections are currently connected to CUE and I am doubtful we are reaching that limit as I can recreate the issue with only a few calls at a time.

Here is the service unavailabe message we are getting - reason cause is 41 - Temporary failure.  I would say 30% of all calls are currently being rejected - always the same message.

04102: Jan  4 13:22:23.291: //99659/39FCADB5A1F9/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 503 Service Unavailable

Via: SIP/2.0/UDP 204.101.5.68:5065;branch=z9hG4bK-d87543-3f535f01771059350b76-1-

cHAwNDZhODIxMzMwNjNjMzBhNTllZQ..-d87543-

From: "LTS"<sip:14168409865@sip.babytel.ca>;tag=29327550

To: <sip:4167443344@sip.babytel.ca>;tag=D71802E8-21D

Date: Wed, 04 Jan 2012 18:22:23 GMT

Call-ID: bd6ef56cda498e1d52a60461c9ae524f

Timestamp: 1325701493

CSeq: 283978178 INVITE

Allow-Events: telephone-event

Server: Cisco-SIPGateway/IOS-12.x

Reason: Q.850;cause=41

Content-Length: 0

Cisco has asked us to switch the DID from  AA to a direct extension and try and recreate the issue to ensure the issue is in fact CUE is the issue and not something else - we will do it later tonight once the customer has left for the day.  Software Packs are all up to date.

Any ideas would be greatly appreciated.

Thanks

Andrew Love

LTS

9 Replies 9

craig.corbett
Level 2
Level 2

I had a similar issue a while back. Turned out that the trunk provider at times were using IP addresses that were unknown to me, I spoke to them and they gave additional IP information so I could configure them as ‘trusted’ on the US500. I presume Cisco support may have ruled this out.

What I suggest is running a ‘debug CCSIP all’ compare a failed call with a working call and try to identify the TSP IP addresses and make sure they are the same.

HTH.

Please post the output of debug CCSIP all like suggested by Craig.

Regards.

HI Craig/Daniele,

Thanks for the reply, we spent a fair amount of time troubleshooting and looking at debugs with Cisco - when we actually changed the DID to blast groups we had no issue - so we have determined it is not a provider issue, the only time the issue appears is when an AA or Voicemail is called which of course leads us to believe it is a CUE issue. The weird part is that the issue appeared to be getting worse and worse as time went on to where CUE could only handle 1 connection at a time (one call in AA at a time).

As a last step we reloaded CUE last night - even though diagnostics said all was fine - and everything went back to normal.  Cisco support spent 4 hours looking at the system/logs and got nowhere - they have escalated and should get back to us today for recommended next steps - we are monitoring for more service unavailable errors (none today so far) but we believe we may have to RMA the unit if it happens again.

Thanks

Andrew

These are quite "normal" Cisco bugs, memory leaks or data structure corruption, that can be recovered only with a reload.

Dealing with ciscos, reload has to be tried quite early during torublehoot, if one cares about maintaning services.

They are for sure, not hardware issues.

For this kind of issue is very difficult to have Cisco reproduce and fix. By the way you haven;t even mentioned which CUE version you are running.

And the commands to know about how many sessiosn to where are in CLI, but no woder that any CCA oriented technician won;t know.

Hi Andrew,

There is a known problems with current CUE revisions of the SIP trunk not clearing down when it is a pure SIP call, the issue is not reproducible when it is say an ISDN/PRI service talking to the CUE, but can be reproduced when it is a SIP trunk service.

What has been discovered though over time is that the CUE runs out of resources, and sessions lockup, and then codec renegotiations fail as well, which has other far reaching consequences. It has been ongoing and I am sure there are quite a few people who are interested in this problem ending, but the issue here is that it does not happen to everyone.

Are you running on Software Pack 8.2? This should have the latest CUE which as I understand it has better resource management, but I have noticed though in previous installs the DB can get corrupted much easier then previous versions... Don't know why this is but it is just something that I have noticed.

There is one trick to this though have all the calls come into an extension, dummy one if you will, and have an immediate call forward on it to go to the AA, the problem has not been easily reproducible when done this way and has worked for others when applied

Just a though for you to look into.

Cheers,

David.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

Hi David,

Thanks for the info, most appreciated. We are running Software Pack 8.2 - CUE 8.0.6.

We were trying to figure out what is different about this site that is creating this issue and you nailed it, only one of our high call volume customers that are configured to go directly to AA using SIP.....I will try your work around to send to an extension and then forward to AA this weekend to see if stabilizes CUE.

Thanks again.

Andrew

Hi Andrew,

Can you please let us know how you got along with it, and if resolved what ended up resolving it

Cheers,

David.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

Hi David,

I made the change you suggested this weekend (send incoming DID to floating extension which forwards to AA), time will tell, no complaints so far.  I am also following up with Cisco support.  Will update in a few days.

Thanks,

Andrew

Hi Andrew,

Appreciate you taking the time to update us

I hope it all works out for you...

Cheers,

David.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *