[cisco-voip] LDAP custom filter for ipPhone field

Fri Oct 23 10:06:57 EDT 2015

The latest and greatest guidance from the man himself, Johannes Krohn, is
to store them in their globalized format.

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.

Session:
https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=83774&backBtn=true

*Jonathan Schulenberg  ·  July 8 10:25 AM *
Hi @Johannes
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?

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.

*Jonathan Schulenberg  ·  July 8 10:28 AM *
CORRECTED - Spark defect caused some content to be stripped out. I have
added underscores in hopes of defating the bug.
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.

*Johannes Krohn  ·  July 9 7:01 AM *
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.

On Thu, Oct 22, 2015 at 9:03 PM, NateCCIE <nateccie at gmail.com> wrote:

> I completely second the proposal to use +E.164 in directories.
>
>
>
> What I haven’t figured out what the right thing to do for non-DID
> extensions.
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] *On Behalf
> Of *Anthony Holloway
> *Sent:* Thursday, October 22, 2015 7:59 PM
> *To:* John Snow <John.Snow at cnrl.com>
>
> *Cc:* cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] LDAP custom filter for ipPhone field
>
>
>
> 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.
>
> 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.
>
>
>
> On Thu, Oct 22, 2015 at 4:37 PM, John Snow <John.Snow at cnrl.com> wrote:
>
> 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 J
>
> 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.
>
>
>
> Regards,
>
>
>
> John Snow
>
> Senior VoIP Analyst
>
> Canadian Natural Resources Limited
>
> Suite 1800, 324 – 8th Ave SW
>
> Calgary AB, T2P 2Z2
>
> T:  403 517 7238
>
> C:  587 585 2924
>
> Email: john.snow at cnrl.com
>
>
>
> *From:* avholloway at gmail.com [mailto:avholloway at gmail.com] *On Behalf Of *Anthony
> Holloway
> *Sent:* Thursday, October 22, 2015 3:07 PM
> *To:* John Snow
> *Cc:* cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] LDAP custom filter for ipPhone field
>
>
>
> 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:
>
>
>
> [image: Inline image 1]
>
>
>
> 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.
>
>
>
> I hope that helps.
>
>
>
> On Thu, Oct 22, 2015 at 3:33 PM, John Snow <John.Snow at cnrl.com> wrote:
>
> 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 ?
>
>
>
>
>
> Regards,
>
>
>
> John Snow
>
> Senior VoIP Analyst
>
> Canadian Natural Resources Limited
>
> Suite 1800, 324 – 8th Ave SW
>
> Calgary AB, T2P 2Z2
>
> T:  403 517 7238
>
> C:  587 585 2924
>
> Email: john.snow at cnrl.com
>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
>
> https://puck.nether.net/mailman/listinfo/cisco-voip[puck.nether.net]
> <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=>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20151023/63c39ce4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 12620 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20151023/63c39ce4/attachment.png>