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.
It sounds like somebody has create a pattern that is marked as onnet that starts with a 9. If you are familiar with SQL query analyzer. Run this query on the latest ccm database and it will tell you what the culprit is:
select numplan.dnorpattern, typenetworklocation.name, typepatternusage.name
from numplan, typenetworklocation, typepatternusage
where numplan.dnorpattern like '9%' and
This query assumes 9 is your accesscode and does not check for message waiting on and off numbers but should check for everything else.
Hope this helps,
I ran the query on the ccm database and this was the result. It does not look like there is a pattern for
dnorpattern name name
9.1976XXXX OffNet Route
911 OffNet Route
9.1631XXXXXXX OffNet Route
9.976XXXX OffNet Route
9.1718XXXXXXX OffNet Route
9.1212XXXXXXX OffNet Route
9.18XXXXXXXXX OffNet Route
9.1[2-9]XXXXXXXXX OffNet Route
9.1646XXXXXXX OffNet Route
9.18887000400 OffNet Route
9.1518XXXXXXX OffNet Route
9.1917XXXXXXX OffNet Route
9.911 OffNet Route
9.1XXX976XXXX OffNet Route
9.1900XXXXXXX OffNet Route
9.[2-9]XXXXXX OffNet Route
(16 row(s) affected)
What are your messaging waiting on and off DN's? Another thing this query does not account for are dn's or route patterns that start with an X, N, or @. Also keep in mind that you may have a pattern that looks something like this [5-9]xxx. That would also cause delayed dialtone if any of these dn's or patterns were marked as onnet. You can modify the query to look for things like this. Where is has dnorpattern like '9%'. Just replace the 9 with X, N, @, or [. Let me know what you find.
The message waiting on and off numbers are in service -> service parameters for cisco call manager. Message waiting on DN and Message waiting off dn. Let me know what they are.
I replace the '9%' with all of the other characters, number and letters you suggested and all of the queries came back with nothing. It seems like there is the simplest thing causing this delay.
Check the 911 pattern to see if you have the "Provide Outside Dial Tone" checkbox checked. Check this box temporarily to see if the problem disappears. If this was not checked, the people dialing 9.1! will not get dial tone until the third digit is dialed because there is a potential match of pattern "911" which is not configured to provide secondary dial tone.
You can see by the query I had him run that outside dialtone is check because when we ran the query we got back offnet for that instance. This means that he has provide outside dialtone checked.
I checked both of my 911 patterns they are 911 and 9.911 and they both have the provide outside dial tone box checked. Could this be the problem i have some patterns being blocked and the provide outside dial tone check box is cleared. They are 9.976XXXX 9.1XXX976XXXX these two patterns do not have the box checked. I am on to something?
Yes you could be. Did you see those when you ran the sql query I gave you. It looked to me like all of them said offnet. Like I said before for the query I gave you offnet means provide secondary dail tone is checked and onnet means that it is not checked.
To answer you question from before I did put the % sign after the character,letter or number. I am going to try checking off the provide outside dial tone boxes on those route patterns on Monday, I will not have access to the cm until then. Thanks for your help.
I went and checked off the provide outside dial tone box on all both of the 976 patterns, 9.976XXXX 9.1XXX976XXXX and now i am back to getting outside dial tone after i dial lets say 916 then i get outside dial tone.
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.
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.
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.
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.
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.
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.
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.