"Resource unavailable" over a SIP Trunk in CCM 5.1 for second call

[Ion Cristian Radescu]

Hi all,

I have a strange problem over a SIP trunk. I configured a SIP trunk between CCM 5.1 and a HiPath 3000 V7.0.

When I am calling analog phones from Cisco Ip Phones first call is ok but second call ring and receive busy when I want to answer. I receive "Reason: Q.850;cause=47" for the second call. I have not problems with MTP. I configured hardware MTPs for this trunk. I am monitoring Xcoders, I saw when first call invoked xcoder, I saw I have enough xcoders available, I saw CCM allocated MTP for second call in traces("mMtpAllocated=1") but after that I had a bye message from CCM.

I attached the relevant debug.

Has anybody an ideea about what could be the cause for this?

Thanks,

Cristian

[Nicholas Matthews]

Hi Cristian,

It's not very clear what's going on from the debugs. The SIP messaging seems to indicate that a call is being put on hold. The traces also don't seem complete - maybe some of the other trace options are not enabled.

-nick

[Ion Cristian Radescu]

Hi Nick,

Thanks for your time.

Please find attached full debug with some explanations at the beginning of the file.

Debug was activated at detailed level for SIP and Media Manager on CCM.

At that moment we tested two calls by putting first one on hold and accepting the second call.

Many thanks,

Cristian

[Nicholas Matthews]

Hi Cristian,

Can't tell you for certain what's going on here. It's either one of two things:

1) CUCM isn't happy about the 0.0.0.0 address it's receiving

2) CUCM has a problem with the MTP allocation.

What is the value of the service parameter regarding 'disconnect call on MTP allocation failure'?

-nick

[Ion Cristian Radescu]

Hi Nick,

1. Why would be CCM unhappy about 0.0.0.0 address only for the second call?

2. I suspect MTP allocation problem too, but RTMT told me I have enough hardware xcoders(23) available. Tommorow I'll do update at 5.1.3f because I saw some bugs about SIP and MTP allocation/deallocation on previous versions.

The service parameter is on False.

Thank you for your time once again,

Cristian

[Nicholas Matthews]

Hi Cristian,

I say that because for an initial call, it would not be expected for the other gateway to send a 0.0.0.0 address. This can also indicate a media failure by the other end, in some situations.

-nick