<div dir="ltr">Always from the SRND:<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">[...] This does not mean that the urgent pattern has a
higher priority than other patterns; the closest-match logic described
in the section on Call Routing in Unified CM still applies.
<p class="">
<a name="pgfId-1581457"></a>For example, assume the route pattern 1XX is
configured as urgent and the pattern 12! is configured as a regular
route pattern. If a user dials 123, Unified CM will not make its routing
decision as soon as it receives the third digit because even though 1XX
is an urgent pattern, it is not the best match (10 total patterns
matched by 12! versus 100 patterns matched by 1XX). Unified CM will have
to wait for inter-digit timeout before routing the call because the
pattern 12! allows for more digits to be input by the user.</p></blockquote><div><br></div><div>Both my translation patterns have urgent priority enabled, so this aspect should not matter. I do not understand if 1XXX has higher priority than 1! or viceversa, given 1234 as called number.<br></div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-12-09 16:09 GMT+01:00 Bill Talley <span dir="ltr"><<a href="mailto:btalley@gmail.com" target="_blank">btalley@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>I would think it will always match 1! because of the urgent priority setting. Keep in mind the example you gave from the SRND list three different translation patterns. The two you have are the same as far as the first two digits, no?<br><br>Sent from an Apple iOS device with very tiny touchscreen input keys. Please excude my typtos.</div><div><div class="h5"><div><br>On Dec 9, 2014, at 5:59 AM, daniele visaggio <<a href="mailto:visaggio.daniele@gmail.com" target="_blank">visaggio.daniele@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div><div><div><div><div><div>Hi all,<br><br></div>I have two translation pattern within the same partition (cucm 9.x).<br><br></div>They are:<br><br></div>1XXX<br>1!<br><br></div>When an incoming call from external sip gateway comes in with called number (say) 1234, the matched translation is 1!.<br><br></div>At first, I thought that 1!, being less specific than 1XXX, should not being matched.<br><br></div>Reading through <a href="http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab09/clb09/dialplan.html" target="_blank">Cisco Collaboration System 9.x Solution Reference Network Designs (SRND)</a>, I saw this:<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">When determining the number of matched strings for a variable-length
pattern, Unified CM takes into account only the number of matched
strings that are equal in length to the number of digits dialed.
Assuming a user dials 1311 and we have patterns 1XXX, 1[2-3]XX, and 13!,
the following table shows the number of matched strings of these
potentially matching patterns....<b>In this example the variable-length pattern 13! is selected as the best match</b>.</blockquote><div><br>Changing temporarily the translation pattern with a leading # and then going back to the original form, the pattern 1XXX started to be matched.<br></div><div><br></div><div>What do you think, guys? is this a bug or are 1! and 1XXX equal-precision matches from cucm point of view?<br><br></div><div>Thank you<br></div></div>
</div></blockquote></div></div><blockquote type="cite"><div><span>_______________________________________________</span><br><span>cisco-voip mailing list</span><br><span><a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a></span><br><span><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a></span><br></div></blockquote></div></blockquote></div><br></div>