Prepending digits on Corporate Directory lookup

Unanswered Question
Oct 30th, 2008
User Badges:

Hi,


I believe I have a rather simple question. We are running UCM 6.x.

Our AD is built from root domain and several child domains.


Each child domain users have their ipphone field with digits sufficient for dial only within that region (4 or 3 digits).

However, dialing between regions using ICTs have side codes....


What I want is for someone in region A when doing directory lookup find user in region B, BUT have XML that prepends the site code on a returned data, so it will be one touch dialing for that user in region A to region B.


If someone from region B searches for the same user, site codes are not needed and info will be returned from AD as is... It's like every region will have a customized XML which prepends site code digits according to which OU the search was performed.


My idea was to install SDK in each region and configure the XML so if lookup is made against region B (one of the child domains), then on return site code is prepended...all in XML.


It sounds easy, so maybe someone have a piece of code for that :-)


Thanks,

David

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
stephan.steiner Fri, 10/31/2008 - 00:52
User Badges:
  • Silver, 250 points or more

So you're saying you have multiple clusters. Are there network limitations that made you chose that approach? We usually do things with a single cluster and use a unified numbering plan (with more digits), then use patterns that allow people to dial the "local" extensions (so 3 or 4 digits) instead of the full 7 - 9 digits that the cluster numbering plan uses. That way, you could use the full internal extension for every user and the problem goes away.


You'll find LDAP search code in the IP Phone Services SDK.. and then you have two options: the programmatic one would use some mechanism to determine if a result needs to be prepended with an ICT prefix or not, based on the rules you have for that scenarios... e.g. you define the service so that it sends the region with it, so your service then knows where it is, read out not only the ipphone field from the AD but also which region each user is in, and then you have some lookup table which tells you that if user is in region A you need ICT prefix 123, if user is in region B you need ICT prefix 234, etc. and put it all together.


Or, you once again return to doing things on the CCM by prepending the ICT prefix to every number you return and have the appropriate translation patterns in place for each cluster so that the prefix is stripped away if applicable.

dknov Sat, 11/15/2008 - 09:01
User Badges:

Not yet, but I believe that key is to build a proper XML file, so when accessing different AD domains XML will either leave whatever if gets from AD as is, or will cut the prefix used for site code.


This way we can make a uniform update to ipphone field in AD and then use XML to manipulate the data per each site.


Not as convenient as using built-in LDAP integration, but oh well :-) BTW, I am surprised Cisco did not do something as simple as mask for received value. If they had done it so, we could used different masks for different LDAP integrations and everything would have been sweet....

stephan.steiner Mon, 11/17/2008 - 05:02
User Badges:
  • Silver, 250 points or more

Actually, if you're going to add a uniform numbering scheme over all clusters, you could just work with translation patterns on each cluster to strip the ict prefix when the call is for a local number.


We have such setups.. three clusters (more coming) over the world, but a uniform numbering scheme with 2 digits for the location (there's also a bunch of CMEs.. hence two digits) and 4 digits for internal numbers. Then, calling #number# would be translated into #number whereas #number# would be dialed as is. That way, you need one additional translation pattern per cluster and that's it...

dknov Mon, 11/17/2008 - 13:06
User Badges:

Stephan,


Yes, exactly, translation patterns are the obvious way to go for call routing, but my concern is about user convenience. Why would everyone in local sites see their neighbors next desk with ICT prefixes... very confusing ;-)


To strip off those prefixes, this is why I am try to jump through the hoops with those custom XML per each time to drip the ICT for looking in local AD domain and leave ICTs in place for lookups in remote AD domains (AD root domain and child domains).


BTW, why do you say that you use 2 digits site codes because of CME? Would it just be digits manupulation regarding how log your ICT codes are?


David

stephan.steiner Tue, 11/18/2008 - 00:30
User Badges:
  • Silver, 250 points or more

If we had just the 3 clusters, then one digit would be enough as ict prefix.. but since we also need to reach more and more CMEs, to have a unified internal numbering plan, two digits had to be prepended.


I don't think you'll have too much trouble getting people to accept seeing longer numbers if you explain to them that this means they now have the entire corporate directory accessible to them.. and not just the people from their own cluster - being able to dial the way they always used to seems to be more important in my experience (and we have quite a number of installations with a unified dialplan which is still allows local dialing with shorter numbers that correspond to the numbers they had prior to using our pbx).

Actions

This Discussion