<div>I did uncheck all "provide dial tone" on all route patterns starting with 8. Worked like a charm -> no secondary dial tone. Restarted the entire cluster then, checked all boxes again and restarted the cluster again. Still, secondary dial tone was in the wrong place.
</div>
<div> </div>
<div>Then ran a query:</div>
<div> </div>
<div>select dnorpattern, outsidedialtone<br>from numplan<br>where dnorpattern like '8%' and outsidedialtone = '0'<br> </div>
<div>As I suspected, no results.</div>
<div> </div>
<div>1 day later, I am about to download the newest release (4.1(3)sr6)</div>
<div>and start upgrading but guess what, the secondary dial tone is in the right place. Very odd.</div>
<div>I am not sure what to think of it. </div>
<div>Cisco folks, is it an isolated incident (besides Paul's and Joel's) or is it a common occurence? Maybe I should disable the secondary dial tone all together so users won't be confused as much next time? I am just looking for some suggestions.
</div>
<div> </div>
<div>Thank you all for help. You guys are great!</div>
<div><br> </div>
<div><br> </div>
<div class="gmail_quote">On Dec 31, 2007 11:52 AM, Ryan Ratliff <<a href="mailto:rratliff@cisco.com">rratliff@cisco.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">4.1(3)SR6 should be out and does have the fix.<br><font color="#888888"><br>-Ryan<br></font>
<div>
<div></div>
<div class="Wj3C7c"><br>On Dec 31, 2007, at 11:33 AM, Jason Burns wrote:<br><br>To add a bit to Ryan's email:<br><br>I always use the following query in 4.X (either query analyzer or<br>enterprise manager with your highest numbered CCM030X DB selected) to
<br>see what might not have "Provide Outside Dialtone" checked.<br><br>select dnorpattern, outsidedialtone<br>from numplan<br>where dnorpattern like '8%' and outsidedialtone = '0'<br><br><br>If that doesn't work...
<br><br>It's also possible that the forwarding intercept for that 8XXXX is<br>still stuck in the database and is causing CCM to hold off on<br>providing the outside dialtone because CCM thinks the number still<br>exists.
<br><br>This wouldn't be visible in the previous query, but could be<br>identified in the CCM traces.<br><br>CSCsj30852 - CM 4.x - Inactive or Unassigned DN with CFA still<br>forwards calls<br><br>Which was fixed in an Engineering Special (no SR released for it yet)
<br><br>It's more likely an overlapping pattern somewhere without the<br>checkbox, but if after more searching you can't find the offending<br>pattern you might want to turn to the traces / TAC.<br><br>Thanks,<br>
Jason Burns<br><br><br>On 12/31/2007 10:27 AM, Ryan Ratliff wrote:<br>> Looks like you are on the right track so far in identifying the<br>> numbers conflicting with the route pattern. Secondary (outside)<br>> dial tone is played only when all potential matches for a dialed
<br>> string have the flag set to play outside dialtone. Since you were<br>> receiving it after dialing 8[2-9] and 81[2-9] this would tell me<br>> you have a pattern beginning with 81 that does not have the flag
<br>> set to play outside dialtone. -Ryan<br>> On Dec 30, 2007, at 11:58 AM, Lelio Fulgenzi wrote:<br>> By 'unused' I meant 'unassigned'.<br>> Route Plan > Route Plan Report > Find Unassigned DN (from drop down).
<br>> This will give you a list of DNs you have deleted, but not purged<br>> from the system.<br>> Just wanted to be clear, some people miss this step.<br>><br>> ----------------------------------------------------------------------
<br>> ----------<br>> Lelio Fulgenzi, B.A.<br>> Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1<br>> (519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)<br>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
<br>> "Life expectancy would grow by leaps and bounds if green vegetables<br>> smelled as good as bacon."<br>> Doug Larson<br>> ----- Original Message -----<br>> *From:* Peter Ejmont <mailto:<a href="mailto:pejmont@gmail.com">
pejmont@gmail.com</a>><br>> *To:* Lelio Fulgenzi <mailto:<a href="mailto:lelio@uoguelph.ca">lelio@uoguelph.ca</a>><br>> *Cc:* <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>
<mailto:<a href="mailto:cisco-">cisco-</a><br>> <a href="mailto:voip@puck.nether.net">voip@puck.nether.net</a>><br>> *Sent:* Sunday, December 30, 2007 5:34 AM<br>> *Subject:* Re: [cisco-voip] secondary dial tone problems
<br>> All unused numbers starting with 8 were deleted to begin with.<br>> Then, the entire cluster was restarted.<br>> Thanks,<br>> Peter<br>> On Dec 29, 2007 11:11 PM, Lelio Fulgenzi <
<a href="mailto:lelio@uoguelph.ca">lelio@uoguelph.ca</a><br>> <mailto:<a href="mailto:lelio@uoguelph.ca">lelio@uoguelph.ca</a>>> wrote:<br>> oh boy. interesting to say the least.<br>> have you tried deleting the number from the
<br>> "unused" numbers?<br>> in route plan report select unused DNs and delete<br>> it from there.<br>> that might help. ???<br>> _______________________________________________
<br>> cisco-voip mailing list<br>> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a> <mailto:<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>><br>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">
https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>> ----------------------------------------------------------------------<br>> --<br>> _______________________________________________<br>> cisco-voip mailing list
<br>> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip
</a><br></div></div></blockquote></div><br>