Globalized Dial Plan Design

Globalized Dial Plan Design
Danny Wong
Session ID 20PT
Abstract
This advanced session provides detailed dial-plan design

guidelines for each of the Cisco IP telephony deployment models
based on Cisco Unified Communications Manager, with
recommended best practices to help ensure successful, scalable
deployments.
This session covers the various dial-plan tools available in Cisco
Unified Communications Manager, such as route patterns,
translation patterns for digit manipulation, calling party
transformations for localisation and globalisation of calling party
information, dial-plan interaction with PSTN gateways and
Services Advertisement Framework's Call Control Discovery.
This session also covers how to best use these tools to deal with
real-world deployments. The main focus of the session is on
system design, with some implementation aspects. This session
is aimed at network planners and designers and telephony
analysts and assumes a working knowledge of the Dial Plan
functionality in Cisco Unified Communications Manager.
BRKSPM-2604_c1 © 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2
@gnowynnad
About @gnowynnad
CCIE R&S #22079, 5 UC-related iPhone

apps in iTunes store, father, husband,
son, SE@Cisco for 5 years
Meet Your Friend: The UC SRND
Source: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/dialplan.html
Agenda
 Introduction
 Call Routing Recap
 Developing a Global Dial Plan – Call Routing
 Developing a Global Dial Plan – Number
Presentation
 SAF/CCD
Agenda
 Introduction
Presentation
 SAF/CCD
What Is a Dial Plan About?
 From entered number to connected party

 Different domains of numbers
Input: Dialing habits
Core routing
Output: Connected party, display of alerting, calling,
connected number, numbers in placed/missed calls
 Calling and called party numbers
Different format of numbers
Number get transformed in the process of call routing
 Classes of service
What device is allowed to reach which destinations
Dialing
 Different types of dialed number (destinations)

National
International
National on-net – National calls to known sites on-net
International on-net – International calls to known sites on-net
Abbreviated on-net – Private numbering plan
Intra-Site – “Office next door”
 Who/what is dialing (is the source of the number)

Users using the keypad – Typically want short numbers
Applications, CTI – Number length irrelevant
Directories – Number format in the directory?
Dialing Habits
 For every type of number we need to define the format

to be used for these numbers
 Country specific habits might exist
 Enterprise dial plans at least need to define how to get
an outside line to dial externally
“0” in most European countries and China
“9” in the US, UK and HK
 Do we need to support abbreviated on-net dialing?
 Do we need to support (+)E.164 dialing?
Applications
Directories
Example Dialing Habits in Europe
 “0” (or “9”) to get an outside line

 Any number starting with 1-9 is generally internal
But please stay clear of “112”
 National numbers need a “0” in front of the area code:
0 – Outside line
0 – Escape for area code
69 – Area code of Frankfurt
Dial 0-0-6-9-... From inside the enterprise to Frankfurt
 international numbers are typically prefixed by “00”:
0 – Outside line
00 – Escape for country code
39 – Country code of Italy
 Dial 0-0-0-3-9-... From inside the enterprise to Italy
Enterprise Specific Dialing Habits
 Typically dialing habits for local, national,

international calls are given
 Need to agree on how to dial:
Private numbers (on-net)
Intra-Site
Services (meet-me, call park, pick-up ...); non-DIDs
 Do we also need to support “+”-dialing?
Private Numbering Plan
 Pro
Possibly shorter inter-site on-net dialing
Fixed length instead of possibly variable length inter-site on-
net dialing
Can be re-used for VM subscriber IDs
 Con
National dialing to known sites can be forced on-net; no
NEED for private numbering
Private numbers are only useable inside the enterprise
Will people actually use them?
Steering digit for private numbering reduces the set of
available numbers
Planning and maintenance effort
 Is it worth it?
Guidelines for Private Numbering Plan
 Typical format:
<access code> - any digit or “*”
<site id> - Might be a hierarchical scheme including regional
attributes
<extension> - Intra-site on-net extension
 Example: 8-496-1234
8 – Access code
496 – Site id (site 6 in Germany)
1234 – Local extension
 Make sure to reserve space (what if we get more than 9 sites
in Germany)
 Make it extensible (think “Shannon coding”)
 Changing an established private numbering is VERY hard
External Numbering Plan Requirements
 Providers dictate format for Calling/Called Party

Numbers on trunks
 Technology:
ISDN: Concept of Type (national, international, subscriber)
and Number
SIP: Only Number; typically +E.164
 PBX interconnect (Q.SIG)

End-to-end support for numbering used on existing PBX
systems
Uniform across all systems?
What to Use as DNs?
 Options:
Intra-site extension: Requires per-site partitions
Example: 9764
Unique abbreviated on-net extension
Example: 8 496 9764
+E.164: Unique; “+” to avoid overlaps
Example: \+49 6100 773 9764
E.164: Unique; how to avoid overlap?
Example: 49 6100 773 9764
National number (10-digit US)
What if you need to expand to global plan?
 Number transformations in UCM allow to map

between numbering schemes
+E.164 DNs and Non-DIDs
 Non-DIDs need to be assigned using “unallocated”

spaces
 International:
Unallocated: http://www.itu.int/pub/T-SP-E.164D
+0: Free by definition, possibly create hierarchical
numbering scheme starting with +0
 National:
Unallocated ranges in national numbering plans:
http://www.itu.int/oth/T0202.aspx?parent=T0202
 Completely different space: e.g. numbers starting

with “*”
Agenda
 Introduction
Presentation
 SAF/CCD
Line/Device CSS Approach for
Centralized Deployments
CSS’s Partitions Route Lists Route Groups
Line CSS BlockedPSTN ―Blocked‖
Dictates: Internal 9.[2-9]XXXXXX Translation
All Lines
 Class of Service 9.1[2-9]XX[2-9]XXXXXX Patterns
9.011!
9.011!#
Unrestricted OnCluster
(No Blocks) All IP Phone DNs
Device CSS
Dictates: RTP_PSTN
RTP Devices
 Path Selection 911

9.911 RTP RG
RTP
RTPDevices 9.[2-9]XXXXXX
9.1[2-9]XX[2-9]XXXXXX RL
9.011!
9.011!# RTP Gateways
NYC Devices
# CSS = N + C NYC_PSTN
911
9.911 NYC RG
N = # of Sites NYC
NYCDevices 9.[2-9]XXXXXX
C = # of Classes 9.1[2-9]XX[2-9]XXXXXX RL
of Service 9.011!
BRKSPM-2604_c1 © 2010 Cisco and/or its affiliates. All rights reserved. 9.011!#
Cisco Confidential
NYC Gateways
19
Line/Device with Local Route Group
CSSs Partitions Route Lists Route Groups
BlockedPSTN
9.[2-9]XXXXXX
Internal
9.1[2-9]XX[2-9]XXXXXX ―Blocked‖
9.011!
Translation
All Lines
9.011!#
Patterns
Unrestricted OnCluster
All IP Phone DNs
(No Blocks)
US_pstn_part
911
9.911 SFO RG
US LOC
Devices 9.[2-9]XXXXXX
RL
9.1[2-9]XX[2-9]XXXXXX
9.011!
9.011!# SFO Gateways
JFK Devices Local
Route
DP: JKF_DP
Location Specific Gateway Selection Group
SFO Devices Through Local Route Group Set

DP: SFO_DP JFK RG
on Device Pool
Where Do We Implement Intra-Site?
JFK Gateways
Local Route Group
Two Sites, Traditional Approach
OnCluster
Internal
All IP Phone DNs
All Lines
US_E911_part
Unrestricted 911
9.911
US_pstn_part
9.[2-9]XXXXXX
9.1[2-9]XX[2-9]XXXXXX
9.011! US LOC SFO RG
9.011!# RL
Location Specific Gateway Selection SFO Gateways

JFK Devices Through Local Route Group Set Local
Route
DP: JKF_DP on Device Pool Group
SFO Devices Still Need Site Specific Intra-Site Dialing;

DP: SFO_DP Use Device CSS or CSSes per CoS and Site JFK RG
Per Site: Only Remaining Advantage: Reuse

of Route Patterns
JFK Gateways
Agenda
 Introduction
Presentation
 SAF/CCD
Requirements
 Dialing Habits
4-digit intra-site
+ dialing for dialing from directories
US sites
9 + 7-digit for local calls
91 + 10-digit for national calls
9011 for international calls
German sites
0 for local calls
00 for national calls
000 for international calls
 Number presentation on phones in shortest

possible format
Requirements
 Routing
Forced on-net
Local gateways in every site
TEHO for international calls
 Classes of Service
Internal: Allowed to call all on-net destinations
National: Only national off-net destinations
International: No restrictions
 Sites
ESC: +4961007739XXX
STU: +49710023911XXX
SJC: +14085551XXX
DFW: +19725551XXX
DN Format
 Single partiton for all DNs

 Requires unique DNs
 We don’t have an abbreviated on-net numbering
plan
... and don’t want to create one from scratch
 +E.164 or E.164?
 Let’s start with +E.164 DNs

 Will it work with just line CSS and LRG?
CoS International
+E.164 Destinations
DN
SJCInternational All IP Phone DNs (+E.164)
USPSTNNational
\+1XXX
\+1XXX XXXXXX XXXX
XXXX, Urgent
Local
LOC RL Route
PSTNInternational
Group
\+!
\+!#, Discard Trailing #
XYZ RG
 Problem with calls to national +E.164 destinations?
 Partial overlap with \+!
 Solution: Make \+1XXX XXX XXXX urgent
 Other problems?
 DNs are non-urgent patterns
 \+! has partial overlap with all DNs
 Solution: We need urgent patterns for all on-net destinations to
avoid overlap with \+!
CoS International
+E.164 Destinations Avoiding Partial Overlap
DN
E164OnNet
DN \+14085551XXX, Urgent
\+19725551XXX, Urgent
\+4961007739XXX, Urgent
\+49710023911XXX, Urgent
USPSTNNational
\+1XXX XXX XXXX, Urgent
Local
LOC RL
PSTNInternational Route
Group
\+!
\+!#, Discard Trailing # XYZ RG
CoS International
+E.164 Destinations Avoiding Partial Overlap
DN
E164OnNet
DN \+14085551XXX, Urgent
\+19725551XXX, Urgent
\+4961007739XXX, Urgent
\+49710023911XXX, Urgent
USPSTNNational
\+1XXX XXX XXXX, Urgent
Local
LOC RL
PSTNInternational Route
Group
\+!
\+!#, Discard Trailing # XYZ RG
 Still need to support other dialing habits

 4-digit intra-site
 US PSTN dialing
CoS International
Adding 4-Digit Intra-Site
DN
E164OnNet
SJCIntra
DN SJCIntra Is Site-Specific
1XXX, Prefix +1408555
XYZ RG
PSTNInternational
USPSTNNational Local
Route
LOC RL Group
CoS International
Adding International Dialing
DN
E164OnNet
SJCIntra Partition for Dialing
DN Normalisation Is CoS Specific,
Because Translation Patterns
Can Only Have a Single
Specific Resulting CSS Which
Implements a Single CoS
UStoE164International
USE164International 9011.!, Urgent, Pre-Dot, Prefix +
9011.!#, Urgent, Pre-Dot, Prefix +
9.1[2-9]XX[2-9]XXXXXX, XYZ RG
Pre-Dot, Prefix +
PSTNInternational
Route
LOC RL Group
CoS International
Adding 9+7 (Local) Dialing; Full Picture
DN
E164OnNet
SJCIntra
DN
1XXX, Prefix +1408555 Partition for 9+7 Dialing
SJCtoE164local
Is Location Specific,
SJCE164Local 9.[2-9]XXXXXX, Pre-Dot, Prefix +1408 Because the Translation
Pattern Needs Site Specific
UStoE164International Called Party Transformation
9011.!#, Urgent, Pre-Dot, Prefix +
Pre-Dot, Prefix +
PSTNInternational
Route
SJCPSTNLocal LOC RL Group
\+1408[2-9]XXXXXX, Urgent
CoS National
Full Picture
DN
SJCInternational
SJCNational All IP Phone DNs (+E.164)
E164OnNet
SJCIntra
DN
SJCtoE164local
SJCE164Local 9.[2-9]XXXXXX, Pre-Dot, Prefix +1408
UStoE164National
USE164International
USE164National 9011.!,
9011.!, Urgent,
urgent, Pre-Dot,
pre-dot, prefix
Prefix ++
9011.!#,
9011.!#, Urgent,
urgent, Pre-Dot,
pre-dot, prefix
Prefix ++
Pre-Dot,
pre-dot, prefix
Prefix ++
PSTNInternational
Route
CoS Local
DN
SJCNational
SJCLocal All IP Phone DNs (+E.164)
E164OnNet
SJCIntra
DN
SJCtoE164local
SJCE164Local 9.[2-9]XXXXXX, Pre-Dot, Prefix +1408
UStoE164National
SJCtoE164
USE164National 9011.!,
9011.!, Urgent,
urgent, Pre-Dot,
pre-dot, prefix
Prefix ++
9011.!#,
9011.!#, Urgent,
urgent, Pre-Dot,
pre-dot, prefix
Prefix ++
Pre-Dot,
pre-dot, prefix
Prefix ++
Route
CoS Internal
DN
SJCInternal
SJCLocal All IP Phone DNs (+E.164)
E164OnNet
SJCIntra
DN
SJCtoE164Internal
SJCtoE164local
SJCE164Local 9.[2-9]XXXXXX,
9.[2-9]XXXXXX, Pre-Dot,
pre-dot, prefix
Prefix +1408
+1408
SJCtoE164
UStoE164Internal
9011.!,
9011.!, Urgent,
urgent, Pre-Dot,
pre-dot, prefix
Prefix ++
9011.!#,
9011.!#, Urgent,
urgent, Pre-Dot,
pre-dot, prefix
Prefix ++
Pre-Dot,
pre-dot, prefix
Prefix ++
Local
Route
Remember
 Translation patterns used to normalise dialing to

+E.164
Because TPs’ resulting CSS implements new CoS (does
not inherit the initial CoS), we need normalisation per CoS
 Non urgent DNs: Need to create urgent translation

patterns to avoid T302 based on overlap between
DNs and variable length PSTN route patterns
Inbound Routing on Gateways
 Internal DNs are +E.164

 Format of received called party number is provider
and technology depending
 Route after globalising to +E.164 on ingress
 Options
Incoming Called Party Settings: Prefixes and CSSes per
number type (not on MGCP gateways and SIP trunks)
Inbound calls CSS; Translation Patterns to get to +E.164
Inbound Routing on Gateways
Incoming Called Party Settings
 H.323 Gateway, H.323 trunk
 Prefix or transformation CSS per type
Transformation CSS not used for call routing only for
number transformations!
 Example: PSTN gateway in site ESC
Emergency Calls
 Emergency Calls need to be enabled for ALL

classes of service
 Emergency Calls need to be routed through an
egress gateway local to the caller
 Different Emergency Numbers:
US: 911
Europe: 112
Hong Kong: 999
Other...
 Options:
Put emergency pattern in device CSS
Add emergency partition to all CoS CSSes
International TEHO
Full Picture
DN
ESCInternational All IP Phone DNs (+E.164)
E164OnNet
ESCIntra
DN
9XXX, prefix +496100773
ESCtoE164local
0.[^0]!, pre-dot, prefix +496100
ESCE164Local 0.[^0]!#, pre-dot, prefix +496100
USE164International 000.!, urgent, pre-dot, prefix +
000.!#, urgent, pre-dot, prefix +
00.[^0]!, pre-dot, prefix +49 XYZ RG
00.[^0]!#, pre-dot, prefix +49
PSTNInternational
GERPSTNNational
\+49!
Local
\+49!#, strip trailing #
Route
ESCPSTNLocal LOC RL Group
\+496100!
\+496100!#, strip trailing #
Agenda
 Introduction
Presentation
 SAF/CCD
Calling/Called Number Transformations
What It Is: Concept
 Calls presented to a phone or a gateway typically

require the calling and the called party numbers be
adapted to the local preferences/requirements of:
The user receiving the call
The gateway through which the call is routed
The network to which the call is routed
 Calls received from an external network (e.g., the PSTN)

typically present calls in a localised flavor. We can now
adapt the received call based on:
The numbering plan presented by the network for a specific call
The called/calling number delivered into the UC system by the
gateway
Combining the two elements above, we can globalise the number
upon entry
Globalise on Ingress
 Goal is to get to +E.164
 Service Parameter:
Prefixes per type for H.323, MGCP and SIP (unknown only)
Not recommended
 Device Pool
Prefixes or CSSes per number type
 Gateway/Trunk
Prefixes or CSSes per number type (only “unknown” on SIP
trunks); Example: Gateway for ESC
Localise on Phones
 Transform Calling Party Number to shortest

possible format
 Example for SJC phones (+1 408 555 1XXX):
Calls from Display as
+1 408 555 1XXX 1XXX
+1 XXX XXX XXXX 91 XXX XXX XXXX or
XXX XXX XXXX
Is This a Problem?
+XX... 9011XX... or
+XX...
 Callback from missed calls directory goes to pre-

transformation number! (globalised number)
 Displayed number does not need to be dialable
Number Transformations
Calling Party Transformation Pattern
 Similar to translation
pattern, but matches on
calling (not CALLED)
party number
 Only allow calling party
transformations
 No impact on call routing
 Addressed by partitions
and CSSes (like regular
patterns)
Calling Party Normalisation
From +E.164 to Shortest Presentation
CSSs Partitions
SJCphonesFromE164
\+1408555.1!, Strip Pre-Dot
SJCphonesFromE164
\+1408.!, Strip Pre-Dot, Prefix 9
DFWphonesFromE164
DFWphonesFromE164 \+1972555.1!, Strip Pre-Dot
ESCtoE164local
USphonesFromE164
\+.1!, Strip Pre-Dot, Prefix 9
\+.!, Strip Pre-Dot, Prefix 9011
ESCphonesFromE164
\+496100773.1!, Strip Pre-Dot
ESCphonesFromE164
STUphonesFromE164
STUphonesFromE164 \+4971002391.1!, Strip Pre-Dot
ESCtoE164local
GERphonesFromE164
\+.!, Strip Pre-Dot, Prefix 000
Phone Directories
 Calling Party Numbers are transformed using phone’s (or device pool’s)
calling party transformation CSS
 Pre-Transformation number is stored in phone directory and is used for

callback
 Normalised (post-transformation) number does not necessarily need to be a

dialable number
 Pre-Transformation number needs to be dialable
Egress Called Party Normalisation
Gateways / Trunks
 Required format for called party numbers typically
defined by the provider
 Use Called Party Transformation CSS for outbound
calls
 Caveat: Device level transformations have no effect
on Q.SIG APDUs
 Example: PSTN gateway in Germany
Calls to Send as
+49XXX... XXX..., ISDN, National
+XXX... XXX..., ISDN, International
Egress Called Party Normalisation
Example: German PSTN Gateway
Egress Calling Party Normalisation
Gateways / Trunks
 Like called party normalisation, but use CALLING
party transformation patterns and CSS!
 When using the device pool calling party CSS make
sure that device pool is not shared by phones and
gateways (typically require different
transformations)
 Optional:
Filter non-DIDs and send dummy instead
Implement screening, if number does not match the
number range assigned to the trunk by the provider
Agenda
 Introduction
Presentation
 SAF/CCD
Dial Plans in Large Networks
 Dial plans in large networks are difficult to implement and maintain

 Centralized call routing intelligence improves scalability but still does
not scale well in very large networks
Call Agent Call Agent

Call Agent Call Agent Call Agent IP Network Call Agent
IP Network

Call Agent Call Agent Call Agent Call Agent

Call Agent Call Agent Call Agent
Call Agent
Dial Plan Scalability Issues
in Large Networks
 Call routing information between separate call routing

domains has to be manually configured:
Full-mesh configuration
Extremely complex, only suitable for small networks
Hub-and-spoke configuration when using centralized call routing
entities (SIP network services or H.323 gatekeepers)
Scales better than full-mesh topologies
Requires redundant deployment of central services
 Changes have to be manually configured

 PSTN backup has to be implemented independently at
each call routing domain
 No dynamic exchange of call routing information, no
automatic PSTN backup
Scalable Dial Plan Solution
for Large Networks
 Solutions for dynamic exchange of routing information exist

Dynamic IP routing protocols
Routers have local networks attached
Routers advertise local networks to other routers
All routers learn all available networks and how to get there
 Same concept can be used for call routing information

Call routing domains advertise telephone numbers or number ranges
Internal numbers and IP address for VoIP
External numbers for PSTN backup
 Call Control Discovery (CCD) has been introduced with Cisco

Unified Communications version 8
Call agents can advertise and learn call routing information using
Cisco Unified Communications Manager
Cisco Unified Communications Manager Express
Cisco Unified SRST
Cisco Unified Border Element
Cisco IOS Gateway
Call Control Discovery Overview
 CCD-enabled call agents

advertise to and learn from
CCD Call Agent
Call Agent “the network”
Call Agent
Call Agent
 SAF is used to distribute
Call Agent
information within
the network
 Service Advertisement
Framework (SAF)
SAF-Enabled forwarders interact with
IP Network CCD-enabled call agents
Call Agent (SAF clients):
SAF forwarder learns
information from SAF client
Call Agent
Call Agent SAF forwarders distribute
information among each other
Call Agent Call Agent SAF forwarder advertises
Call Agent Call Agent all learned information to
SAF client
SAF Components
Cisco Unified Cisco Unified
Communications Communications
Manager Manager  SAF supports any service
to be advertised
 CCD is the first Cisco
application using SAF
to advertise services
(call routing)
 SAF Network Components
SAF Client
SAF Client SAF Forwarders
CCD CCD
Exchange service information
among each other
SAF-CP SAF-CP Use the SAF forwarding
protocol (SAF-FP)
SAF Clients
SAF-FP Advertise services to and learn
services from SAF forwarders
Use SAF client protocol
(SAF-CP) to interact with
SAF forwarders
SAF Network with 5 SAF
Forwarders In case of CCD, SAF client
is a call agent
CCD—Base Configuration
BR Learned Routes
HQ Learned Routes
DN Pattern “ToDID” Rule IP Address Protocol
9XXX
PSTN
+4961007739XXX
HQ 10.1.5.10
+19725551XXX
SAF-Enabled 1XXX
IP Network
10.1.7.10 BR
CCD—Propagation of HQ Routes
BR Learned Routes
HQ Learned Routes
9XXX 0:+496100773 10.1.5.10 SIP
Learn Hosted Directory Number

9XXX Range and ToDID Rule and Store
in Memory
PSTN
+4961007739XXX
HQ 10.1.5.10
+19725551XXX
Advertise Hosted Directory SAF-Enabled 1XXX

Number Range (9XXX) and IP Network
ToDID Rule (0:+496100773)
10.1.7.10 BR
CCD—Propagation of BR Routes
BR Learned Routes
HQ Learned Routes
9XXX 0:+496100773 10.1.5.10 SIP
1XXX 0:+1972555 10.1.7.10 SIP
Learn Hosted Directory Number Range

and ToDID Rule and Store in Memory
9XXX
PSTN
+4961007739XXX
Advertise Hosted Directory Range
(1XXX) and ToDID rule (0:+1972555)
HQ 10.1.5.10
+19725551XXX
SAF-Enabled 1XXX
IP Network
10.1.7.10 BR
CCD—Call from HQ to BR
BR Learned Routes
HQ Learned Routes
9XXX 0:+496100773 10.1.5.10 SIP
1XXX 0:+1972555 10.1.7.10 SIP
Call Placed to 1001 Using SIP Trunk to 10.1.7.10
9XXX
PSTN
+4961967739XXX
HQ 10.1.5.10
+19725551XXX
SAF-Enabled 1XXX
IP Network
Call 1001
10.1.7.10 BR
CCD—Link Failure at BR
Marked
Unreachable BR Learned Routes
HQ Learned Routes
9XXX 0:+496100773 10.1.5.10 SIP
1XXX 0:+1972555 10.1.7.10 SIP
9XXX
PSTN
+4961007739XXX Link Failure
HQ 10.1.5.10
+19725551XXX
SAF-Enabled 1XXX
IP Network
10.1.7.10 BR
CCD—Call from HQ to BR
During Link Failure
Marked
Unreachable BR Learned Routes
HQ Learned Routes
9XXX 0:+496100773 10.1.5.10 SIP
1XXX 0:+1972555 10.1.7.10 SIP
Strip 0 Digits, Prefix +1972555

to Directory Number Pattern
(1XXX) for PSTN Number Call Placed to +19725551001
Using PSTN
9XXX
PSTN
+4961007739XXX Link Failure
HQ 10.1.5.10
+19725551XXX
SAF-Enabled 1XXX
IP Network
Call 1001
10.1.7.10 BR
Monitoring learned Patterns
 CCD learned patterns are added to UCM digit

analysis dynamically
Not displayed in route plan report
Invisible in UCM administration
 Use RTMT do view learned patterns

 Learned patterns are display without “Learned
Pattern Prefix” configured in CCD requesting
service!
CoS International
Integrating CCD Partition
DN
E164OnNet
SJCIntra
DN
1XXX, Prefix +1408555 CCD Partition Needs to Be
SJCtoE164local Added to CoS CSS and
SJCE164Local 9.[2-9]XXXXXX, Pre-Dot, Prefix +1408 Corresponding E.164 CSS
CCDPattern
9011.!#, Urgent, Pre-Dot, Prefix + SAF trunk
9.1[2-9]XX[2-9]XXXXXX,
Pre-Dot, Prefix +
PSTNInternational Local
USPSTNNational Route
Group
SJCPSTNLocal LOC RL
\+1408[2-9]XXXXXX, Urgent XYZ RG
CCD and Static Routing Integration
Considerations
 All routes learned by CCD are put into the same partition
 If partition is listed first in CSS it has priority for equally-
qualified matches
Allows learned routes to take precedence over statically configured
backup routes
Make sure that backup routes in later partitions are not more specific
than learned hosted DNs
 Routes in later partition(s) are only considered after learned
entry is completely deleted
Learned IP path is tried until CCD Learned Pattern IP Reachable
Duration (default 60 seconds) expiration
If IP path does not work during this time, the call fails
ToDID is used as backup after expiration of CCD Learned Pattern IP
Reachable Duration until expiration of CCD PSTN Failover Duration
If no ToDID configured, call fails during this time
Only after expiration of CCD PSTN Failover Duration
(default 48 hours) learned pattern is completely removed
Static backup patterns are now considered
Complete Your Session Evaluation
 Please give us your feedback!!

Complete the evaluation form you were
given when you entered the room
Don’t forget to complete the overall

event evaluation form included in
your registration kit
YOUR FEEDBACK IS VERY

IMPORTANT FOR US!!! THANKS

Globalized Dial Plan Design

Uploaded by

Copyright:

Available Formats

Globalized Dial Plan Design

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Globalized Dial Plan Design

Uploaded by

Copyright:

Available Formats

Globalized Dial Plan Design

This advanced session provides detailed dial-plan design

CCIE R&S #22079, 5 UC-related iPhone

 From entered number to connected party

 Different types of dialed number (destinations)

 Who/what is dialing (is the source of the number)

 For every type of number we need to define the format

 “0” (or “9”) to get an outside line

 Typically dialing habits for local, national,

 Do we also need to support “+”-dialing?

 Providers dictate format for Calling/Called Party

 PBX interconnect (Q.SIG)

 Number transformations in UCM allow to map

 Non-DIDs need to be assigned using “unallocated”

 Completely different space: e.g. numbers starting

 Path Selection 911

SFO Devices Through Local Route Group Set

Location Specific Gateway Selection SFO Gateways

SFO Devices Still Need Site Specific Intra-Site Dialing;

Per Site: Only Remaining Advantage: Reuse

 Number presentation on phones in shortest

 Single partiton for all DNs

 Let’s start with +E.164 DNs

 Still need to support other dialing habits

 Translation patterns used to normalise dialing to

 Non urgent DNs: Need to create urgent translation

 Internal DNs are +E.164

 Example: PSTN gateway in site ESC

 Emergency Calls need to be enabled for ALL

 Calls presented to a phone or a gateway typically

 Calls received from an external network (e.g., the PSTN)

 Transform Calling Party Number to shortest

 Callback from missed calls directory goes to pre-

 Pre-Transformation number is stored in phone directory and is used for

 Normalised (post-transformation) number does not necessarily need to be a

 Pre-Transformation number needs to be dialable

 Dial plans in large networks are difficult to implement and maintain

Call Agent Call Agent

Call Agent Call Agent Call Agent IP Network Call Agent

Call Agent Call Agent

Call Agent Call Agent Call Agent Call Agent

 Call routing information between separate call routing

 Changes have to be manually configured

 Solutions for dynamic exchange of routing information exist

 Same concept can be used for call routing information

 Call Control Discovery (CCD) has been introduced with Cisco

 CCD-enabled call agents

Learn Hosted Directory Number

Advertise Hosted Directory SAF-Enabled 1XXX

Learn Hosted Directory Number Range

Call Placed to 1001 Using SIP Trunk to 10.1.7.10

Strip 0 Digits, Prefix +1972555

 CCD learned patterns are added to UCM digit

 Use RTMT do view learned patterns

 Please give us your feedback!!

Don’t forget to complete the overall

YOUR FEEDBACK IS VERY

You might also like