Re: Secondary dial tone - Page 2

mreilly · ‎03-27-2002

When a user dials 9 to get out there is no secondary dial tone. They get the dial tone after they dial the third number. I have multiple route patterns, so it seems as if you only get secondary dial tone after the pattern finds a unique number. Example route patterns (9.1212XXXX 9.1631XXXX 9.718XXXX) We did not have this problem until the upgrade to 3.1.3a call manager. I have checked with my other sites and they have their patterns configured the same way.

mimckee · ‎04-01-2002

You want provide outside dial tone checked on any pattern that starts with a 9 with is your access code.

Thank you,

-Mckee

SEAN NILSEN · ‎04-03-2002

the 9.1xxx pattern was your case for the 4th digit providing the explicit match: 9.1xxx will override a 9.1212 until the last 2 is pressed.

You have to have another pattern hanging out there that is causing a conflict on digit 3, like you have a 9.1618XXXXXXX pattern and a 9.1X[2-9]XXXXXXXX, but you get the idea.

I would go through each pattern again, blocked and routed, to verify that you enable dialtone for all of them.

The other thing to check is to list all of your patters in CCMAdmin and use SQL Enterprise manager to verify that the two show the same translations. I have had patterns get "stuck" (improperly removed by CCMAdmin) in the database and that can cause problems.

Another thing to try would be to create a new set of Partitions and Calling Search spaces and with a test phone, assign route patterns one at a time until the problem occurs. That is kind of that long way around but given that you can't locate the issue, it might be your best shot at finding it.

mreilly · ‎04-03-2002

All of my patterns including the ones that are being blocked have the provide outside dial tone checked. I am working with tac and their suggestion was to try a 9.@ but in speaking with another Cisco se they have the same exact route patterns on their cm and as soon as they hit 9 there is secondary dial tone. I am looking in the wrong place? Should i upgrade the version on my 6608 blade. Is there another test i can run.

mimckee · ‎04-03-2002

I am not sure why you are still getting secondary dial tone. I found the case number that you are working on. If you can provide terminal service to the TAC engineer you can tell them to contact me and I will get in and look and see if I can find the problem. I don't see how upgrading the code on the 6608 is going to help. This is a callmanager logic issue. We need to find out what is starting with a 9 that is marked as an onnet pattern.

Thank you,

-Mckee

mreilly · ‎04-03-2002

Mckee,

Since school is not in session I do have some flexibility this week. Do you think it would be beneficial for me to take out the 9. patterns and then add them back in one by one and see what that shows. As for terminal services, I unfortunately do not have ts running and there is no hole in the firewall so that is out. I did do screen prints of all the route patterns for the engineer.

mimckee · ‎04-04-2002

I guess you can try what you want. I don't see how that would help. There has to be something in the numplan the we are overlapping with that is marked as onnet. Did you ever check the message waiting on and off DNs in the service parameters for callmanager. As for the pard dn that is in the numplan so we should get that back from the query we ran.

Thank you,

-Mckee

mreilly · ‎04-04-2002

The problem is solved. It turns out the way we set this up I had the patterns that we being blocked with the provide outside dial tone box unchecked. I think I asked the tac engineer if this should be checked, but anyway. I went through and checked the provide outside box on all of my blocked route patterns and then tried making a call. I was provided secondary dial tone as soon as i hit 9. I want to thank everyone for their help.

mimckee · ‎04-04-2002

I am glad you got it fixed. Sorry it took so long. I tried to be helpful.

Thank you,

-Mckee

SEAN NILSEN · ‎04-03-2002

Have you also looked at Park DN's and other on-net device type numbers? How about going into the Dial Plan report and looking at the whole list of DN's and patterns on the system. Could be there is something you are overlooking somewhere. Any wildcard patterns: 9.@ 9.! 9.x... will cause a pattern to not match explicitly. There HAS to be one either listed there or it has gotten locked in you SQL database.

If you are familiar with SQL Enterprise Manager/Query Analyzer, you can pull up the DialPlan and look there to see if there is something "stuck" that is not visible to the CCM Admin interface.