3.1(1) Dialing Delays

[silaghi]

Implementation: MCS7835 running CCM 3.1(1) using 7960s & AS5300/H.323 gateway.

Issue: Intermittent dialing delays when dialing local numbers.

Issue Description: When the delay is occuring, you dial local number (e.g., 94531042) the number sits on the screen for 10 seconds without ever changing display from [94531042_] to [TO: 94531042]; then drops the call.

When the delay is not occuring, the screen changes from [94531042_] to [TO: 95431042] almost immediately.

Symptom conclusion: It seems that despite the route or translation patterns, RFs, RLs, DDI, etc.. the symptoms persist to occur intermittently & at random with any local number dialed.

Suspicions: Possible compatibility issue between AS5300/H.323 Gateway & CCM 3.1(1)?

CCM 3.0(9) notable comparisons: In same network, on another MCS7835 running 3.0(9) using same AS5300 and identicle dialing plans, 7960 phones almost instantly show [To: 94531042] on screen, and dial with minimal delays every time.

AS5300 Gateway config: 12.1(5)XM, VCW 8.06, DSPW 3.5.122

Is anyone familiar with such issues. Please post a response.

We can provide further details as necessary. Thank you,

Rob Silaghi

NetCubed Corporation

[dgoodwin]

Rob, it's almost certainly a CallManager issue and not anything with the AS5300.

You would want to turn on DETAILED tracing for CCM and capture a trace of the problem occurring and then either attempt to read it yourself or send it to TAC with an open case.

[silaghi]

DG-

Thanks for your response. I have a TAC case open & have reviewed several traces (successful calls & failed). Do not see any obvious explanations or variations in the traces for what is happening.

This did catch our eye though:

PatternType=National

PotentialMatches=NoPotentialMatchesExist

This NoPotentialMatchesExist is showing on both successful & failed calls so doesn't appear to be the issue.

Additionally, on failed calls it shows that the RL was identified, the gateway device was identified, & then right after identifying gateway device it says:

[extending call to device]

The call then fails. Then there are no more messages in the trace. The very next message is a InboundStim (keepalive) messages between phone & ccm.

TAC has yet to respond to my open case (2 hours old) & I have a 3.1 customer upgrade scheduled for 6pm eastern. We believe that we have reviewed all published caveats but if we can't resolve this problem we are not prepared to deploy 3.1 with these local dialing issues.

Any further guidance you could provide would be very appreciated.

Thanks again,

Rob

[dgoodwin]

I don't know of any bugs or other caveats off the top of my head that would have anything to do with this. That's not to say that it does not exist, I just don't know about any.

Let's see what TAC has to say.

[silaghi]

Word: "don't get too buried in the CCM application & abandon the basics".

We have made some progress. We have a physical problem. AS5300 has (2) PRIs coming into it from PSTN. (1) of which is taking massive errors (& guess what, no network management at this customer).

Nevertheless, obviously the problem is not due to CCM 3.1. The (2) pots 9T dial peers on the AS5300 are in tandem so we would only get these issues when we happened to be hitting the dial peer associated with the lame PRI circuit.

Shut it down & now all is well.

However, there is still one remaining issue.

There is a good PRI. We are now researching who is "giving up" on the call & why it's not rerouting to the good PRI.

Any thoughts on call setup timeout values on CCM? I'm hopeful that we can handle the issue (timeout/reroute) on the AS5300 config but for MGCP gateways shouldn't all manipulation be done on CCM?

Appreciate any additional input.

Thanks again,

Rob

[dgoodwin]

I'm not sure if there are any timers you can adjust on the CM side for this or not. With MGCP gateways, yes.

We might need to look at a CCM trace to see how (if at all) the AS5300 is responding when it is experiencing this problem. That could affect what we can do if anything on the CM side