CCM 4.2 strange problem related to T302

[Clifford McGlamry]

Customer has an old CCM 4.2 cluster.  Recently, they made a change and installed a new PRI from another carrier, and moved service to it.  The old carrier was configured as MGCP with NI2.  The new circuit, for reasons that make no sense and baffle all reason, was delivered from the carrier requiring a 4ESS emulation with MEGACOM.  This forced the gateway to be reconfigured as H323 to support this.

Ever since this change, we are having delay problems with outbound dialing.  Route patterns have not changed.

In checking the route pattern, there is no overlap.

In debugging the H323 gateway, the call is fired off instantly when the call comes in, so there's not a delay there.

We cranked down the T302 timer to 5 seconds, but we are still getting a 15 second delay.

Customer doesn't have a current support contract on this (and won't get one).  They also refuse to upgrade.

I'm scratching my head on this one.  I know several ways to fix it, but they are unwilling to force the carrier to respond or upgrade.

Any ideas?  I can't find a bug on this (though I did look).

Cliff

[paolo bevilacqua]

You could have sent a debug isdn q931 to decrease the crystall ball factor ..

However, if you don't have it, try adding "isdn sending-complete" under interface.

Note for you MGCP diehards, my understanding is that megacom is just another name for the same stuff, and MGCP with switch National would work just fine.

[Clifford McGlamry]

I can get the q931 trace.  Problem is it doesn't show anything unusual.  The q931 trace starts immediately when the dial peer is hit.  But the trace doesn't even start to fire for 15 seconds after the last digit was hit on the phone.  It looks like a normal Q931 trace.  But I will add the command and let you know.

If we could have gotten MGCP with switch national, we'd have used that.  However the carrier claims that we HAD to use 4ESS with Megacom.  This was unexpected and thrown at us at the last minute.  We only found out they'd change the emulation when the national (which the port was already configured for) wouldn't work.

Don't get me wrong Paolo, I'm not trying to force the protocol to anything (MGCP, H323, or SIP).  But it was working under MGCP and now it's having issues that appear to be occurring with CCM now that it was changed.  The customer is doing several things that make it harder, but I'm really looking to find out if anyone has any troubleshooting ideas here.  We've gone through route patterns, set the priority to urgent (which intrestingly did fix things for a few hours, and then the problem came back), etc.  Im working on it from 3000 miles away, and the customer has no one on site that's capable of doing much more than turning things on and off.

Cliff

[paolo bevilacqua]

You did not specified that the delay was in CM. If really so, there is no point in investigating the router. However, there is a "isdn nsf-service mgacom" config you would need there.

In my experience, "carriers" often make wrong claims, and I still have to see evidence for which (if not national), a 4ess switch type should not work with mgcp and megacom.

[Clifford McGlamry]

Sorry.  It's a complex problem, and I missed explaining about that moving part.

In this particular case, we could not get the megacom option to "stick" with 4ESS under MGCP.  And we did test it (and it wouldn't work) without it.

Not sure what you'd like to see, but I'd be happy to see if they'd let me run some tests if there is something specific around that issue (which is admittedly different).

Cliff

[paolo bevilacqua]

May be a CM reload? Or some kind of CM trace could tell you where the call is hunting around for 15 secs before hitting the GW.

[Clifford McGlamry]

Ok.  I guess we'll have to look that way again.

I'm thinking we may need to reload, but that's particularly problematic for this customer.

I'll let you know.  Thanks!