No dialtone after pressing access code for an outside PSTN line

[pbarman]

I have a route-pattern 9.@, and 'provide outside dialtone' is checked in the route-pattern config in the CCM. So I get an outside dialtone, when I press 9(the access code). One fine morning, I press 9 and get no outside dialtone, I press the next digit(any) and then get the outside dialtone. ????? Dialing resumes and I can connect to PSTN fine, and make calls.

After some 4-5 hours it was solved by itself (no manual changes made), ie, normal behaviour of getting dialtone after pressing a 9 for an ouside line resumed.

Going thru the trace file I found that when the problem occured, the Call Manager would interpret 9 as a Internal PotentialMatchExists, when it should interpret as ExclusivelyOffnetPotentialMatchExists. After 4-5 hrs when it came up by itself, now the trace file output shows that the Call Manager interprets 9 as an ExclusivelyOffnetPotentialMatchExists (desired behaviour).

No idea for the abnormal behaviour for the sudden short duration, when I have no internal extensions starting with a 9. I use 9 only for dialing a outside line. Whether its a new bug, or ???

I run CCM 3.1(2c).

Can anyone guess a reason for it?

[mmellet]

Sounds like a bug but it might be difficult to trace until it comes back. I would open a case with Cisco if it does it again. I couldn’t find anything on bugtracker.

[cristianmunoz]

my suggestion

test with 9XXXXXXX, where the X is the amount of I number dialed

luck

[mimckee]

I have not seen any problems like this with 3.1(2c) are you sure someone did not add a translation pattern or some extension that started with a 9 and then removed it?

Thank you,

[Tom Dillon]

If you have multiple 9.@ or 9.anything route patterns and one of them does not have the outside dialtone checked, then it can cause delayed outside dialtone for all your 9. route patterns.

I added a new route pattern to my 3.1(2c) system and forgot to check the outside dialtone. Then all my calls would not get outside dialtone until several digits were entered after the 9.

I have no idea why your system appears to be self-healing. Maybe Cisco is testing EICRP (Enhanced InterCluster Routing Protocol) :-)

[pbarman]

there's no translation pattern, no route patterns with a 9 other than 9.@, and that has provide outside dialtone checked......

the mystery still exists!

[rlyons]

Hello Partha,

This sounds like a great mystery to which I have no answer. One thing you have not mentioned is partitions and calling search spaces. Have there been any changes in these parameters? It seems, from what you said, that even if there had been there were no DN's that might have caused a problem. Just thought I would ask though.

Bob

[pbarman]

There were no changes to partitions and calling search spaces, and no conflicting DNs. Sounds crazy, but could it happen due to lack of database synchronization due to high network traffic at the particular moment? The last reason I could guess.