<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
p.Code, li.Code, div.Code
{mso-style-name:Code;
mso-style-link:"Code Char";
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
background:#EAF1DD;
font-size:8.0pt;
font-family:"Courier New";}
span.CodeChar
{mso-style-name:"Code Char";
mso-style-link:Code;
font-family:"Courier New";
background:#EAF1DD;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">We had this problem with calls failing to route to voicemail when a DN was not assigned to a device. The fix was editing the DN directly and select the [x]
Active checkbox, just under the ASCII Alerting name. This checkbox won't appear for DNs assigned to a route point or device. When the DN was active, Dialed number analyzer would pretend everything was working fine when in reality, the more general route patterns
were used instead.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#002B5C">JP Senior</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> cisco-voip-bounces@puck.nether.net [mailto:cisco-voip-bounces@puck.nether.net]
<b>On Behalf Of </b>Lelio Fulgenzi<br>
<b>Sent:</b> 16 March 2012 9:13 AM<br>
<b>To:</b> Hefin James [ahj]<br>
<b>Cc:</b> cisco-voip@puck.nether.net<br>
<b>Subject:</b> Re: [cisco-voip] Problem with un-assigned DN's<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:black">While this may not answer the question, I do have a suggestion which might prevent the situation happening in the future. A Cisco
tech once told me, (actually, I had to have him repeat it numerous times since I was new to the whole thing) do not allow a trunk access to DNs/patterns that would route calls back to itself.<br>
<br>
So, take your 1XXX route pattern that sends calls to the PBX. Put this in a partition that all phones have access to, i.e. in their CSS. But, do not put the partition that contains this route pattern in the outbound CSS of the gateway of the PBX. This way,
if by chance a call gets routed to the PBX, it won't get rerouted back to CallManager. Once we did this, our call handling was much better. We went further to remove wildcard route patterns and use specific route patterns to the PBX.<br>
<br>
Does the inactive DN have any forwarding target? If it's active but not assigned, it may be handled differently?<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 (ANNU)<br>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
Cooking with unix is easy. You just sed it and forget it. <br>
- LFJ (with apologies to Mr. Popeil)<br>
<br>
<o:p></o:p></span></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:black">
<hr size="2" width="100%" align="center" id="zwchr">
</span></div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:black">From:
</span></b><span style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:black">"Hefin James [ahj]" <<a href="mailto:ahj@aber.ac.uk">ahj@aber.ac.uk</a>><br>
<b>To: </b><a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<b>Sent: </b>Friday, March 16, 2012 10:46:28 AM<br>
<b>Subject: </b>[cisco-voip] Problem with un-assigned DN's<br>
<br>
We have a problem that we can't get to the bottom off. <br>
The problem is where unassigned DN's (which have active selected) are falling through and matching a the general rule that we have forwarding to another PABX system (which has the DN marked as being on the CM, which then causes a loop on our ISDN trunk).<br>
Dialled number analyser shows the number hitting the specific route for 1793 under PA-ABER-OWNNET with the alternative match for 1XXX. (Flow copy shown below)
<br>
<br>
Any pointers as to why it's matching the general route, and not the specific route for the DN?<br>
It's also affecting DN's that are assigned to profiles that are logged off.<br>
<br>
Thanks,<br>
Hefin<br>
<br>
Results Summary<br>
Calling Party Information<br>
Calling Party = 2456<br>
Partition =<br>
Device CSS =<br>
Line CSS = CS-ABER-UK-UNR<br>
AAR Group Name =<br>
AAR CSS =<br>
Dialed Digits = 1793<br>
Match Result = RouteThisPattern<br>
Matched Pattern Information<br>
Pattern = 1793<br>
Partition = PA-ABER-OWNNET<br>
Time Schedule =<br>
Called Party Number = 1793<br>
Time Zone = Etc/GMT<br>
Call Classification = OnNet<br>
InterDigit Timeout = NO<br>
Device Override = Disabled<br>
Outside Dial Tone = NO<br>
Call Flow<br>
TranslationPattern :Pattern=<br>
Partition =<br>
Positional Match List = 1793<br>
Calling Party Number = 2456<br>
PreTransform Calling Party Number =<br>
PreTransform Called Party Number =<br>
Calling Party Transformations<br>
External Phone Number Mask = NO<br>
Calling Party Mask =<br>
Prefix =<br>
CallingLineId Presentation =<br>
CallingName Presentation =<br>
Calling Party Number = 2456<br>
ConnectedParty Transformations<br>
ConnectedLineId Presentation =<br>
ConnectedName Presentation =<br>
Called Party Transformations<br>
Called Party Mask =<br>
Discard Digits Instruction =<br>
Prefix =<br>
Called Number =<br>
Directory Number :DN= 1793<br>
Partition = PA-ABER-OWNNET<br>
TypeCFACSSPolicy =<br>
Forwarding Information<br>
Forward All : DN = <br>
VoiceMail = No <br>
CSS = Forward Busy Internal : DN = VoiceMail = No CSS = External : DN = VoiceMail = No CSS = Forward No Answer Internal : DN = VoiceMail = No CSS = External : DN = VoiceMail = No CSS = Forward No Coverage Internal : DN = VoiceMail = No CSS = External : DN =
VoiceMail = No CSS = Forward Unregistered Internal : DN = VoiceMail = No CSS = External : DN = VoiceMail = No CSS = CFDF : DN = VoiceMail = No CSS = Pickup Group Number = Device : Type = No Device associated with the DN Alternate Matches Partition :Name= PA-ABER-OWNNET
Pattern Pattern = 1XXX Pattern Type = Enterprise CallManager Device Type = AccessDevice PatternPrecedenceLevel = PlDefault PatternRouteClass = RouteClassDefault<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">https://puck.nether.net/mailman/listinfo/cisco-voip</a><o:p></o:p></span></p>
</div>
</div>
</body>
</html>
<pre>The contents of this message may contain confidential and/or privileged
subject matter. If this message has been received in error, please contact
the sender and delete all copies. Like other forms of communication,
e-mail communications may be vulnerable to interception by unauthorized
parties. If you do not wish us to communicate with you by e-mail, please
notify us at your earliest convenience. In the absence of such
notification, your consent is assumed. Should you choose to allow us to
communicate by e-mail, we will not take any additional security measures
(such as encryption) unless specifically requested.