Cucm 10 self provisioning and dial plan

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


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


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


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


What is it?SIP Uniform Resource Identifier (Email address best suited?, ex. [email protected])

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


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.


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.


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 [email protected]

– Frank is [email protected]

What if it is flat– There is NO STANDARD for

intra-domain routing

[email protected]@nyc.cisco.com

[email protected]

sjc.cisco.com

fra.cisco.com nyc.

cisco

.com

sjc.c

isco.

com

nyc.cisco.comfra.cisco.com

[email protected]

[email protected]

[email protected]

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

mailto:[email protected]



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


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 “[email protected]”, 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

[email protected]

maincucm.cisco.comSME or “Main Cluster”

_cisco-uds._tcp.cisco.com.SRV 1 1 8443 maincucm.cisco.com

IM/P Cluster

ILS


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

[email protected] and +1408555XXXX (via sjc.cisco.com)[email protected] and +3355566XXXX (via fra.cisco.com)

[email protected]@cisco.com

SIP TrunksSIP Route Pattern to

SIP Route Stringfra.cisco.com

SIP Route Pattern to SIP Route String

sjc.cisco.com

[email protected]+1408555XXXX

Home: sjc.cisco.comVia RS: sjc.cisco.com

[email protected]+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







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


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

[email protected] or maybe [email protected]

Do something like meetnow.{mail} or maybe meetnow.{username}@cisco.com inside of TMS

Right Hand Side (RHS) Rendezvous URI Format

[email protected]

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

“[email protected]”

3rd Party Video Endpoint

“[email protected]”“[email protected]”

All User’s Rendezvous URIsmeetnow.<mail>

(ex. [email protected])

cisco.com

vcs.cisco

.com

Add SRV records for SIP/H.323 for video.cisco.com

“[email protected]”

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!!)

?


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


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 [email protected] 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 [email protected] found, sends “any alias” to VCS-E

4. VCS-E checks local zone for [email protected] found, if unmodified, stops routing even though has *.cisco.com route towards CUCM

X

CUCM and VCSURI Routing and Loop Prevention


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:,[email protected]

GPDR Import toSIP Route String

vcs.cisco.com

PatternType,PSTNFailover,Pattern

Pattern,0:,[email protected]

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 [email protected]

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


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


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

[email protected]

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 = [email protected]

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


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


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


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 [email protected] +14085551212otherTelephone 85551212

amer.cisco.comemea.cisco.com

cn=users, dc=cisco, dc=com

Create the following using FGTDirectory Number +14085551212Blended [email protected] E.164 # w / ILS+14085551212Enterprise Alt. # w/ ILS85551212Home ClusterAssigned

LDAP Filter

LDAP Filter


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

Technology

Cucm 10 self provisioning and dial plan