View
174
Download
4
Category
Preview:
DESCRIPTION
CLLE FL 092014
Citation preview
Local Edition
Provisioning and Dial Plan with Cisco Unified Communications Manager 10.x
John F. Rosinski
Collaboration Consulting Systems Engineer (Florida)
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal 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
Local Edition
E.164-based Dial Plan with CUCM 10.x
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal Edition
Dial PlanBackground
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 platformsNewer forms of addressing to deal with (Uniform Resource Identifier)Globalization of the EconomyNeed 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 PlanDue to the evolution of collaboration, Cisco has likewise evolved it’s dial plan capabilities within it’s collaboration applications and endpoints
4
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal Edition
Dial Plan+E.164 and Cisco
What is +E.164An 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 systemsMost 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 padBut, 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
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal Edition
Globalized Dial PlanRecommendation Example with +E.164 in action
6
Jabber ClientDN = +14085551212
Mobile Device+33622334455
France PSTN
Jabber Client dials French cell phone 901133622334455
EMEA ClusterN. Amer Cluster
San Jose RemoteSIP Trunk
ILS and GDPR(detail covered later)
Paris Remote
CUBE
Paris UserDN = +33166778888
Paris User +33166778888France 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-worker901133166778888
OR86778888
OR+33166778888 (click-2-call)
Specific DN match +33166778888Routes to EMEA Cluster
Specific DN or GPDR local match +33166778888Matching 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 +33XXXXXXXXXRoutes 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
“ILS-E
nabled”
DN
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal 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 DNPrimary URI plus up to 4 more will ring DN
URI can be automatically imported from LDAP using these two fieldsmail 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 DialingIntro
cucmpub.cisco.local
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal Edition
Taking Advantage of URI DialingExtending 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/EIncluded 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 installationFor calls to and from other domains, Rich Media Session Licenses are required.
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal Edition
9
Alpha URI vs. NumberHow to Differentiate Between a Number and an Alpha URI
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 URIsThe 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.
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal Edition
SIP URI RoutingThe 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.combob@nyc.cisco.com
john@sjc.cisco.com
sjc.cisco.com
fra.cisco.com nyc.
cisco
.com
sjc.c
isco.
com
nyc.cisco.comfra.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 ClusterIM/P Cluster
IM/P Cluster
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal Edition
Inter-Cluster Lookup Service (ILS)What and Why?
What is ILSInter-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
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal Edition
ILS and Home Cluster DiscoveryMulti-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.comSME or “Main Cluster”
_cisco-uds._tcp.cisco.com.SRV 1 1 8443 maincucm.cisco.com
IM/P Cluster
ILS
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal Edition
ILS NetworkingInformation 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 TrunksSIP Route Pattern to
SIP Route Stringfra.cisco.com
SIP Route Pattern to SIP Route String
sjc.cisco.com
pete@cisco.com+1408555XXXX
Home: sjc.cisco.comVia RS: sjc.cisco.com
gerrard@cisco.com+3355566XXXX
Home: fra.cisco.comVia RS: fra.cisco.com
fra.cisco.com+3355566XXXX
sjc.cisco.com+1408555XXXX
CUBE ILS Route String Routing Only
ILS Route String LogicURI Dial Peers
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal Edition
ILSTopologies
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
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal 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
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal Edition18 “Leaf Clusters”
cisco.com
SIPH.323H.320
“uk-rm200@cisco.com”
3rd Party Video Endpoint
“amer-rm55@cisco.com”“uk-rm32@cisco.com”
All User’s Rendezvous URIsmeetnow.<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 FormatEveryone / 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 requestMake 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!!)
?
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal Edition
19 “Leaf Clusters”
cisco.com
Collaboration Meeting Room (CMR)Choosing a URI Scheme Cont…
Best Case ScenarioNo 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
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal 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.comNothing found, sends “any alias” to VCS-E
4. VCS-E checks local zone for sally@cisco.comNothing found, if unmodified, stops routing even though has *.cisco.com route towards CUCM
X
CUCM and VCSURI Routing and Loop Prevention
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal Edition
OTLD:acme.comOTLD:cisco.com
+14085551XXXInternet
Numeric Inter-Domain RoutingNot 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 toSIP Route String
vcs.cisco.com
PatternType,PSTNFailover,Pattern
Pattern,0:,+4085551XXX@cisco.com
GPDR Import toSIP 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.comcall +14085551212, GDPR match, append @cisco.com
*.* *.*
Local Edition
Provisioning
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal 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 ProvisioningAdministrative Improvements
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal Edition
CUCM 10 Dial Plan and ProvisioningWorking 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
+1408555121285551212
pete@cisco.com
UC ServicesIM and
PresenceVoice/Video
Visual VoicemailWebEx
DirectoryCTI Control
AD(&(objectclass=user)(|(co=United States)(co=Mexico)))
(&(objectclass=user)(|(co=United Kingdom)(co=France)))
Auto-createon AD import
emea.cisco.com
SME orCentral Cluster
ILS ExchangeUser’s URIs
User’s E.164sUser’s Home Cluster
AD Attribute PopulationtelephoneNumber = +14085551212
otherTelephone = 85551212mail = pete@cisco.com
Login to correct and query for
Services
Provide Services and login
instructions
Follow SRV record and
attempt cluster discoveryReturn Home Cluster URL
For Service Discovery
Service Profile
_cisco-uds._tcp.abc.com.SRV 1 1 8443 cucm.abc.com
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal Edition
amer.cisco.com
25
CUCM 10 Provisioning FoundationService Profile ConceptThe 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
UC
Ser
vice
s
Ser
vice
Pro
file
AD
User
Configura
tion
Fe
atu
re G
rou
p T
em
pla
te (
FG
T)
Quick U
ser
Add FGT Appliedat LDAP import
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal Edition
CUCM 10 Provisioning FoundationProvisioning 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
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal 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 ProvisioningLDAP and Provisioning with Multiple Clusters
AD
(&(objectclass=user)(|(co=United States)(co=Mexico)))(&(objectclass=user)(|(co=United Kingdom)(co=France)))
Attribute ValuesAMAccountName jdoeco United Statesmail jdoe@cisco.comtelephoneNumber +14085551212otherTelephone 85551212
amer.cisco.comemea.cisco.com
cn=users, dc=cisco, dc=com
Create the following using FGTDirectory Number +14085551212Blended URIjdoe@cisco.comEnterprise E.164 # w / ILS+14085551212Enterprise Alt. # w/ ILS85551212Home ClusterAssigned
LDAP Filter
LDAP Filter
© 2014 Cisco and/or its affiliates. All rights reserved.Presentation_ID Cisco PublicLocal 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 ProvisioningCreating the Device
Local Edition
Recommended