1. Local Edition
Provisioning and Dial Plan with Cisco
Unified Communications Manager 10.x
John F. Rosinski
Collaboration Consulting Systems Engineer (Florida)

2. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
Objective and Assumptions
• Objective
To understand the importance and power of the Inter-cluster Lookup
Service (ILS) and its role in URI propagation / Global Dial Plan Replication
(GDPR), and Jabber Service Discovery
To understand how ILS and multi-cluster synchronization of information is
achieved
To understand new provisioning methods for users in CUCM and IM/P
• Assumption
Attendee understands the basics of UCM endpoint addressing (E.164 and
URIs) and dial plan management (CSS and PTs), trunks, DNs, patterns,
etc. in a multi-cluster environment.
Throughout this presentation, we will be referring to end-to-end Enterprise
dial plans of customers with some of the following characteristics
E.164-based dial plans
Larger footprint, many endpoints at many remote locations
International locations, and maybe some interest in Tail End Hop Off (TEHO)
Multiple CUCM Clusters
2

3. Local Edition
E.164-based Dial Plan with CUCM 10.x

4. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
Dial Plan
Background
What is a “Dial Plan”
An administratively configured collection of rules instructing call processing elements on how to allow, block, and route
calls/sessions between endpoints inside or outside of your network. Dial plan can also handles distribution of patterns
for routing, address manipulation, and the presentation of certain address elements to end users
Call Routing and Dial Behavior/Habits
Dial Plans and their capabilities within Cisco and in the industry are evolving due to things like:
Centralization of call control platforms
Newer forms of addressing to deal with (Uniform Resource Identifier)
Globalization of the Economy
Need for universal click-2-dial functionality
“I have a 4 digit Dial Plan”…
Is there really even such a thing with most customers?
If so, is probably referring to situation where routing and dial behavior are identical and require no manipulation or
different forms of dial habits (ex. a very small systems residing in a single country or provider’s network).
Cisco and Dial Plan
Due to the evolution of collaboration, Cisco has likewise evolved it’s dial plan capabilities within it’s collaboration
applications and endpoints
4

5. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
Dial Plan
+E.164 and Cisco
What is +E.164
An ITU-T recommendation defining a numbering plan for the world-wide PSTN.
It’s numeric presentation is normally prefixed with a “+” to indicate the country or origin.
+E.164 is very important in centralized systems
Most customers use a form of E.164 for numbering and routing today (as opposed to things like store numbers, etc.)
Guarantees uniqueness of addressing throughout your entire global system. Uniqueness of addressing is required for a functional
globalized routing scheme in a system
Brings much needed structure to the variability of pattern length and overlap of patterns between various countries around the globe.
+1 (N. America and various islands)
+[2-9]XX (rest of globe)
Cisco Numeric Dial Plan Possible Recommendation
 Globalized dial plan approach for our system (system = CUCM clusters)
 Address the DN with a globalized unique number using +E.164 (unless need the “site code” or “store number” methodology)
Can also use something else that is globalized, like 8XXXXXXX using the last 7 digits of the phone number.
Have both dial-able in the system: +E.164 for routing and click to dial, 8XXXXXXX for dialing inter-site from key pad
But, can still have XXXX intra-site.
 When digits enter the system, globalize the called and calling number to a global form, such as +E.164
 Once globalized, the unique patterns can route through the system without possibility of overlap
 Upon egress (to PSTN, phone), localize the number. Conform to the egress’ routing and presentation needs
 Utilize tools such as CSS/PTs, Calling/Called party transformations, and Global Dial Plan Replication (GPDR) with Inter-Cluster
Look-up Service (ILS) – covered later
 See SRND for details
5

6. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
Globalized Dial Plan
Recommendation Example with +E.164 in action
6
Jabber Client
DN = +14085551212
Mobile Device
+33622334455
France PSTN
Jabber Client dials French cell
phone 901133622334455
EMEA ClusterN. Amer Cluster
San Jose Remote
SIP Trunk
ILS and GDPR
(detail covered later)
Paris Remote
CUBE
Paris User
DN = +33166778888
Paris User +33166778888
France TEHO +33XXXXXXXXX
GDPR Pattern Entries and +E164s
+33166778888 (DN)
France GDPR pttn. +33XXXXXXXXX
• How might we implement enterprise global dial plan for US dialing to France for On-net calls and TEHO
calls while maintaining expected user dialing habits
• We will be looking only at one direction for simplicity in this example
• On-net call
• Off-net call with Tail-End-Hop-Off routing
GDPR Table
+33166778888  EMEA Cluster
+33XXXXXXXXX  EMEA Cluster
Translate (TP) called number in
order to globalize it to
+33166778888 (unless initially
dialed, then no need to translate)
Calling number already in
globalized format in our example 
Jabber dials Paris co-worker
901133166778888
OR
86778888
OR
+33166778888 (click-2-call)
Specific DN match +33166778888
Routes to EMEA Cluster
Specific DN or GPDR local match
+33166778888
Matching on DN’s partition
Transformation pattern localizes
calling number on Egress (to phone)
and can be applied to the device pool
of the phone
Maybe we convert all International
(from France’s perspective) calling
numbers to match dialing habit of
users for aesthetics and redial
+14085551212  0014085551212
translation pattern to globalize
called to +33622334455
Calling number already in globalized
format in our example 
GPDR pattern match
+33XXXXXXXXX
Routes to EMEA Cluster
Local Route Pattern
+33XXXXXXXXX
to CUBE
Localize calling and called number to what French PSTN likes
(Transformation Pattern at Egress of SIP Trunk Level)
For Example….
Called: +33622334455  0622334455
Calling: +14085551212  0014085551212

7. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
What is it?
SIP Uniform Resource Identifier (Email address best suited?, ex. alice@cisco.com)
Used for internet video dialing for years and gaining universal popularity for SIP dialing
Why?
Because its globally routable (DNS-based) and friendly, but E.164 is not going away any time soon
Cisco UC 9+ implements blended identity and is simply an alias to the DN
Primary URI plus up to 4 more will ring DN
URI can be automatically imported from LDAP using these two fields
mail attribute
msRTCSIP-primaryuseraddress attribute
URI can be dialed with or without the Right-Hand-Side (RHS)
Call “alice”, then “cisco.com” is automatically added from domain name configured in the
Organizational Top Level Domain service parameter
I have split DNS (Internal “cisco.local” external “cisco.com”). What is used where?
Internal host names for network connectivity, use internal
For User-facing things (SIP addressing and dialing), use external
Same goes for separating video out into a sub-domain unless necessary (ex. @video.cisco.com)
SIP URI Dialing
Intro
cucmpub.cisco.local

8. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
Taking Advantage of URI
Dialing
Extending Your Collaboration
Infrastructure to the Rest of the
World
VCS-E / Expressway Edge
VCS-C / Expressway Core
Cisco Firewall Traversal for Collaboration Workloads (IM&P,
Audio/Video, Directory, Messaging). SIP communications with
3rd party endpoints.
Securely extend your entire Collaboration infrastructure’s
communications to the rest of the world
Enables URI Dialing to and from CUCM registered endpoints
that support SIP URI dialing
All Telepresence endpoints, Jabber 9.6+, and most all current SIP
phone loads support URI dialing
Expressway C/E
Included for use with Jabber and Telepresence systems (registered with
CM) remote access with all levels of licensing in CUCM 9.x+
Virtual Machine Templates, OVA’s for Quick and Easy installation
For calls to and from other domains, Rich Media Session Licenses are
required.

9. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
Alpha URI vs. Number
How to Differentiate Between a Number and an Alpha URI
9
Alpha URIs and numbers routed differently
Dialed “numbers” can contain: +, 0-9, *, A-D
SIP Profile now has “Dial String Interpretation” setting
associated with endpoints and trunks
Setting is relevant for calls from endpoints and trunks
Before CUCM 9.x, we always treated the LHS of a URI as a number
and processed accordingly
Default: If LHS consists of characters 0-9, * or + then process as a
number. Else, treat as URI
This behavior can be bypassed if endpoint uses the “user=phone”
tag in request URI forces treatment as numeric URI
Recommendation: use un-ambiguous alpha URIs
The indirect use of the email address for LDAP imported user URIs
usually fits and has become de-facto standard
Note: “Always treat all dial strings as URI addresses”
effectively disables numeric routing. Don’t do this unless
your eliminating E.164 dialing from your system completely.

10. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
SIP URI Routing
The Intra-domain Routing Problem
Hierarchical URI suffix design can
identify home cluster (by sub-
domain)
Reachability established through SIP
route patterns for host parts
Simplifies routing. Example:
– sjc.cisco.com  1.1.1.1
– nyc.cisco.com  2.2.2.2
However, requiring a hierarchical
URI scheme for users adversely
effects usability
– Sue is sue@sjc.cisco.com
– Frank is frank@nyc.cisco.com
What if it is flat
– There is NO STANDARD for
intra-domain routing
pete@fra.cisco.com
bob@nyc.cisco.com
john@sjc.cisco.com
nyc.cisco.com
fra.cisco.com
?
pete@cisco.com
john@cisco.com
bob@cisco.com
IM and Presence clusters
have long solved intra-
domain routing (for
XMPP) by way of “inter-
cluster peering”
relationships…
IM/P Cluster
IM/P Cluster
IM/P Cluster

11. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
Inter-Cluster Lookup Service (ILS)
What and Why?
What is ILS
Inter-Cluster Look-up Service (ILS) is a cluster-wide service in UCM that, when configured on and between UCM
clusters, synchronizes information throughout the “ILS Network”
It came about in 9.x to solve a major routing and lookup limitations in a multi-cluster environment, and has been
greatly enhanced in 10.x
"Why" Specifics…
It was necessary to support URI addressing and Home Cluster Discovery
Also to greatly simplify administrative overhead in a multi-cluster environment
Ease adoption of powerful dial plan concepts such as TEHO
Because without ILS…..
URI dialing pretty much wouldn’t work well in a multi-cluster environment (mass configuration, routing loop
avoidance, call setup delay)
Would need to duplicate patterns on each cluster
We would need to manually configure Jabber clients to a specific cluster otherwise there is no simple way for
a Jabber client to find it’s home cluster
11

12. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
ILS and Home Cluster Discovery
Multi-Cluster Jabber Login
Jabber needs to know where to login, get its
configuration, and register (Covered in more detail in
the Jabber Design session)
As of 9.6+, the Jabber Client Framework utilizes a
SRV record for UDS on domain suffix domain (ex.
cisco.com)
Jabber should register to a CUCM node in the right
cluster for that user, else the initial login will fail and
manual configuration is needed
This is easy with one cluster
However, in a multi-cluster environment, if it points to
a specific cluster, and, for “pedepalm@cisco.com”, it
is the wrong cluster
Need a way to redirect the client to the right cluster
SOLUTION:
– UDS, which uses ILS, plays an important role in
cluster/service discovery. Let’s see how this works…
IM/P Cluster
IM/P
Cluster
petepalm@cisco.com
maincucm.cisco.com
SME or “Main Cluster”
_cisco-uds._tcp.cisco.com.SRV 1 1 8443 maincucm.cisco.com
IM/P
Cluster
ILS

13. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
ILS Networking
Information Synching
Components of end-to-end
URI/E.164 dialing/routing and home cluster
discovery
Database in each cluster consists of patterns, URI,
E.164, and Users tagged with home cluster
identification
The ILS Network Establishment (which is essentially
peering relationships)
Enable URI and Global Dial Plan Replication (ex.
alternate number advertising)
Configure User’s Home Cluster (Jabber)
Catalog transfers
SIP trunk and Route patterns for actual routing.
Called “SIP Route String”
ILS networking is foundation for exchange of
information only. Specifies destination “SIP Route
String”, but doesn't specify how to get to
destination. Hence, the need for SIP Route
patterns and SIP Trunk topology.
SIP connectivity is foundation for call routing based
on SIP route patterns and tells how to get to the
destination
ILS networking
URI / E.164 / UDS synching
pete@cisco.com and +1408555XXXX (via sjc.cisco.com)
gerrard@cisco.com and +3355566XXXX (via fra.cisco.com)
pete@cisco.comgerrard@cisco.com
SIP Trunks
SIP Route Pattern to
SIP Route String
fra.cisco.com
SIP Route Pattern to
SIP Route String
sjc.cisco.com
pete@cisco.com
+1408555XXXX
Home: sjc.cisco.com
Via RS: sjc.cisco.com
gerrard@cisco.com
+3355566XXXX
Home: fra.cisco.com
Via RS: fra.cisco.com
fra.cisco.com
+3355566XXXX
sjc.cisco.com
+1408555XXXX
CUBE
ILS Route String Logic
URI Dial Peers

14. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
ILS
Topologies
ILS Node Types (Stand-Alone, Hub, Spoke)
UCM Clusters participating in ILS network form a
hub & spoke topology
Each Cluster is either a hub or spoke
Hubs must be fully meshed
Largest diameter = 3 hops
ILS Topology is mutually exclusive from SIP
Routing
14
ILS hub
ILS spoke

15. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
Collaboration Meeting Room On-Prem (CMR)
Choosing a URI Scheme
What is CMR (See "Taking Collaboration to Next Level" Session for details)
On-premises, it provides users with their own Rendezvous alias and the ability for those
users to manage it (layout, PIN, Friendly Room Name)
Will make video conferencing pervasive throughout your organization
Need to decide on URI Formats for Rendezvous identification
Left Hand Side (LHS) Rendezvous URI Format
meetnow.jdoe@cisco.com or maybe jdoe.meetnow@cisco.com
Do something like  meetnow.{mail} or maybe meetnow.{username}@cisco.com inside of TMS
Right Hand Side (RHS) Rendezvous URI Format
jdoe@meetnow.cisco.com
Which Format do I choose?
It depends on your topology, number of clusters and their version (ILS capabilities), and
VCS registered endpoints and topology
Has significant routing implications:
LHS URI routing is complex for the application, requires Regex like matching, and only supported on VCS as
CUCM cannot manipulate the LHS. However, it’s more flexible and arguably easier for the end user.
RHS URI routing is easier for the application, but means having to adopt an less user-friendly hierarchical
domain structure
If we are all about the end-user experience, we’d use LHS
17
TMS 14.4

16. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition18 “Leaf Clusters”
cisco.com
SIP
H.323
H.320
“uk-rm200@cisco.com”
3rd Party Video
Endpoint
“amer-rm55@cisco.com”
“uk-rm32@cisco.com”
All User’s Rendezvous URIs
meetnow.<mail>
(ex. meetnow.pete@cisco.com)
cisco.com
vcs.cisco.com
Add SRV records for SIP/H.323 for
video.cisco.com
“uk-rm200@video.cisco.com”
video.cisco.com
Collaboration Meeting Room (CMR)
Choosing a URI Scheme Cont…
First, understand URI routing capabilities
VCS uses regular expressions for URI routing, will “search” different
destinations (at the expense of call setup delay), and is for simple and small
topologies
CUCM is all about deterministic routing in complex topologies, can only route
URIs by RHS (ex. @meetnow.cisco.com), and does not “search” for more
routes after route selection (it requires returned cause codes to re-route)
Problematic Scenario for LHS Rendezvous URI Format
Everyone / thing must to be intra-domain, or known as @cisco.com for their URI (per CIO).
Therefore, no sub-domains!
@cisco.com URI addresses destined at VCS, CUCM leaf clusters, and Conductor
?Where do we route @cisco.com throughout this topology?
Potential Solution
1. Use Global Dial Plan Catalog Import (ILS Hub only)
Import all host URIs for either VCS Host URIs and Conductor Rendezvous URIs using GDP
Catalogs
for example, lets say VCS and send to route string vcs.cisco.com
Now, @cisco.com routing centers in only one place (SME). Continue to route @cisco.com from
SME to Conductor
CUCM not an issue, as ILS provides for full knowledge of all URIs
2. Defy CIO’s request
Make unique the RHS of the 3rd party endpoints on VCS – confusing to end users
Add appropriate SRV records, transforms…
3. Convert all 3rd party endpoints to Cisco and register to CUCM (BEST!!)
?

17. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
19 “Leaf Clusters”
cisco.com
Collaboration Meeting Room (CMR)
Choosing a URI Scheme Cont…
Best Case Scenario
No registered VCS endpoints!
All Clusters talking ILS
Conductor rendezvous calls all via SME (or “main cluster”)
…And Route Rendezvous URIs on LHS
How will this work (Best Case Scenario)
No registered VCS endpoints
All CUCM systems will have exact route matches for all user URIs via
ILS (so no need to have routes for *.cisco.com)
VCS simply has to route two ways
To the Internet (*.*)
To the Inside (*.cisco.com) towards SME
1. Route *.* from Leaf Clusters to SME
2. Route *.* from SME towards VCS, and out to Internet
3. Route cisco.com from VCS’s towards SME
4. Route the ILS SIP Route Strings of leaf clusters to the leaf clusters
5. Route cisco.com URIs from SME to Conductor (for Rendezvous and
Bridge ID). Only remaining cisco.com requests as ILS knows all
others.
Expressway-E
Expressway-C

18. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
CUCM, loop prevention via CSS and PTs
Via ILS, CUCM has full knowledge of all specific URIs, so no
need for SIP route patterns amongst clusters
CUCM Trunks have CSS on them
Don’t allow the CSS of the CUCM inbound trunk from VCS to
to see the SIP route pattern of *.*
VCS has various mechanisms:
Primary one being a Search Rule mechanism
a call coming from specific zone (trunk) is not sent back from
where it come unless it’s been modified
1. Joe calls
sally@cisco.com
via Jabber (who
does not exist)
2. CUCM cluster(s)
check ILS DB, nothing
found, so follows *.* SIP
route pattern towards
VCS
3. VCS-C checks local
zone for
sally@cisco.com
Nothing found, sends
“any alias” to VCS-E
4. VCS-E checks local
zone for sally@cisco.com
Nothing found, if
unmodified, stops routing
even though has
*.cisco.com route
towards CUCM
X
CUCM and VCS
URI Routing and Loop Prevention

19. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
OTLD:acme.comOTLD:cisco.com
+14085551XXX
Internet
Numeric Inter-Domain Routing
Not ENUM
VCS-C VCS-E
Secure FW
Traversal
+15164442XXX
VCS-E VCS-C
Secure FW
Traversal
PatternType,PSTNFailover,Pattern
Pattern,0:,+5164442XXX@acme.com
GPDR Import to
SIP Route String
vcs.cisco.com
PatternType,PSTNFailover,Pattern
Pattern,0:,+4085551XXX@cisco.com
GPDR Import to
SIP Route String
vcs.acme.com
_sip._tcp.acme.com_sip._tcp.cisco.com
Requirement
– Both me and my business partner have firewall traversal. We’d like to dial each other over the internet via E.164
Problem
– CUCM does not support ENUM
– CUCM will attach “@cisco.com”), then if no match, send call via normal PSTN route plan.
– Ex. when dialing +15164442001 from cisco, the request and To: URI should be +15164442001@acme.com
Solution
– For a given +E.164, when dialed numerically, the appropriate RHS must be inserted into To: and request URI to make sure that B2B
connectivity can be established solely based on host piece routing.
– Based on GDPR imported patterns. CUCM can now route based off of RHS to numeric remote destinations.
*.* *.*
call +15164442001, GDPR match, append @acme.com
call +14085551212, GDPR match, append @cisco.com
*.* *.*

20. Local Edition
Provisioning

21. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
User administration has been greatly simplified!
Makes use of Profiles and Templates
User Profile, Service Profile,
Device/Line Templates
Templates can now be applied at the LDAP
integration or at time of user provisioning.
Two provisioning mechanisms added
IVR-based Self Provisioning (No
Administration Required)
Quick User/Phone Add
CUCM 10 Provisioning
Administrative Improvements

22. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
CUCM 10 Dial Plan and Provisioning
Working Example Overview
 Get Active Directory and Numbering Plan in order
 Globally dialable numbers in appropriate AD field
 Filterable object to determine cluster
membership
 CUCM 9.x+ blended Identity and URI dialing
 CUCM 10.x for ILS
 full dial plan replication
 Home Cluster discovery
 CUCM 10.x for provisioning
 Auto Create free Jabber IM/P Clients on AD import
 Quick Add or BAT to create CSF
 IVR for phones
 CUCM 9.x+ for Service Discovery
 UC Services and Service Profiles Configured
 Jabber discovers home cluster
 Jabber Logs into home cluster, queries for UC Services
 Home cluster provides assigned UC Services and Jabber
will logon to each service
 Let’s dive into the details…
amer.cisco.com
+14085551212
85551212
pete@cisco.com
UC Services
IM and
Presence
Voice/Video
Visual Voicemail
WebEx
Directory
CTI Control
AD
(&(objectclass=user)(|(co=United States)(co=Mexico)))
(&(objectclass=user)(|(co=United Kingdom)(co=France)))
Auto-create
on AD
import
emea.cisco.com
SME or
Central Cluster
ILS Exchange
User’s URIs
User’s E.164s
User’s Home Cluster
AD Attribute Population
telephoneNumber = +14085551212
otherTelephone = 85551212
mail = pete@cisco.com
Provide Services
and login
instructions
Service Profile
_cisco-uds._tcp.abc.com.SRV 1 1 8443 cucm.abc.com

23. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
amer.cisco.com
25
CUCM 10 Provisioning Foundation
Service Profile Concept
The Service Profile created to simplify Jabber registration and configuration
A Service Profile is made up of UC Services. Each UC Service represents a
Jabber workload:
– Voicemail, HTTP connection for Jabber for visual voicemail
– Mail Store, IMAP connection for Jabber to Unity Connection for voicemail retrieval
– Conferencing, WebEx site information or Jabber to WebEx or CWMS
– Directory, TCP connection for Jabber to AD for LDAP Contacts (as opposed to UDS)
– IM and Presence, XMPP connection information for Jabber to CUCM IM/P
– CTI, TCP connection for Jabber to CTI application server (CUCM phone control)
– Video Conferencing Scheduling Portal, HTTP connection from Jabber to TMS in order
for user to control on-prem Collaboration Meeting Rooms (CMR)
For Redundancy, there can be more than one UC Service for a given Jabber
workload (this depends on the workload application)
The UC Services are assigned to one or more Service Profiles
– Primary, and sometimes Secondary, and Tertiary UC Services are assigned to a
Service Profile
The Service Profile is assigned to the user by way of
– The User’s configuration page
– Through a Feature Group Template (FGT) either…
directly (via Quick User Add)
or indirectly (via LDAP integration)
Voicemail
MailStore
Conferencing
Directory
IM and Presence
CTI
Video Conference
Scheduling Portal
Voicemail
MailStore
Conferencing
Directory
IM and Presence
CTI
Video Conference
Scheduling Portal
UCServices
ServiceProfile
AD
FeatureGroupTemplate(FGT)
FGT Applied
at LDAP import

24. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
CUCM 10 Provisioning Foundation
Provisioning Configuration
Provisioning Configuration “Deconstructed”:
Assign Access Control Groups to the LDAP
Integration configuration
Can Create and assign directory numbers from
LDAP (with mask) or from a pool of numbers. The
DNs will not be assigned to a device until the
device is provisioned
Assigned Feature Group Templates (FGT) to
LDAP integration. Within FGT, we…
Assigned Home Cluster and enable IM and
Presence. Do not assign a single user to
multiple clusters
User Profiles and Service Profiles
User Profile (Universal Device and
Line Templates not shown)
Turn On Self Provisioning
Add Services to the Service Profile

25. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
User’s must be provisioned on only 1 cluster, so provisioning users at LDAP import
needs to grab only users that belong to it.
This can be done in the following ways:
– Direct integration’s User Search Base at different OU’s. This might require a somewhat
geographical OU design, which is unlikely.
– Standard LDAP filters.
With Standard LDAP Filters, you must have attributes to filter on
– LDAP filters can be nested and complex in order to zero in on the specific user LDAP attributes,
but your AD must have the necessary user information in order.
You can create a DN at import using Feature Group Templates. Phone number
population in AD is important
– If in full +E.164 from AD, then you just need to accept that as the DN
– URI assigned from mail or msRTCSIP-primaryuseraddress AD attribute
– Enable Routing (ILS) and globalized addressing. If imported phone number field not populated
with full +E.164, might be much harder to create the Enterprise Alternate Number
Assign Home Cluster on import
– Home cluster required for IM/P server assignment and URI blended Identity creation
– Jabber with IM/P up and running, zero touch
In 10.x, we have increased the number of LDAP integrations (to single AD Forest) in
a cluster to 30
– Might be a trade off of # integrations vs. filter complexity
27
CUCM 10 Provisioning
LDAP and Provisioning with Multiple Clusters
AD
(&(objectclass=user)(|(co=United States)(co=Mexico)))(&(objectclass=user)(|(co=United Kingdom)(co=France)))
Attribute Value
sAMAccountName jdoe
co United States
mail jdoe@cisco.com
telephoneNumber +14085551212
otherTelephone 85551212
amer.cisco.comemea.cisco.com
cn=users, dc=cisco, dc=com
Create the following using FGT
Directory Number +14085551212
Blended URI jdoe@cisco.com
Enterprise E.164 # w / ILS +14085551212
Enterprise Alt. # w/ ILS 85551212
Home Cluster Assigned
LDAP
Filter
LDAP
Filter


26. © 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco Public
Local Edition
Two Ways to Provision Device using CUCM 10 Provisioning
1. Self Service
Used in conjunction with Auto Registration
Phone must be auto registered before provisioned
TIP  add a speed dial to the Universal Line Template
assigned to auto auto-registered devices or assign a null
translation pattern forcing the auto-registered phone to the
provisioning IVR DN when the user takes it off-hook.
Self Service with CUCM IVR
Self Service IVR must be created first on Publisher
User follows prompts enters Self Service ID
Self Service User ID = form of user phone number
2. Quick User/Phone Add
Manually add device to local or AD user
Can apply User Info, FGT and auto-created DN automatically
from LDAP import
Provisioning might be limited to LDAP capabilities
UCM 10.x now supports 30 LDAP integrations
LDAP attributes and filtering extremely important in
multi-cluster environment
CUCM 10 Provisioning
Creating the Device

27. Local Edition