Advanced Dial Plan Design for Unified Communications Networks Johannes Krohn BRKUCC PDF Free Download

Advanced Dial Plan Design for Unified Communications Networks Johannes Krohn BRKUCC-3000

Agenda Introduction Numbering vs Dialing Reference Dial Plan Call Routing Reference Dial Plan Number Presentation Special Considerations Deterministic Inter-Cluster Routing (Global Dial Plan Replication) SIP Routing URI Routing on SIP Trunks

Introduction

Remember Best and most important tools for dial plan design: Pencil Paper Whiteboard Dial plans are not a new concept IP did not really change the fundamentals of dial plan design Dial Plan recommendations are not a monolith Take what you need Keep it simple!

What Is a Dial Plan About? Mapping from dialed destinations to connected endpoints Concepts that are part of dial plans user input mapping of user input to routable format (transformations) routing / routing restrictions (class of service) call presentation numbering plans (addressing) 1234 1234 84961234 routing 84961234

User Input / Dialing Habits Users dial using common habits: Dialing Habits Different formats for types of destinations colleague next door example: 4XXX (four digit dialing) PSTN: local, national, international example: 9-7D, 91-10D, 9011-E.164, +E.164 Inter-office (abbreviated on-net, forced on-net) 8-7D, or any supported dialing habit for PSTN destinations mapped to on-net address Voicemail example: 4000 (special intra-site) Emergenc example: 911, 112, 110, 000 other services Especially external dialing habits are country-specific 9 or 0 for outside line Format of national numbering plan (fixed/variable length etc.)

Example Dialing Habits in Europe 0 (or 9 ) to get an outside line (trunk access) Any number starting with 1-8 is generally internal But please stay clear of 112 standardised emergency number National numbers need a 0 in front of the area code: 0 Trunk access 0 Escape for area code (Italy: 0 is part of the 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 Trunk access 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/agreed based on a given domain/country In addition need to agree on how to dial: Private numbers (on-net) Intra-Site Services (voicemail, meet-me, call park, pick-up...); non-dids + -dialing also needs to be supported! application support number portability

Dialing Domain Enterprise call controls need to be able to support different national dialing behaviours (different dialing habits) Groups of users sharing common dialing habits need to be treated identical Definition: Dialing Domain = Group of users/devices sharing common dialing habits to reach identical destinations US 901161284466000 90114961007730764 +1 408 555 1234 UC PSTN +61 2 8446 6000 DE 00061284466000 0061007739764 +49 3100 556677 00061284466000 +49 6100 123233 07739764 PSTN +49 6100 773 9764

Numbering vs. Dialing

Dial Plan vs. Numbering Plan Dial Plan: from dialed digits (dialing habits) to destinations Numbering Plan: scheme to identify entities (phones) unique number per entity e.g. (+)E.164 or private numbering allows for single numbering domain overlapping numbering e.g. unique per site requires partitioned numbering domains Recommended: unique addresses Benefits: maintain correct caller ID (think overlaps in forwarded inter-site calls) Simplified VM integration (unique subscriber IDs)...

Dial Plan vs. Numbering Plan Dial plan might support various dialing habits local call: 9+7D or 9+10D national call: 91+10D international call: 9011+<E.164> abbreviated on-net: 8+7D +E.164: +E.164 string Enterprise Numbering Plan might follow one of the above dialing habits (e.g. abbreviated on-net or +E.164)... but does not necessarily have to!

The Case for +E.164 Addresses (DN) PSTN addresses (E.164) are unique by definition No need to manage the addressing domain Prefix + allows to differentiate E.164 dialing from any other dialing habit Benefits if +E.164 DNs: +E.164 dialing habit for free Unique addresses (by definition) Correct globalized caller ID for calls orginiating from internal endpoints

+E.164 DNs and Non-DIDs (1) Non-DIDs for Lobby phones Features (call park, call pick-up, conferences,...) +E.164 DNs for regular phones provide Unique address (by definition) One on-net dialing habit for free (+E.164 dialing) Correct globalized caller ID for all call-flows originating from internal endpoints pseudo +E.164 DNs (e.g. +0...) don t have any of the above

+E.164 DNs and Non-DIDs (2) Better: start with the question how do I want my users dial these destinations?... And add the appropriate patterns as addresses directly Local Significance site specific partition with site-unique patterns caution with exposing non-did inter-site Global Significance global partition with unique patterns need to come up with enterprise specific numbering scheme On egress (specifically gateways) make sure to filter non-did caller IDs

Enterprise Numbering Plan (abbreviated on-net inter-site dialing) Why Overlay addressing for non-dids including conference rooms and other features Can be re-used for VM subscriber IDs Possibly shorter inter-site on-net dialing (if mapped to addresses of endpoints) Fixed length instead of possibly variable length inter-site on-net dialing Enterprise Significant Numbers (ESN) must not overlap with any other dialing habit Steering digit for ESNs reduces the domain available for other dialing habits Planning and maintenance effort!

Guidelines for ESN 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

Example Dialing Habits/Numbering Non-DID Addressing Based on Dialing Habits Site +E.164 Abbr. Intra-Site * Call Park ** CMR conferencing *** SFO +14085559XXX 9XXX 4XXX 88XXXXX NYC +12125551XXX 1XXX 4XXX 88XXXXX RTP +19195551XXX 1XXX 4XXX 88XXXXX * site specific translation patterns in site specific partition mapping to +E.164 ** single call park range in global partition or site specific call park ranges in site specific partitions *** single dialing habit (single route pattern) in global partition

Reference Dial Plan Call Routing

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

Requirements Sites ESC: +4961007739XXX STU: +49710023911XXX SJC: +14085551XXX DFW: +19725551XXX

CoS International +E.164 Destinations CSSs Partitions Route Lists Route Groups SJCInternational DN All IP Phone DNs (+E.164) USPSTNNational \+1XXX \+1XXX XXXX, XXXX Urgent PSTNInternational Problem with calls to national +E.164 destinations? Partial overlap with \+! Solution: Make \+1XXX XXX XXXX urgent LOC RL 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 \+! \+! \+!#, Discard Trailing # Local Route Group XYZ RG

CoS International +E.164 Destinations Avoiding Partial Overlap CSSs Partitions Route Lists Route Groups SJCInternational DN All IP Phone DNs (+E.164) DN E164OnNet \+14085551XXX, Urgent \+19725551XXX, Urgent \+4961007739XXX, Urgent \+49710023911XXX, Urgent USPSTNNational \+1XXX XXX XXXX, Urgent PSTNInternational \+! \+!#, Discard Trailing # LOC RL Local Route Group XYZ RG

CoS International Adding 4-Digit Intra-Site CSSs Partitions Route Lists Route Groups SJCInternational DN All IP Phone DNs (+E.164) DN E164OnNet SJCIntra 1XXX, Prefix +1408555 SJCIntra Is Site-Specific XYZ RG PSTNInternational USPSTNNational LOC RL Local Route Group

CoS International Adding International Dialing CSSs Partitions Route Lists Route Groups SJCInternational DN All IP Phone DNs (+E.164) DN USE164International E164OnNet SJCIntra 1XXX, Prefix +1408555 UStoE164International 9011.!, Urgent, Pre-Dot, Prefix + 9011.!#, Urgent, Pre-Dot, Prefix + 9.1[2-9]XX[2-9]XXXXXX, Pre-Dot, Prefix + Partition for Dialing Normalisation Is CoS Specific, Because Translation Patterns Can Only Have a Single Specific Resulting CSS Which Implements a Single CoS XYZ RG PSTNInternational USPSTNNational LOC RL Local Route Group

CoS International Adding 9+7 (Local) Dialing; Full Picture (pre 10.0) CSSs Partitions Route Lists Route Groups SJCInternational DN All IP Phone DNs (+E.164) DN SJCE164Local USE164International E164OnNet SJCIntra 1XXX, Prefix +1408555 SJCtoE164local 9.[2-9]XXXXXX, Pre-Dot, Prefix +1408 UStoE164International 9011.!, Urgent, Pre-Dot, Prefix + 9011.!#, Urgent, Pre-Dot, Prefix + 9.1[2-9]XX[2-9]XXXXXX, Pre-Dot, Prefix + Partition for 9+7 Dialing Is Location Specific, Because the Translation Pattern Needs Site Specific Called Party Transformation XYZ RG PSTNInternational USPSTNNational SJCPSTNLocal \+1408[2-9]XXXXXX, Urgent LOC RL Local Route Group

CoS International 10.0 Simplification (urgent DNs) CSSs Partitions Route Lists Route Groups SJCInternational DN IP Phone DNs (+E.164, urgent) DN SJCE164Local E164OnNet SJCIntra 1XXX, Prefix +1408555 SJCtoE164local 9.[2-9]XXXXXX, Pre-Dot, Prefix +1408 Full match on urgent DN terminates digit collection. No T302 caused by overlap with \+! route pattern USE164International UStoE164International 9011.!, Urgent, Pre-Dot, Prefix + 9011.!#, Urgent, Pre-Dot, Prefix + 9.1[2-9]XX[2-9]XXXXXX, Pre-Dot, Prefix + XYZ RG PSTNInternational USPSTNNational SJCPSTNLocal \+1408[2-9]XXXXXX, Urgent LOC RL Local Route Group

CoS International 10.0 Simplification (urgent DNs) CSSs Partitions Route Lists Route Groups SJCInternational DN IP Phone DNs (+E.164, urgent) DN SJCE164Local SJCIntra 1XXX, Prefix +1408555 SJCtoE164local 9.[2-9]XXXXXX, Pre-Dot, Prefix +1408 Full match on urgent DN terminates digit collection. No T302 caused by overlap with \+! route pattern USE164International UStoE164International 9011.!, Urgent, Pre-Dot, Prefix + 9011.!#, Urgent, Pre-Dot, Prefix + 9.1[2-9]XX[2-9]XXXXXX, Pre-Dot, Prefix + XYZ RG PSTNInternational USPSTNNational SJCPSTNLocal \+1408[2-9]XXXXXX, Urgent LOC RL Local Route Group

TP CSS Inheritance split personality Translation Patterns CSSs Partitions Route Lists Route Groups SJCInternational DN All IP Phone DNs (+E.164) UStoE164 9011.!, Urgent, Pre-Dot, Prefix + 9011.!#, Urgent, Pre-Dot, Prefix + 9.1[2-9]XX[2-9]XXXXXX, Pre-Dot, Prefix + XYZ RG SJCNational PSTNInternational USPSTNNational LOC RL Normalisation translation patterns use the activating CSS for secondary lookup Local Route Group A secondary lookup CSS following the activating CSS allows for re-use of normalisation

TP CSS Inheritance New in release 10.0 CSSs Partitions Route Lists Route Groups SJCInternational DN All IP Phone DNs (+E.164) UStoE164 9011.!, Urgent, Pre-Dot, Prefix + 9011.!#, Urgent, Pre-Dot, Prefix + 9.1[2-9]XX[2-9]XXXXXX, Pre-Dot, Prefix + Translation Pattern using CSS inheritance: secondary lookup uses activating CSS Translation Patterns can be re-used XYZ RG SJCNational PSTNInternational USPSTNNational LOC RL CSS Inheritance forces digit analysis to go back to the activating CSS after performing the calling/called party transformations defined on the translation pattern Ideal use case: dialing normalisation Local Route Group

CoS International 10.0 Simplification (TP Inheritance) CSSs Partitions Route Lists Route Groups SJCInternational DN IP Phone DNs (+E.164, urgent) DN SJCE164Local SJCIntra 1XXX, Prefix +1408555 SJCtoE164local 9.[2-9]XXXXXX, Pre-Dot, Prefix +1408 Don t need CoS specific secondary lookup CSS any more USE164International UStoE164International 9011.!, Urgent, Pre-Dot, Prefix + 9011.!#, Urgent, Pre-Dot, Prefix + 9.1[2-9]XX[2-9]XXXXXX, Pre-Dot, Prefix + XYZ RG PSTNInternational USPSTNNational SJCPSTNLocal \+1408[2-9]XXXXXX, Urgent LOC RL Local Route Group

CoS International 10.0 Simplification (TP Inheritance) CSSs Partitions Route Lists Route Groups SJCInternational DN DN IP Phone DNs (+E.164, urgent) SJCIntra 1XXX, Prefix +1408555 SJCtoE164local 9.[2-9]XXXXXX, Pre-Dot, Prefix +1408 UStoE164International 9011.!, Urgent, Pre-Dot, Prefix + 9011.!#, Urgent, Pre-Dot, Prefix + 9.1[2-9]XX[2-9]XXXXXX, Pre-Dot, Prefix + Might be a good idea to keep the DN CSS as secondary lookup for intra-site dialing to avoid abbreviated intra-site dialing of unassigned extensions to flow over to the PSTN XYZ RG PSTNInternational USPSTNNational SJCPSTNLocal \+1408[2-9]XXXXXX, Urgent LOC RL Local Route Group

Effect of CSS Inheritance W/ CSS Inheritance: dialing normalisation re-used W/o CSS Inheritance: dialing normalisation patterns per CoS (and site)

CSS Inheritance Configuration New translation pattern attribute ( Use Originator's Calling Search Space ) CSS is empty!

Other classes of service Other classes of service built based on CoS International by removing route patterns Re-use of all dialing normalisation patterns TP CSS inheritance allows to remove all redundancies

Enterprise alternate dialing Adding abbreviated on-net inter-site dialing CSSs Partitions Route Lists Route Groups SJCInternational DN IP Phone DNs (+E.164, urgent) DN SJCIntra 1XXX, Prefix +1408555 SJCtoE164local 9.[2-9]XXXXXX, Pre-Dot, Prefix +1408 OnNet 8496.9XXX, Pre-Dot, Prefix +496100773 for all other sites Dialing normalisation for abbreviated inter-site dialing UStoE164International 9011.!, Urgent, Pre-Dot, Prefix + 9011.!#, Urgent, Pre-Dot, Prefix + 9.1[2-9]XX[2-9]XXXXXX, Pre-Dot, Prefix + XYZ RG PSTNInternational USPSTNNational SJCPSTNLocal \+1408[2-9]XXXXXX, Urgent LOC RL Local Route Group

Alternate Numbers for DNs (10.0) Can define up to two alternate numbers on DN page Enterprise and +E.164 Alternate number defined using mask If mask is empty then DN is taken as configured Alternate Numbers can(!) be added to local route partition Alternate Numbers can(!) be advertised via ILS (Global Dial Plan Replication, GDPR)

Enterprise alternate dialing Adding abbreviated on-net inter-site dialing CSSs Partitions Route Lists Route Groups SJCInternational DN IP Phone DNs (+E.164, urgent) DN SJCIntra 1XXX, Prefix +1408555 SJCtoE164local 9.[2-9]XXXXXX, Pre-Dot, Prefix +1408 OnNet Enterprise alternate numbers Partition holding all enterprise alternate numbers defined for DNs UStoE164International 9011.!, Urgent, Pre-Dot, Prefix + 9011.!#, Urgent, Pre-Dot, Prefix + 9.1[2-9]XX[2-9]XXXXXX, Pre-Dot, Prefix + XYZ RG PSTNInternational USPSTNNational SJCPSTNLocal \+1408[2-9]XXXXXX, Urgent LOC RL Local Route Group

Alternate Numbers Alternate numbers can be put into local partitions (added to local dial plan) Alternate numbers allow to implement up to two overlay dialing habits Even abbreviated intra-site dialing could be implemented using the alternate numbers Abbreviated intra-site dialing is site-specific Make sure to have alternate numbers in site specific partitions Caution: abbreviated intra-site dialing should not be advertised to other clusters! In general alternate numbers should be globally significant

Remember Workarounds required pre-10.0: 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 10.0 dial plan enhancements simplify the design: Urgent priority for DNs Translation pattern CSS inheritance

Inbound Routing on Gateways Internal DNs are +E.164 Format of received called party number is provider and technology depending Route after globalizing to +E.164 on ingress Options Incoming Called Party Settings: Prefixes and CSSes per number type (pre 10.0: 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 Other... Options: Put emergency pattern in device CSS EM users use visited site s emergency calling format (recommended, but consider overlaps!) Add emergency partition to all CoS CSSes EM uses use home site s emergency calling format

Tail-End-Hop-Off Business case for national TEHO difficult Caller ID preservation? CLIP No Screening National restrictions for international TEHO? TEHO implemented through specific route pattern overlays

International TEHO Full Picture CSSs Partitions Route Lists Route Groups ESCInternational DN All IP Phone DNs (+E.164) DN E164OnNet ESCIntra 9XXX, Prefix +496100773 ESCE164Local GERE164International ESCtoE164local 0.[^0]!, Pre-Dot, Prefix +496100 0.[^0]!#, Pre-Dot, Prefix +496100 GERtoE164International 000.!, Urgent, Pre-Dot, Prefix + 000.!#, Urgent, Pre-Dot, Prefix + 00.[^0]!, Pre-Dot, Prefix +49 00.[^0]!#, Pre-Dot, Prefix +49 PSTNInternational GERPSTNNational \+49! \+49!#, Strip Trailing # ESCPSTNLocal \+496100! \+496100!#, Strip Trailing # LOC RL Local Route Group XYZ RG

International TEHO Full Picture CSSs Partitions Route Lists Route Groups DFW GW US TEHO SJC GW PSTNInternational \+1XXX XXX XXXX \+49! UStoE164International \+49!# GER TEHO Local Route Group ESC GW STU GW Local Route Group

Reference Dial Plan Number Presentation

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 the call is routed through The network the call is routed to 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 or respective outbound dialing habit 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 +XX... 9011XX... or +XX... Callback from missed calls directory goes to pre-transformation number! (globalised number) * Displayed number does not need to be dialable * * depending on phone model

Number Transformations 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 SJCphonesFromE164 Partitions SJCphonesFromE164 \+1408555.1!, Strip Pre-Dot \+1408.!, Strip Pre-Dot, Prefix 9 For Your Reference DFWphonesFromE164 ESCphonesFromE164 STUphonesFromE164 DFWphonesFromE164 \+1972555.1!, Strip Pre-Dot \+1972.!, Strip Pre-Dot, Prefix 9 ESCtoE164local USphonesFromE164 \+.1!, Strip Pre-Dot, Prefix 9 \+.!, Strip Pre-Dot, Prefix 9011 ESCphonesFromE164 \+496100773.1!, Strip Pre-Dot \+496100.!, Strip Pre-Dot, Prefix 0 STUphonesFromE164 \+4971002391.1!, Strip Pre-Dot \+497100.!, Strip Pre-Dot, Prefix 0 ESCtoE164local GERphonesFromE164 \+49.!, Strip Pre-Dot, Prefix 00 \+.!, Strip Pre-Dot, Prefix 000

Number Transformations on Endpoints Phones have Inbound and Outbound Calls Calling Party Transformation CSS Inbound: calls originating from endpoint; typically used to map from DN to +E.164 Outbound: calls terminating on endpoint; typically used to map from globalised calling party to display format Can also be configured on device pool Use Device Pool... Device Pool New in 9.0 Endpoint

End-to-End Calling Party Transformations Inbound / Outbound calls Outbound calling party transformation Inbound calling party transformation 610077369764/national +49610077369764 Inbound calling party transformation Outbound calling party transformation 84969764 Version 9.0 V 710012345/national +49710012345 00710012345 Caller ID for Calls From This Phone Calling party transformation Remote Number calling party transformation Version 9.1

Phone Directories Calling Party Numbers are transformed using phone s (or device pool s) outbound calling party transformation CSS But: pre-transformation number is stored in missed calls directory and used for callback * Concept: Pre-transformation calling party numbers should be globalised globalise on ingress, localise on egress Globalised numbers (pre-transformation) have to be routable! (supported dialing habit) * 7940/60 store post transformation number in missed/received calls directory (9.1 and later)

Egress Called Party Normalisation Gateways / Trunks required format for calling party numbers typically defined by the provider use Calling Party Transformation CSS for outbound calls Caveat: device level transformations have no effect on Q.SIG APDUs

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

Deterministic Inter-Cluster Routing (Global Dial Plan Replication)

Multicluster URI routing sfo.cisco.com nyc.cisco.com alice@sfo.cisco.com bob@nyc.cisco.com Host part of URIs might identify home cluster Reachability established through SIP route patterns for host parts Requires hierarchical URI scheme jkrohn@fra.cisco.com

Multicluster URI routing sfo.cisco.com nyc.cisco.com alice@cisco.com bob@cisco.com Host part of URIs might identify home cluster Reachability established through SIP route patterns for host parts Requires hierarchical URI scheme What if URI scheme is flat? jkrohn@cisco.com

Multicluster URI routing alice@cisco.com Host part of URIs might identify home cluster Reachability established through SIP route patterns for host parts Requires hierarchical URI scheme What if URI scheme is flat?? jkrohn@cisco.com bob@cisco.com

Intercluster Lookup Service (ILS) Fundamental idea Need mechanism that allows propagation of individual alpha URIs between call controls binds alpha URI with attribute that allows routing to URI s home cluster ILS each call control replicates it s alpha URIs to it s neighbours each call control also announces SIP route string together with the alpha URIs SIP route string can be routed based on SIP route patterns intercluster routing of alpha URIs not based on URIs host part, but on SIP route string

ILS Learning Learned from ILS bob@cisco.com nyc.route jkrohn@cisco.com fra.route sfo.route nyc.route Learned from ILS alice@cisco.com sfo.route jkrohn@cisco.com fra.route alice@cisco.com routestring: sfo.route Call controls establish ILS Exchange ILS Exchange bob@cisco.com routestring: nyc.route URI information flooded Each call control creates table with URIs and associated SIP route string SIP route strings routed by SIP route patterns Learned from ILS alice@cisco.com sfo.route bob@cisco.com nyc.route routestring: fra.route jkrohn@cisco.com

Routing Alpha URI Using ILS Information Learned from ILS bob@cisco.com nyc.route jkrohn@cisco.com fra.route 3) ILS Lookup leads to routestring fra.route 1) Alice calls jkrohn@cisco.com alice@cisco.com 2) not routeable using Alice s CSS (not a local URI) routestring: sfo.route ILS Exchange 4) call gets routed using SIP route pattern fra.route SIP route pattern can point to route lists starting with CUCM 9.0 5) jkrohn@cisco.com is routeable using the trunk s CSS (is a local URI) jkrohn@cisco.com routestring: fra.route

Inter-cluster URI routing recap URIs (especially flat URIs) can not be used as addresses ; they only are identifiers Introduce a location attribute (SIP route string) Bind set of identifiers (URIs) to a common location attribute (SIP route string) Indirect routing: route identifiers (URIs) according to learned location attribute (SIP route string)

GDPR Motivation On-Net/Off-Net decision w/ multiple call controls 912125557001 Maintained manually +1 408 555 1XXX 912125556001 +12125557XXX +14045556XXX +14085551XXX +19195557XXX +1 212 555 7XXX PSTN +1 919 555 7XXX +1 404 555 6XXX Each call control has to take independent on-net/off-net decisions Requires knowledge about remote on-net addresses Explicit configuration of remote address ranges or automatic learning? Complexity depending on number of prefixes! +1 212 555 6001

GDPR Motivation Local On-Net/Off-Net w/ Centralized Dial Plan? Maintained manually Really? 912125557001 912125556001 PSTN +1 408 555 1XXX +1 919 555 7XXX +1 212 555 6001 SME to centralize dial plan, apps, PBX interconnect etc Default routing on leaf vs. local on/off-net descision +1 212 555 7XXX +1 404 555 6XXX

GDPR Concept New in release 10.0 Split identity of (E.164) numbers Identifier: non-wildcarded number identifies a callable endpoint Address: number/pattern used to identify the location (typically prefix based) Global Dial Plan Replicaton (GDPR) allows to route numeric destinations based on locaton attribute (SIP route string) Reachability information associated with SIP route string (location information) Arbitrary topology of SIP trunks, arbitrary SIP route string address space structure Think of splitting location from identity for +E.164 numbers Location of +E.164 identifier now determined based on SIP route strings (locators) LISP for +E.164 DN is the key identity (address) in Communications Manager

GDPR Concept New per DN attributes: +E.164 alternate number and/or Enterprise alternate number (one can be assigned as PSTN fallback number) Defined using a mask Can be put into local partition (to implement alternate dialing habit) Can be advertised via ILS Advertized patterns +E.164 or enterprise number pattern PSTN failover: use pattern directly (+E.164) or strip/prefix instruction Differentiated partitions for learned numbers and patterns

GDPR learning and routing Global Learned E.164 Numbers +4961007739003 nyc.route +4961007739002 fra.route sfo.route nyc.route Global Learned E.164 Numbers +4961007739001 sfo.route +4961007739002 fra.route +4961007739001 routestring: sfo.route Call controls establish ILS Exchange ILS Exchange +4961007739003 routestring: nyc.route GDPR information flooded Each call control puts learned patterns/numbers in respective partitions and associated them with learned SIP route string Global Learned E.164 Numbers +4961007739001 sfo.route +4961007739003 nyc.route routestring: fra.route SIP route strings routed by SIP route patterns +4961007739002

Routing Call to remote Number using ILS Information Global Leaned +E.164numbers +4961007739003 nyc.route +4961007739002 fra.route 2) Match on learned numeric +E.164 pattern in digit analysis leads to SIP route string fra.route 1) Alice calls +4961007739002 +4961007739001 routestring: sfo.route ILS Exchange 3) call gets routed using SIP route pattern fra.route routestring: fra.route 4) +4961007739002 is routeable using the trunk s CSS (is a local DN) +4961007739002

ILS Networking, GDPR Learning and Routing Components of end-to-end dialing/routing ILS networking GDPR propagation SIP trunk SIP route pattern bob@cisco.com 84969XXX route: fra.route route string: nyc.route ILS networking GDPR propagation jkrohn@cisco.com. 84953XXX (fra.route) bob@cisco.com, 84969XXX (nyc.route) SIP Trunk route string: fra.route jkrohn@cisco.com 84953XXX route: nyc.route SIP connectivity is foundation for call routing based on SIP route patterns ILS networking is foundation for exchange or GDPR reachability information GDPR propagation/exchange is enabled independent of ILS networking

GDPR Number Types Enterprise Alternate Number : Enterprise specific dialing habit (abbreviated on-net dialing, e.g. 8-496-9764) +E.164 Alternate Number : +E.164 number (e.g. +4961007739764) Enterprise Pattern : Wildcarded Enterprise specific dialing habit (e.g. 8-496- 9XXX) +E.164 Patterns : Wildcarded +E.164 (e.g. +4961007739XXX) Example: DN 9764 (not recommended, but ) +E.164 Alternate +4961007739764 Enterprise Alternate: 84969764 Enterprise Pattern: 84969XXX +E.164 Pattern: +4961007739XXX 9764 9765 Site ESC: +E.164 range +49 6100 773 9XXX Enterprise range: 84969XXX

GDPR Information Exchange Single Catalog per ILS cluster can contain: Per DN GDPR information Up to 5 URI aliases Enterprise alternate number (abbreviated inter-site dialing) +E.164 alternate number PSTN failover number (for numeric and URI dialing) DN independent GDPR information Enterprise pattern (abbreviated inter-site dialing): summary per DID range +E.164 pattern: summary per DID range Additional catalogs: imported GDPR catalogs Individual SIP route string per imported catalog Advertised into GDPR by cluster the catalog is imported on Use case: proxy for systems not supporting GDPR/ILS

Advertising Patterns vs. individual Alternate Numbers All advertised numbers and patterns are added to digit analysis on the receiving cluster Only advertising summaries (patterns) reduces the numbers of entries to be considered on the receiving side Individual numbers need to be advertised if numbers can t be summarized (e.g. one DN from range moved to different cluster) or local on/off-net decision is absolutely required! Otherwise call to unassigned DN in +E.164 range might be sent to remote cluster only to be blocked there (Shouldn t really be a problem)

GDPR in an Enterprise Dial Plan Dialing learned numbers Up to three intercluster dialing habits to reach remote DN: Enterprise (8+7) based on enterprise alternate/pattern +E.164 based on +E.164 alternate/pattern URI Assuming that CoS does not depend on dialing habit all remote patterns can be put into single partition onnetremote CSSs SJCInternational ILS learned URIs are reachable from any device (, but the SIP route patterns potentially are not) DN Partitions DN All IP Phone DNs (+E.164) SJCtoE164 1XXX, Prefix +1408555 9.[2-9]XXXXXX, Pre-Dot, Prefix +1408 onnetremote All patterns/numbers learned via GDPR + SIP route patterns for SIP route strings onnetremote added to all CSSes with CoS On-net Also make sure to add SIP route pattern matching on SIP route strings to onnetremote partitions

PSTN failover for URI dialed calls with GDPR bob@example.org alice@example.org GDPR learned: bob@example.org (east.route) Alternate: +4961007739764 east.route west.route CAC or SIP trunk failure bob@example.org +4961007739764 Alternate (+E.164) PSTN GDPR provides PSTN alternate number for learned URIs If primary call fails (CAC failure or SIP trunk failure) reroute to PSTN using PSTN failover number and AAR CSS of calling device

SIP Routing

SIP Request Routing Flowchart Is LHS numeric? no Does whole URI match one in the CSS and URI table? no Does whole URI match one in ILS? no Does RHS match a SIP Route Pattern? no Block call yes yes yes No match yes Route/block based on existing numeric rules (see next slide) Offer call Note: Assume only alice@cisco.com is in URI table, 1) alice@cucm IP address will not route. 2) alice@cfqdn will not route Route using SIP route patterns based on routing string provided by ILS user @ example.org Route based on RHS Fallback for alpha-uris not local and not found in ILS! e.g. default routing left-hand-side (LHS) right-hand-side (RHS)

Numeric SIP Request Routing Flowchart Is RHS the IP address of a cluster member? no Does RHS match CFQDN? no Does RHS match OTLD? no Match RHS against SIP Route Pattern Route or block yes yes yes Analyze LHS Route or block Does LHS find a match? yes Offer call no numeric pattern actually routed based on RHS and not based on numeric dial plan

Clusterwide Domain Configuration OTLD: single domain CFQDN: one or more names separated by spaces Max 255 chars Allows wildcards; e.g. *.eu-cluster.home.org

Always set CFQDN and OTLD Set OTLD to match single(!) corporate domain name Make sure to set the CFQDN to match host names of all cluster nodes DNS naming structure might help e.g.: *.cucmeu.home.org for pub.cucmeu.home.org, sub1.cucmeu.home.org, Keep in mind that fallback routing based on RHS is implemented for: Alpha URIs not found locally Numeric URIs with RHS = OTLD not found in numeric lookup

Fully Qualified Domain Name in SIP Requests Always set Use Fully Qualified Domain Name in SIP Requests in SIP profile of all SIP trunks and endpoints involved: CUCM will relay an alphanumeric hostname of a caller to the called endpoint as a part of the SIP header information. This enables the called endpoint to return the call using the received or missed call list Mainly important for numeric IDs, but in mixed environments where numeric and alpha URIs exist, it s important to always have FQDNs in SIP requests for all calls For endpoints registered with CUCM the FQDN in SIP requests will be set to the OTLD configured in the enterprise parameters

Use Fully Qualified Domain Name in SIP Requests Example Route call cross-cluster INVITE bob@cisco.com RPID: sip:alice@cisco.com INVITE bob@cisco.com RPID: sip:alice@cisco.com ( Fully Qualified turned on) -or- INVITE bob@cisco.com RPID: sip:alice@10.10.10.1 ( Fully Qualified turned off) 180 Ringing RPID: sip:bob@cisco.com ( Fully Qualified turned on) -or- 180 Ringing RPID: sip:bob@10.10.10.1 ( Fully Qualified turned off) 180 Ringing RPID: sip:bob@cisco.com

URI Handling on SIP Trunks

RHS of numeric URIs on SIP trunks Numeric dialing 1234 OTLD:home.org Route Pattern: 1234, matched *.org INVITE sip:1234@192.168.10.74:5060 To: <sip:1234@192.168.10.74> 192.168.10.74 CUCM builds RHS of request and To: URI for numeric destinations based on configured SIP trunk destination Constructing RHS of To: and request URI makes perfect sense in pure numeric dialing environment where no concept of a URI host portion exists on the user side

RHS of numeric URIs on SIP trunks RHS of numeric URI matches OTLD, numeric match 1234@home.org OTLD:home.org Route Pattern: 1234, matched *.org INVITE sip:1234@192.168.10.74:5060 To: <sip:1234@192.168.10.74> 192.168.10.74 CUCM still builds RHS of request and To: URI for numeric destinations based on configured SIP trunk destination Numeric destination matched against numeric dial plan (OTLD match) and matches against configured route pattern When routed through a numeric route pattern RHS of To: and request URI are rewritten use FQDN in SIP requests setting on SIP trunk has no impact; only applied to calling/connected ID

RHS of numeric URIs on SIP trunks RHS of numeric URI matches OTLD, no numeric match 2000@home.org OTLD:home.org Route Pattern: 1234 *.org, matched INVITE sip:2000@home.org:5060 To: <sip:2000@192.168.10.74> 192.168.10.74 CUCM maintains original request URI but still rewrites RHS of To: URI based on configured SIP trunk destination Numeric destination matched against numeric dial plan (OTLD match), but no numeric match found Fallback to routing based on SIP route patterns RHS of To: URI not critical for routing (routing based on request URI), but possibly problematic if remote entities evaluate the To: URI for some reason

RHS of numeric URIs on SIP trunks RHS of numeric URI does not match OTLD 1234@example.org OTLD:home.org Route Pattern: 1234 *.org, matched INVITE sip:1234@example.org To: <sip:1234@192.168.10.74> 192.168.10.74 CUCM maintains original request URI but still rewrites RHS of To: URI based on configured SIP trunk destination RHS of request URI does not match OTLD; hence only routed based on SIP route patterns RHS of To: URI not critical for routing (routing based on request URI), but possibly problematic if remote entities evaluate the To: URI for some reason

RHS of numeric URIs on SIP trunks Summary For numeric destinations the RHS of the To: URI is always(!) rewritten RHS of request URI is only rewritten, if session is routed by match on numeric pattern Keep in mind that some numeric URIs are actually not routed numerically For these cases CSCtr30922 changes the behavior so that the To: URI is identical to request URI (check defect for integrated release, currently only 10.x)

Continue the Conversation using Cisco Spark Sign up free for Cisco Spark at http://www.ciscospark.com/ Download the application from ios App Store, Google Play Store, or from http://download.ciscospark.com/ Visit the World of Solutions Cisco Spark area for demos Use Cisco Spark to continue the conversation or ask any additional questions with the speaker for this session. The room name is BRKUCC-3000 How to get added to the Cisco Spark room for this session To opt in, send an email to spark-at-ciscolive@cisco.com with the message Please add me to the BRKUCC-3000

Complete Your Online Session Evaluation Give us your feedback to be entered into a Daily Survey Drawing. A daily winner will receive a $750 Amazon gift card. Complete your session surveys though the Cisco Live mobile app or your computer on Cisco Live Connect. Don t forget: Cisco Live sessions will be available for viewing on-demand after the event at CiscoLive.com/Online

Continue Your Education Demos in the Cisco campus Walk-in Self-Paced Labs Table Topics Meet the Engineer 1:1 meetings Related sessions

Thank you