<div dir="ltr">The latest and greatest guidance from the man himself, Johannes Krohn, is to store them in their globalized format.<div><br></div><div>Here is a discussion on the topic conducted on Cisco Spark, and based on the BRKUCC-3000 Advanced Dial Plan Design session at Cisco Live US this past summer.<br></div><div><br></div><div>Session: <a href="https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=83774&backBtn=true">https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=83774&backBtn=true</a></div><div><br></div><div><div><b>Jonathan Schulenberg  ·  July 8 10:25 AM </b></div><div>Hi @Johannes</div><div>I wanted to follow up on the change in recommendations for non-DIDs. Previously the SRND recommended what are now labled “pseudo" +E.164 DNs (e.g. +0… or unused space within the national numbering plan such as +1[01]XX[01]XXXXXX in NANP). More recently this has been recinded and effectively the 8<site id><extension> schema from the 6.x SRND era has returned. My question is why? Was this truely a change of heart internally or was there some external pressure (e.g. the ITU) who didn’t like the approach?<span class="" style="white-space:pre">       </span> </div><div><br></div><div>I ask for a few reasons: 1) I am struggling to see how a numeric access code, which reduces the number of available leading digits for abbreviated dialing habits, is better than the plus character; 2) how the <site id><extension> schema considerations such as length or shorter intra-site abbreviated dialing considerations are any different in either approach (e.g. 8<site id><extension> vs. \+1100[01]<site id><extension> or \+0<site id><extension>); and, 3) the “pseudo +E.164” recommendation was in the field for years, garnering clusters built based on it. As your slide deck mentions, changing the ESN is very hard and this change doesn’t seem to solve an additional problems.<span class="" style="white-space:pre">        </span> </div></div><div><br></div><div><div><b>Jonathan Schulenberg  ·  July 8 10:28 AM </b></div><div>CORRECTED - Spark defect caused some content to be stripped out. I have added underscores in hopes of defating the bug.</div><div>I ask for a few reasons: 1) I am struggling to see how a numeric access code, which reduces the number of available leading digits for abbreviated dialing habits, is better than the plus character; 2) how the _site id__extension_ schema considerations such as length or shorter intra-site abbreviated dialing considerations are any different in either approach (e.g. 8_site id__extension_ vs. \+1100[01]<site id__extension_ or \+0_site id__extension_); and, 3) the “pseudo +E.164” recommendation was in the field for years, garnering clusters built based on it. As your slide deck mentions, changing the ESN is very hard and this change doesn’t seem to solve an additional problems.<span class="" style="white-space:pre"> </span> </div></div><div><br></div><div><div><b>Johannes Krohn  ·  July 9 7:01 AM </b></div><div>Hi Jonathan, you are right: for some time i talked about using "unused" ranges in the E.164 domain for non-DIDs like +0 on the global level or +10 on the NANP level. While working on a global dial plan design with a customer i realized that pseudo +E.164 actually do not solve the actual problem of non-DIDs: since for example nobody actually wants to dial +0 pseudo +E.164s as pick-up numbers one would have to provision dialing normalization translation patterns transforming from the site specific (or global) dialing habit to reach the respective non-DID to the pseudo +E.164 address of that non-DID. This creates addtl. overhead in the dial plan. You might now want to argue that we ave the same situation with +E.164 DNs where the typical preferred dialing habit also probably is not +E.164, but OTOH +E.164 DNs have three advantages: unique by definition (numbering plan managed by national numbering plan authorities), one dialing habit for free (+E.164) and correct caller ID for all call flows. Comparing that to pseudo +E.164 non-DIDs we see that none of these three advantages exist for non-DIDs: they are not unique by definition (the pseudo +E.164 range is managed by the UCM admin), we don't get a useful dialing habit for free (nobody dials pseudo +E.164s) and the caller ID for non-DIDs should not be sent to the PSTN anyway. Hence i came to the conclusion that's it's actually better to define the cluster addressing for non-DIDs based on the desired dialing habits for non-DIDs by starting with the question "How do i want my users to dial non-DIDs" and then use the desired dialing habit as addressing schema for the non-DIDs directly. The desired dialing habit(s) for non-DIDs now can be either locally significant (site specific) or global (enterprise wide) so that this approach leads to either site-specific non-DIDs or global non-DIDs which need to be configured in site-specific or global partitions respectively. Enterprise specific numbering (like for example 8+7) is only required if global inter-site dialing is required for non-DIDs. Keep in mind that also with +0 pseudo +E.164 non-DIDs some global inter-site dialing different from +0 would need to be defined if global inter-site dialing to non-DIDs is a requirement and would need to be implemented through the appropriate translation patterns. So why not configuring the non-DIDs in the format of the dialing habit directly instead of using some pseudo format combined with translation patterns; BTW: these translation patterns cover/block the exact same space in the enterprise numbering domain as the direct non-DID addressing using the same format.<span class="" style="white-space:pre">    </span> </div></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 22, 2015 at 9:03 PM, NateCCIE <span dir="ltr"><<a href="mailto:nateccie@gmail.com" target="_blank">nateccie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I completely second the proposal to use +E.164 in directories.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">What I haven’t figured out what the right thing to do for non-DID extensions.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> cisco-voip [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nether.net</a>] <b>On Behalf Of </b>Anthony Holloway<br><b>Sent:</b> Thursday, October 22, 2015 7:59 PM<br><b>To:</b> John Snow <<a href="mailto:John.Snow@cnrl.com" target="_blank">John.Snow@cnrl.com</a>></span></p><div><div class="h5"><br><b>Cc:</b> <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br><b>Subject:</b> Re: [cisco-voip] LDAP custom filter for ipPhone field<u></u><u></u></div></div><p></p><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal" style="margin-bottom:12.0pt">You're right about CUC being able to manipulate the data it pulls from AD.  That's a pretty good feature of CUC, though, I've never seen it used before.  But, still nice to have options like that.<u></u><u></u></p></div><p class="MsoNormal">For a while now, I have been proposing +E164 directories, so that numbers are dialable from any device, any acquisition, any merger, etc.  Maybe you can just get AD updated to +E164 and add that functionality into the dial plan?  You could relatively easily script the update into AD so that your change is bulk in nature.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Thu, Oct 22, 2015 at 4:37 PM, John Snow <<a href="mailto:John.Snow@cnrl.com" target="_blank">John.Snow@cnrl.com</a>> wrote:<u></u><u></u></p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Yeah what happened here is an AD migration took place to consolidate two domains with two CM clusters (A=4 digits, B=10 digits). The ipPhone field on ClusterA was being entered as 10digits so the business wanted me to write a script to strip it down to 4 – not my recommendation so I was hoping this was not possible </span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d">J</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I thought based on the default filter ipphone=* ,  that * in itself was a regular expression and it would be possible to write something more elaborate similar to what UCXN can do.</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif;color:#1f497d">Regards,</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif;color:#1f497d">John Snow</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif;color:#1f497d">Senior VoIP Analyst</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif;color:#1f497d">Canadian Natural Resources Limited</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif;color:#1f497d">Suite 1800, 324 – 8th Ave SW</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif;color:#1f497d">Calgary AB, T2P 2Z2</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif;color:#1f497d">T:  <a href="tel:403%20517%207238" target="_blank">403 517 7238</a></span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif;color:#1f497d">C:  <a href="tel:587%20585%202924" target="_blank">587 585 2924</a></span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif;color:#1f497d">Email: <a href="mailto:john.snow@cnrl.com" target="_blank">john.snow@cnrl.com</a></span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p><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"> <a href="mailto:avholloway@gmail.com" target="_blank">avholloway@gmail.com</a> [mailto:<a href="mailto:avholloway@gmail.com" target="_blank">avholloway@gmail.com</a>] <b>On Behalf Of </b>Anthony Holloway<br><b>Sent:</b> Thursday, October 22, 2015 3:07 PM<br><b>To:</b> John Snow<br><b>Cc:</b> <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br><b>Subject:</b> Re: [cisco-voip] LDAP custom filter for ipPhone field</span><u></u><u></u></p><div><div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal">Just so you know the LDAP filters do not manipulate data synced in from LDAP.  They simply filter which records will be synced.  If you already have the ipPhone field filled in, within LDAP, as the last 4 of the phone, then you're probably only missing the mapping in the LDAP directory.  It looks like this:<u></u><u></u></p><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal"><img border="0" width="536" height="213" src="cid:image001.png@01D10D04.A727D1D0" alt="Inline image 1"><u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">I believe in 9.1(2) you cannot change this field on the fly.  Instead, you have to delete the integration and then re-add it with that field set.  In CUCM 10x you can just change it whenever you want.<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">I hope that helps.<u></u><u></u></p></div></div></div></div><div><p class="MsoNormal"> <u></u><u></u></p><div><div><div><p class="MsoNormal">On Thu, Oct 22, 2015 at 3:33 PM, John Snow <<a href="mailto:John.Snow@cnrl.com" target="_blank">John.Snow@cnrl.com</a>> wrote:<u></u><u></u></p><div><div><p class="MsoNormal">I am searching for a regular expression(s) syntax to import the last 4 digits from the ipPhone field attribute.  Anyone know if this can be accomplished in CUCM 9.1.2 ?<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif">Regards,</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif">John Snow</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif">Senior VoIP Analyst</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif">Canadian Natural Resources Limited</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif">Suite 1800, 324 – 8th Ave SW</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif">Calgary AB, T2P 2Z2</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif">T:  <a href="tel:403%20517%207238" target="_blank">403 517 7238</a></span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif">C:  <a href="tel:587%20585%202924" target="_blank">587 585 2924</a></span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Tahoma",sans-serif">Email: <a href="mailto:john.snow@cnrl.com" target="_blank">john.snow@cnrl.com</a></span><u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p></div></div></div></div><div><div><p class="MsoNormal"><br>_______________________________________________<br>cisco-voip mailing list<br><a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><u></u><u></u></p></div></div><p class="MsoNormal"><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_cisco-2Dvoip&d=CwMFaQ&c=aCXjXS7ZZ-mOR1xNksNgTg&r=0dwR7MgCdcKS3L4tuPBDuwL8G7meAwcyDgMIephsLj8&m=XCQaqLO7tgU5cE4sY2wA9IQLz2nFhh0lZFZghE705oc&s=MA1OO6ZEC29yb4Y0C0D6j6guwbMAF8_ulwT3zwRcKAE&e=" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip[puck.nether.net]</a><u></u><u></u></p></div><p class="MsoNormal"> <u></u><u></u></p></div></div></div></blockquote></div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></div></blockquote></div><br></div>