CUCM Dial Plan and Call Routing FAQ

From DocWiki

(Difference between revisions)
Jump to: navigation, search
(How do you configure a DID in CUCM??)
(How do you configure a DID in CUCM??)
Line 432: Line 432:
The telco will configure the routing on their side and deliver you the calls with whatever technology you chose, or the telco offered. It may be FXO, PRI, SIP trunk, etc. or you might use another combo, like an FXO with a GSM gateway. This also doesn't matter to CUCM.
The telco will configure the routing on their side and deliver you the calls with whatever technology you chose, or the telco offered. It may be FXO, PRI, SIP trunk, etc. or you might use another combo, like an FXO with a GSM gateway. This also doesn't matter to CUCM.
-
Telco will deliver you the calls with a certain number of digits, and this might vary, for our example lets assume we get four digits. So, when someone dials 1 222 333 4444, the telco will present us a call to 4444. If you want / need +- digits, you will need to discuss that with telco.
+
Telco will deliver you the calls with a certain number of digits, and this might vary, for our example lets assume we get four digits. So, when someone dials 1 222 333 4444, the telco will present us a call to 4444. If you want / need +- digits, you will need to discuss that with telco. You need to know how many digits the telco delivers.
You will use a GW to connect with your telco, and I will not discuss the GW configuration in detail, this will depend on technology and protocol used.<br>
You will use a GW to connect with your telco, and I will not discuss the GW configuration in detail, this will depend on technology and protocol used.<br>
Line 447: Line 447:
And you're done, you've configured a DID in CUCM.
And you're done, you've configured a DID in CUCM.
-
''Was the above any different from any other DN / pattern you have configured in CUCM??''
+
''Was the above any different from any other DN / pattern you have configured in CUCM??''<br>
Pretty sure you'll answer it wasn't, and that's because CUCM has no special configuration for a DID.
Pretty sure you'll answer it wasn't, and that's because CUCM has no special configuration for a DID.

Revision as of 18:07, 11 September 2018

Back to Unified Communications FAQ
Back to CUCM FAQ

Contents

What are the partitions and CSS (Calling Search Space)??

Partitions and CSS are some of the building blocks for CUCM's dial plan, they define who you can call, and who can call you, and are associated to many other configuration items.

The easiest way to think of this, are locks and keys.
A partition will be a door with a specific lock, and the CSS will be the keychain with the keys you need.
In order to open a door with a lock, you need the right key.
That's the best I can think of to explain the concept.

There are some special considerations about this, any CUCM has a <none> partition, and <none> CSS, those are built-in and cannot be removed.
The equivalent of <none> partition would be a door without a lock, and the <none> CSS keychain without keys. It goes without saying that neither of them are a good idea.
The <none> partition is included at the end of every CSS you create, so anything in the <none> partition is reachable by all DNs / Patterns.
The <none> CSS, only contains the <none> partition, so you can call only DNs / Patterns in the <none> partition.

You can read the whole technical explanation here: Calling Privileges in Unified CM

Go to CUCM Dial Plan and Call Routing FAQ Content Table

I get an error about 512 characters when configuring a CSS, why is that??

This is due to the fact that the CUCM DB does not allow more than 512 characters in the DB per CSS, related bug: CSCsb16203 CM Should Allow CSS to have Partitions that exceed 512 characters.
The concatenated partitions from the CSS should not exceed 512 characters, including the separator character ":", which goes between each partition, in total, the line and device CSS cannot exceed 1024 characters.

NOTE The above only applies to older CUCM releases, but I though of adding this just in case someone runs into it.

Go to CUCM Dial Plan and Call Routing FAQ Content Table

How can I add a prefix to my incoming calls for callback??

Well, this depends on the protocol, there is an old doc that explains how to do this with PRIs:
Add Prefix to the Missed Call Number

The first method still works, but with globalization, it's not so manageable to do it.

As for the second method and the related parameters, they still exist under CCM Service parameters:

Incoming Calling Party National Number Prefix - MGCP This parameter defines the number, up to 16 digits, that is prefixed to an incoming national number, and provides a means to help you identify national numbers, if necessary. This parameter allows you to prefix specified digits to the calling number of an inbound call on the basis of the Type of Number field in an inbound offered call. It also allows you to strip a specified number of leading (starting from the left-hand side) digits for the incoming calling party number before prefixing it. The digits to strip can be specified as x:y where x represents the prefix and y represents the number of digits to be stripped; the colon is required to act as a separator between the prefix and the number of digits to be stripped. For example, 91010:6 which means that the prefix is 91010 and the number of leading digits to strip is 6. In this example, a national call from 2145551234 would get updated to 910101234.The maximum number of leading digits that can be stripped is 24 and the maximum number of digits that can be prefixed is 16.

When the prefix in this parameter is applied to the incoming calling party number at the MGCP device level, Cisco Unified Communications Manager includes the prefix in the calling party number field for all additional actions pertaining to the call, such as supplementary services including call forwarding, call park, etc., voice messaging, and CDR data. Several additional service parameters provide prefix functionality on the IP Phone side and the incoming gateway side for H.323 and SIP. See the Clusterwide Parameters (Device - Phone) section and the related gateway-specific sections in the Service Parameter Configuration window for more information.

Maximum length: 19
Allowed values: The maximum number of leading digits that can be stripped is 24 and the maximum number of digits that can be prefixed is 16. A colon is required to act as a separator between the prefix and the number of digits to be stripped. For example, 91010:6 which means that the prefix is 91010 and the number of leading digits to strip is 6. In this example, a national call from 2145551234 could get updated to 910101234. Valid characters include (0-9,#,*,+,:)

Incoming Calling Party International Number Prefix - MGCP This parameter defines the number, up to 16 digits, that is prefixed to an incoming international number, and provides a means to help you identify international numbers, if necessary. This parameter allows you to prefix specified digits to the calling number of an inbound call on the basis of the Type of Number field in an inbound offered call. It also allows you to strip a specified number of leading (starting from the left-hand side) digits for the incoming calling party number before prefixing it. The digits to strip can be specified as x:y where x represents the prefix and y represents the number of digits to be stripped; the colon is required to act as a separator between the prefix and the number of digits to be stripped. For example, 91010:6 which means that the prefix is 91010 and the number of leading digits to strip is 6. In this example, a national call from 2145551234 would get updated to 910101234.The maximum number of leading digits that can be stripped is 24 and the maximum number of digits that can be prefixed is 16.

When the prefix in this parameter is applied to the incoming calling party number at the MGCP device level, Cisco Unified CallManager includes the prefix in the calling party number field for all additional actions pertaining to the call, such as supplementary services including call forwarding, call park, etc., voice messaging, and CDR data. Several additional service parameters provide prefix functionality on the IP Phone side and the incoming gateway side for H.323 and SIP. See the Clusterwide Parameters (Device - Phone) section and the related gateway-specific sections in the Service Parameter Configuration window for more information.

Maximum length: 19
Allowed values: The maximum number of leading digits that can be stripped is 24 and the maximum number of digits that can be prefixed is 16. A colon is required to act as a separator between the prefix and the number of digits to be stripped. For example, 91010:6 which means that the prefix is 91010 and the number of leading digits to strip is 6. In this example, a national call from 2145551234 could get updated to 910101234. Valid characters include (0-9,#,*,+,:)

Incoming Calling Party Subscriber Number Prefix - MGCP This parameter defines the number, up to 16 digits, that is prefixed to an incoming Subscriber number, and provides a means to help you identify Subscriber numbers, if necessary. This parameter allows you to prefix specified digits to the calling number of an inbound call on the basis of the Type of Number field in an inbound offered call. It also allows you to strip a specified number of leading (starting from the left-hand side) digits for the incoming calling party number before prefixing it. The digits to strip can be specified as x:y where x represents the prefix and y represents the number of digits to be stripped; the colon is required to act as a separator between the prefix and the number of digits to be stripped. For example, 91010:6 which means that the prefix is 91010 and the number of leading digits to strip is 6. In this example, a national call from 2145551234 would get updated to 910101234.The maximum number of leading digits that can be stripped is 24 and the maximum number of digits that can be prefixed is 16.

When the prefix in this parameter is applied to the incoming calling party number at the MGCP device level, Cisco Unified CallManager includes the prefix in the calling party number field for all additional actions pertaining to the call, such as supplementary services including call forwarding, call park, etc., voice messaging, and CDR data. Several additional service parameters provide prefix functionality on the IP Phone side and the incoming gateway side for H.323 and SIP. See the Clusterwide Parameters (Device - Phone) section and the related gateway-specific sections in the Service Parameter Configuration window for more information.

Maximum length: 19
Allowed values: The maximum number of leading digits that can be stripped is 24 and the maximum number of digits that can be prefixed is 16. A colon is required to act as a separator between the prefix and the number of digits to be stripped. For example, 91010:6 which means that the prefix is 91010 and the number of leading digits to strip is 6. In this example, a national call from 2145551234 could get updated to 910101234. Valid characters include (0-9,#,*,+,:)

Incoming Calling Party Unknown Number Prefix - MGCP This parameter defines the number, up to 16 digits, that is prefixed to an incoming Unknown number, and provides a means to help you identify Unknown numbers, if necessary. This parameter allows you to prefix specified digits to the calling number of an inbound call on the basis of the Type of Number field in an inbound offered call. It also allows you to strip a specified number of leading (starting from the left-hand side) digits for the incoming calling party number before prefixing it. The digits to strip can be specified as x:y where x represents the prefix and y represents the number of digits to be stripped; the colon is required to act as a separator between the prefix and the number of digits to be stripped. For example, 91010:6 which means that the prefix is 91010 and the number of leading digits to strip is 6. In this example, a national call from 2145551234 would get updated to 910101234.The maximum number of leading digits that can be stripped is 24 and the maximum number of digits that can be prefixed is 16.

When the prefix in this parameter is applied to the incoming calling party number at the MGCP device level, Cisco Unified CallManager includes the prefix in the calling party number field for all additional actions pertaining to the call, such as supplementary services including call forwarding, call park, etc., voice messaging, and CDR data. Several additional service parameters provide prefix functionality on the IP Phone side and the incoming gateway side for H.323 and SIP. See the Clusterwide Parameters (Device - Phone) section and the related gateway-specific sections in the Service Parameter Configuration window for more information.

Maximum length: 19
Allowed values: The maximum number of leading digits that can be stripped is 24 and the maximum number of digits that can be prefixed is 16. A colon is required to act as a separator between the prefix and the number of digits to be stripped. For example, 91010:6 which means that the prefix is 91010 and the number of leading digits to strip is 6. In this example, a national call from 2145551234 could get updated to 910101234. Valid characters include (0-9,#,*,+,:)

A similar set of settings exist for H.323, as well as just one for SIP, for calls with unknown numbers. On 10.5(2) you can even find some for phone level. If you don't see any of these, click on Advanced at the top of the page.
In any case this work based on the info you get in the setup message in order to choose which call to tag, and with what prefix, the below example is for an outgoing call, but you can see the calling party was showing up as National, and if you configured it, since it's an international call (011) you could set it up as international. The other end might see your calling info as an International call as well.

Jun 29 09:42:07: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x0004
       Bearer Capability i = 0x8090A2
               Standard = CCITT
               Transfer Capability = Speech
               Transfer Mode = Circuit
               Transfer Rate = 64 kbit/s
       Channel ID i = 0xA98397
               Exclusive, Channel 23
       Calling Party Number i = 0x2181, 'XXXX'
               Plan:ISDN, Type:National
       Called Party Number i = 0x81, '011XXXXXXXXX'
               Plan:ISDN, Type:Unknown

But, this days you hear about SIP trunks more and more, and this does not work with SIP trunks as they do not send anything similar, so, how to do this with SIP trunks??
You use calling / called party transformations in order to achieve the same result. They offer the same flexibility as Translation Patterns but do not actually change the call routing, just the call presentation. This method also works with any other kind of PSTN trunk you can have.

Go to CUCM Dial Plan and Call Routing FAQ Content Table

How to configure a PLAR and how does it work??

For most endpoints, this link has the instructions for this to work:
Hotdial on IP Phones with CallManager Configuration Example

The document is quite old, but the theory for how it works is still the same, you hit the blank TP the moment you pick up the handset and it will dial a pre-defined destination for you.

For many of the new SIP endpoints the above will not work, and you need to create a SIP dial rule for this to work.

  1. CCMadmin -> Call Routing -> Dial Rules -> SIP Dial Rules -> Add New
  2. For most phones choose Dial Pattern = 7940_7960_OTHER -> Next
  3. Fill in the name and description -> Save
  4. Under Pattern Addition type a name for the pattern, PLAR_office for example -> Add Plar
  5. Make sure it's correctly added and that under Dial Parameter it shows: Pattern and that the Value field is empty

Once it's created, go to the device and under Protocol Specific Information area, set the SIP Dial Rules value to the one you just created.
It will also rely on the regular PLAR config above, we're merely telling the phone to dial immediately when it matches a blank pattern.

UPDATED 6/8/2018
Here you can find an updated set of instructions for SCCP and SIP devices: CUCM PLAR Configuration Example

Go to CUCM Dial Plan and Call Routing FAQ Content Table

For a greenfield deployment, should I design an E.164 dial plan??

Yes, this is the recommended approach as it will in turn make many other configurations not necessary, or will make their configuration a lot easier.
If you have ILS / GDPR with other clusters, this will facilitate calls on-net, or over the PSTN.
AAR configuration will only require the right set of CSS as no transformation will be required.

UPDATED 6/26/2018
Some related training:

Go to CUCM Dial Plan and Call Routing FAQ Content Table

Should I leave all my DNs in the <none> partition??

No, even for a small deployment, that is a very bad design, you should always create at least some basic set of partitions for on-net Vs. off-net calls.

Go to CUCM Dial Plan and Call Routing FAQ Content Table

When should I get the secondary dial tone??

This is topic that I often see and on which I got plenty of cases back in TAC. There's a lot of confusion around this.
When should you get it??
Well, that entirely depends on your config. First, some myths about this:

  • Only route patterns and translation patterns affect it

NOPE completely wrong, ANY DN or pattern from CUCM can affect the behavior of the secondary dial tone

So... when should you get it??
As you dial the digits, they're sent to CUCM Digit Analysis engine, the DA already knows what your final CSS look like (built from line and device CSS), so it begins to look for elements within that dialing space you can reach, as you dial each digit, it starts removing any DNs / patterns that will not match what you're dialing, until (ideally) it should find only one match for the call to be placed.
Most dial plans have a digit like 9 set as the outside line code, so, you'll use them in route patterns. ONLY route patterns and translation patterns have the option to "Provide secondary dial tone". As the DA starts to discard DNs and patterns you will not match, when ALL the possible patterns have the "Provide secondary dial tone" option checked, THEN you will get that secondary dial tone.

That's the reason why if you decided to use 9 as an outside line access code, you should NOT configure anything else that starts with 9. Bear in mind that CUCM's DA not only uses digits, it also uses wildcards, so, if you have a DN with X111, [1,2,8,9], [7-9], etc. and it has the possibility to match 9, you will NOT get the tone after you hit 9.

I got plenty of cases on which someone had the marvelous idea of configuring a new DN on a phone that was 9 something, and then they would break this. And they thought that since it was a DN, it would not affect anything else.

So, if you're not getting the secondary dial tone when you want it, your best friend is the route plan report to find out exactly what you might be matching, and ALWAYS remember, you're not only looking for something that starts with 9, you're looking for ANYTHING (wildcard included) that CAN match 9. DNA is also a good option to pin-point what you are matching.

UPDATED 6/26/2018
You can run the following SQL query to find which patterns do have the Provide Outside Dial Tone enabled in your CUCM:

admin:run sql ccm select dnorpattern from numplan where outsidedialtone = 't'

You can fine tune it by searching the pattern, for example, all patterns that start with 9:

admin:run sql ccm select dnorpattern, outsidedialtone  from numplan where dnorpattern like '9%'

Go to CUCM Dial Plan and Call Routing FAQ Content Table

What is a shared line??

A shared line is a unique combinations of DN and partition which is configured in more than one device, only one device should have the DN as the primary DN for that device, and it should show as a secondary DN in any other phones. This DN will ring in all phones which have it configured and they share most of their configuration. One thing they don't share, is the Maximum Number of Calls and Busy Trigger, those are handled independently in each device.
You can use this to configure Barge or cBarge to automatically conference you into a call from the shared line, or to monitor the status of the line.

Go to CUCM Dial Plan and Call Routing FAQ Content Table

Why do I have a line CSS and a device CSS??

The main focus for having a line CSS, and a device CSS, was for a differentiated class of service on which you defined what you could NOT dial at the line level.

The whole explanation can be found here: Building Classes of Service for Unified CM

If you configure both CSS, you resulting CSS is the elements of both combined, with the partitions from the line CSS having a higher preference than those of the device CSS.

Go to CUCM Dial Plan and Call Routing FAQ Content Table

How does the DA from CUCM decides where to route the call??

CUCM uses best match logic to route calls, it's a very common misconception that the order of the partitions in a CSS takes precedence over the DA process, and that is COMPLETELY WRONG.
CUCM will ALWAYS use the best match logic to try and route the calls.
The ONLY scenario on which the order of the partitions in a CSS would matter, is:

  • When 2 (or more) DNs or patterns have the exact same number of matches

For example, if you have DN 222X in partition A, and 2222 in partition B, and both in the same CSS. If you dial 2222, you'll hit 2222 in partition B, despite partition A being higher in the CSS. If we change 222X to 2222 in partition A and dial 2222, then we will hit 2222 from partition A, this also makes it impossible for us to reach 2222 on partition B.

Go to CUCM Dial Plan and Call Routing FAQ Content Table

How can I find which Route Patterns / Translation Patterns have the secondary dial tone option checked??

Someone posted this on CSC and it's a really nice explanation on working with CLI and getting this info.

You can see the route patterns and translation patterns that have secondary dial tone enabled by using the following query from the command line:

run sql select dnorpattern,outsidedialtone from numplan

Since the above may give you more data than you care to process, you could also use:

run sql select dnorpattern,outsidedialtone from numplan where outsidedialtone='t'

The patterns presented by the second query have secondary dial tone enabled.

If you truly want to disable secondary dialtone "entirely" then you can do so with an update query. But you want to make sure you really want to disable secondary dialtone. The following query would do it. Disclaimer: use at your own risk because there is no going back. I'd recommend that you first log what patterns have secondary dialtone so you can undo manually.

run sql select pkid,dnorpattern,outsidedialtone from numplan where outsidedialtone='t'

Save the above output to a text file as a snap shot of what patterns had the secondary dialtone enabled. Then you can use the following to completely remove secondary dialtone:

admin:run sql update numplan set outsidedialtone='f' where (outsidedialtone='t') and (tkpatternusage=5 or tkpatternusage=6)

The above will set the outsidedialtone to 'f' (false or disabled) where:

(a) The outsidedialtone is 't' (true or enabled) AND
(b) The pattern is a route pattern or a translation pattern

Be careful when doing SQL updates.

Go to CUCM Dial Plan and Call Routing FAQ Content Table

Can I provide a notification to calling party that called party is already in another call??

No, CUCM has no method of telling you that the called party is already in another call, some options would be:

  • Presence enabled directories
  • BLF / SD
  • Jabber

UPDATED 6/26/2018
The main request for this is to provide an audio or visual indication that the called party is already on a call, however, if you're not hitting the CFB and you have a busy greeting in CUC, you would not get any indication. Any call that is below the busy trigger will ring on the phone, and you will get no indication the user is already on another call.

Go to CUCM Dial Plan and Call Routing FAQ Content Table

Can I change the ring tone for music??

No, CUCM provides no way to change the ring tone for music, or any other media.

Go to CUCM Dial Plan and Call Routing FAQ Content Table

How to configure ILS and GDPR??

If you're not aware of GDPR, you can review it here:

The configuration is rather easy:

We'll assume you have a cluster which URIs are ciscoA.com and another one on ciscoB.com, we'll be doing the config from the ciscoA.com side. You will need to configure a SIP trunk to the other cluster, I assume you know how to do this, so I'll assume one is already configured and working. The SIP trunk we'll be using on ciscoA.com will be pointing to ciscoB.com IP or hostname.

  1. CCMadmin -> System -> Enterprise Parameters
  2. Make sure each cluster has a UNIQUE Cluster ID parameter configured.
  3. CCMadmin -> Call Routing -> Sip Route Pattern -> Add New
  4. We'll use the following settings:
    • Pattern Usage = Domain Routing, IPv4 Pattern = ciscoB.com, set the proper Route Partition and the SIP Trunk / RL for our SIP trunk pointing to ciscoB.com
  5. Click Save
  6. CCMadmin -> Advanced Features -> ILS Configuration
  7. Choose the Role as Hub Cluster
  8. If you want to enable GDPR, check the option for Exchange Global Dial Plan Replication Data with Remote Clusters
  9. Under Advertised Route String configure domain for which you're going to be advertising. In our scenario, it would be ciscoA.com
  10. Under ILS Authentication if you have all your servers signed with your internal CA, you can use Use TLS Certificates, otherwise, you can simply use the Use Password option and type in your desired password. You can also choose Use TLS Certificates with the built-in certificates, but in such case, you will need to exchange the Tomcat certificates between the clusters.
  11. Click Save

If you wish other clusters to register as a spoke to a particular cluster, you will need to click on the Register to Another Hub... option under the ILS Configuration page.

Once you're done, in the ILS Configuration page you should see at the bottom: ILS Clusters and Global Dial Plan Imported Catalogs, and you should see your own cluster and the other cluster(s) listed there.

How can you make sure this is actually working??
CCMadmin -> Call Routing -> Global Dial Plan Replication and you can look into Learned Directory URIs, Learned Numbers or Learned Patterns. If you checked this on the ciscoA.com server, you should only see URIs from ciscoB.com there.

Under the DN configuration page you will find several checkboxes for Advertise Globally via ILS you use to configure what you want to publish via ILS

Go to CUCM Dial Plan and Call Routing FAQ Content Table

What is DNA (Dialed Number Analyzer)??

DNA is a small application that is within CUCM which can assist you in finding problems within your dial plan, you can input certain conditions as if you were dialing from a certain DN, to some DN / pattern, and it will tell you how the call should be routed based on the DB info. It's important to notice that the actual call routing is done based on what the CUCM has on current memory, that's the reason why the more routing elements you have, the longer it takes to initialize. There might be certain circumstances under which you will see a different behavior for a real call Vs. a DNA call, and most likely the runtime data is not up to date with the info in the DB, usually a CCM restart, or a server reboot fixes that.

Go to CUCM Dial Plan and Call Routing FAQ Content Table

Can I limit the time for my calls??

There is a CCM service parameter that controls the time for ALL calls (Maximum Call Duration Timer), by default, it's configured for 720 minutes. If you wish to control the time for:

  • Outbound calls
  • Calls for certain users
  • Provide users with a certain amount of call time per month / week / day

None of those are possibilities within CUCM. If you wish to set a maximum time for outbound calls and / or for certain users (also outbound), you would need to look into TCL scripting for those features. I will not cover the topic of TCL development, if you wish assistance, you may reach the Developer Support team at Cisco.

Go to CUCM Dial Plan and Call Routing FAQ Content Table

Can I limit who my users can transfer calls to??

The only way to set that, is via the CCM service parameter "Block OffNet To OffNet Transfer Required Field", however, this only prevents outbound calls, to be sent back to outbound destinations. For internal transfers, the same CSS you use to place calls, is used for transfers. Which effectively means that if you wish to block a transfer to certain DN, you would lose all ability to call the DN, not only for transfers.

Go to CUCM Dial Plan and Call Routing FAQ Content Table

How to configure ToD (Time Of Day) routing??

You can find plenty of information about this on the Cisco Support Community, and there is even a Youtube video on this: CCNP Voice CUCM Dial Plan Digit Addressing, Time of Day ToD, Hunt Group Coverage, FAC, CMC, Auto

The Cisco documentation covers ToD under the system guide: Time-of-Day Routing

So, how does this work??

Well, first of all, you probably want to create two new partitions for the DNs on which you want to use it, you'll understand why you don't want to have other devices sharing the same DN later.

ToD enables our CSS to be "dynamic", this means that the partition on which we apply the Time Schedule will appear, or disappear from the CSS, as required. That's the reason you want to separate the DNs over which you want ToD to happen, in a separate partition. If you keep them in your regular "internal" partition along with your other 1000+ phones, you'll be causing a lot of trouble when that partition disappears from their CSS.

So, let's say you have 1111/worktime and 1111/offhours, you already created your Time Periods, 9-5 for worktime, the rest of the day for offhours, and have two Time Schedules, and you associate them accordingly. Then you would need to add wortime and offhours partitions to the CSS of the devices who will be routed to one , or the other, depending on the time of their call. The order does not really matter, as only one will be available at any given time. And... you're done, that's ToD in a nutshell.

Please notice that ToD is still affected by best match routing, so if you want to configure a DN / pattern with wildcards, you need to make sure that there is nothing in your dial plan, at that time, which is a best match.

UPDATED 6/8/2018
I created a video in which I explain the theory behind ToD, and how it interacts with the CSS/partitions in order to work properly. Most of the issues are due to not properly understanding call routing in CUCM: How Time of Day Routing works (ToD) and configuration

Go to CUCM Dial Plan and Call Routing FAQ Content Table

What can I check if CFA is not working??

A document on the topic already exists, although it's a bit old, most of the reasons are still valid:

In newer releases you need to make sure to choose the right CSS Activation Policy for the calls to work.

Go to CUCM Dial Plan and Call Routing FAQ Content Table

Why is there a delay before my call is placed??

The most likely reason, is that you have overlapping in your dial plan, what does that mean?
Examples of that, is having an internal 4 digit dial plan, unique numbers, and a route pattern which is XXXXX, what happens if they're both in your CSS, is that CUCM thinks "OK, there is a phone that has the DN 1111 that he has dialed so far but there is a route pattern that can also match 1111 plus one more digit, I'll wait to see what he does" and CUCM will wait 15 seconds (by default) until the T302 timer (inter-digit time-out) expires, before understanding that you actually only wanted to dial 4 digits. Why can't CUCM send the call right away??? because it's an application, not a mind reader!!!, how do you possibly expect CUCM to know that?? ? What if it was the other way around??? You actually wanted to dial 5 digits and you suddenly find yourself calling an internal DN???
In the end, it's really not CUCM's fault, it's whoever configured and / or designed the dial plan. CUCM provides that timer as the way in which it will wait for you to dial more digits, if you're reading them from your screen, for example. Or if you're simply a slow kind of guy.

So, how do you fix this??
The only real fix, is to change the dial plan to avoid any kind of overlapping, an alternative "fix" would be to decrease the T302 timer, but this also means CUCM might try to send the calls before you have actually finished to dial the numbers. Another alternative, which would require user intervention, is to configure the DNs and patterns with # at the end, once the users dial the number, and press #, they're indicating CUCM they have finished entering the digits.

You need to be very careful when you're designing a dial plan, if you're going for an E.164 dial plan, there are very low chances you'll run into this, if you're not, and you want a 2, 3 ,4 digit dial plan, remember:

  • Always leave room for growth, if you want a 4 digit dial plan for a company with 4000 employees, chances are you might run out of DNs and will need to change that into a 5 digit plan.
  • Avoid by all means, using the same digit you'll use for outside calls, or intersite calls for any other use. The most common choices are 9 for PSTN access, and 8 for inter-site calls. On the above scenario, if you do this, you would have realized a 5 digit dial plan would be required if you leave 9 and 8 reserved.
  • If you need to design a multi-site dial plan, just as with the number of employees, choose a number of digits for the site code that allows for growth.
  • You can use * for internal services or special use.

Reference links:

Go to CUCM Dial Plan and Call Routing FAQ Content Table

Is there anyway in which I can listen to a call from my phone??

The only way to do this with the out of the box features of CUCM is to use Barge and / or cBarge, however, these two features are not the silent monitoring you might be looking for, what you would be doing, is creating a 3 way conference. And the caveat for that to happen, is that it requires to be in a shared line, meaning, you would need to have a shared line with every employee you want to do this with.

UPDATED 6/8/2018
This requirement usually comes from Call Centers, and such is a UCC feature called silent monitoring which has other requirements aside from CUCM. There may also be some 3rd party options which might offer this feature without deploying a full UCC solution.

Go to CUCM Dial Plan and Call Routing FAQ Content Table

Can I play a message for incoming calls prior to the phone ringing??

No, CUCM does not offer this feature. In order to do this, you would have a few options, as they require custom scripting, I will not cover them:

  • TCL script, if you have H.323 or SIP, you can build a TCL script that plays the message, then send the call over to CUCM
  • UCCX / UCCE, just as the TCL script, but you would need to route the calls from CUCM to UCC, play the message, then route back to CUCM
  • CUC, it's possible, but it's far from being manageable, you would need to set the call routing so that external calls go to CUC, you would need to do this for every single DN, as CUC doesn't have the ability to remember numbers for call routing, the call flow would be: PSTN -> GW -> CUCM -> CTI RP 1111 with CFA to VM -> CUC 1111 call handler -> Play message -> Send back call to CUCM DN 1111. This also involves carefully planning CSS and partitions so that only the GW can reach the CTI RP. I would not recommend this.

A working alternative if you have CUCM 9.x+, albeit not something you would do for all your users (very similar to the CUC method), is to use the queuing mechanism from CUCM, user carlnewton from CSC tried my suggestion, and was kind enough to post how he did it:

I did the following:

  1. Hunt list with no members
  2. Hunt pilot on 2802 only accessible by the MGCP gateway
  3. Hunt pilot with queuing enabled, with a MOH source set with an announcement to be played before the call queues
  4. Hunt pilot set to divert all calls to 2802 when no hunt group members logged in on a CSS that can only access the 2802 handset and not the hunt pilot
  5. What happens is the call comes in the gateway, hits the hunt pilot, plays the announcement BEFORE sending to the hunt group. It then tries to route the call, finds the hunt group has no members and so diverts it to the users handset.

Go to CUCM Dial Plan and Call Routing FAQ Content Table

How to change the ANI (calling number) I send to the PSTN??

This can be done in several areas in your CUCM.

  • External Phone Number Mask
  • Route Pattern
  • Route List
  • GW/Trunk

Where to perform the change will depend on the specific requirements of your deployment, the most common configuration is to configure the External Phone Number Mask or the Calling Party Transformation Mask in the Route Pattern to achieve this.

Go to CUCM Dial Plan and Call Routing FAQ Content Table

I configured AAR, and calls are not re-routing over PSTN when WAN fails??

Because AAR is not a mechanism for WAN failures, AAR is meant for CAC overflow. The only reason AAR will re-route a call, is when your locations run out of bandwidth.

Go to CUCM Dial Plan and Call Routing FAQ Content Table

I configured SNR and want to have two schedules for my Remote Destinations, is it possible??

Unfortunately no, you can only configure one schedule per Remote Destination

Go to CUCM Dial Plan and Call Routing FAQ Content Table

Can I dial to IP addresses from endpoints registered in CUCM??

Yes, you can follow the instructions outlined in this link:

Go to CUCM Dial Plan and Call Routing FAQ Content Table

Is there any way the phone recalls my FAC / CMC for regularly dialed numbers??

Not natively, as otherwise this would actually defeat the purpose of the feature, at least in my opinion. But there is a 3rd party app that can do that:

Go to CUCM Dial Plan and Call Routing FAQ Content Table

I configured a line group and their members have CFA to a PSTN number, but they still ring??

Yes, this behavior is WAD (Working As Designed), any call forward behavior configured for the line group members will be ignored for calls that are extended to them via the hunt pilot. If you wish to reach another external destination, you would need to configure the member(s) with SNR so the call is extended to the internal DN, and the remote destination.

UPDATED 6/8/2018
This holds true for any call forward behavior and any destination, the most common usage scenario is CFA to an external number where members of a line group want calls to be sent to their mobile.

Go to CUCM Dial Plan and Call Routing FAQ Content Table

Are there any 3rd party options to improve / enhance call routing within CUCM??

Yes, and as I find different options, I'll list them here, because you can do some pretty neat stuff with them.

SmartRoute

  • Allows you to configure call routing based on presence from your IM&P/Jabber client
  • Enables the ability to follow you, as you roam. For example, a doctor that moves within a hospital, can swipe/read his ID card on the room, and the calls directed to this number would follow him, until he logs out.
  • Enables the ability to do LDAP lookups to present information of the calling party on the device.
  • Can be configured per user, and the user has the ability to configure their own routing.
  • Allows routing based on full/partial calling/called numbers.

UPDATED 6/8/2018
CUCM has the ability to delegate some of the call routing to external entities using the External Call Control Profile option, this requires custom programming to alter the default routing behavior.

Go to CUCM Dial Plan and Call Routing FAQ Content Table

What are the limits regarding hunt pilots and line groups??

  • A single Unified CM Cluster supports a maximum of 15,000 hunt list devices.
  • A single Unified CM Subscriber supports a maximum of 100 hunt pilots with call queuing enabled per node
  • Hunt list devices may be a combination of 1500 hunt lists with ten IP phones in each hunt list, 750 hunt lists with twenty IP phones in each hunt list, or similar combinations
  • The maximum number of simultaneous callers in queue for each hunt pilot that you can configure ranges from 1 to 100 (default 32).
  • The maximum wait time in queue for each hunt pilot that you can configure ranges from 0 to 3600 seconds (default 900). An increase in the number of hunt lists can require you to increase the dial plan initialization timer that is specified in the Unified Communications Manager service parameters. We recommend that you set the dial plan initialization timer to 600 seconds if you have 1500 hunt lists configured.
  • We recommend having no more than 35 directory numbers for a single line group when using broadcast algorithms with call queuing. Additionally, the number of broadcast line groups depends on the busy hour call completion rate (BHCC). If there are multiple broadcast line groups in a Unified CM system, the number of maximum directory numbers in a line group must be less than 35. The number of busy hour call attempts (BHCA) for all the broadcast line groups should not exceed 35 calls set up per second.

Performance and Scalability for Hunt Pilots

Go to CUCM Dial Plan and Call Routing FAQ Content Table

How do you configure a DID in CUCM??

We need to start by explaining that CUCM is completely unaware of what a DID is. CUCM doesn't know, and doesn't care.
CUCM only know how to route calls based on the dial plan and call routing that you have configured.

Lets use 1 222 333 4444 as an example.
Most usually you buy / contract blocks of DIDs, for example, you got 1000 numbers, so you have 1 222 333 0000 through 1 222 333 9999 available for your organization.

The telco will configure the routing on their side and deliver you the calls with whatever technology you chose, or the telco offered. It may be FXO, PRI, SIP trunk, etc. or you might use another combo, like an FXO with a GSM gateway. This also doesn't matter to CUCM.

Telco will deliver you the calls with a certain number of digits, and this might vary, for our example lets assume we get four digits. So, when someone dials 1 222 333 4444, the telco will present us a call to 4444. If you want / need +- digits, you will need to discuss that with telco. You need to know how many digits the telco delivers.

You will use a GW to connect with your telco, and I will not discuss the GW configuration in detail, this will depend on technology and protocol used.
In any case, you will need either dial peers to route the calls to CUCM, or leave to CUCM all the call routing.

As SIP is one of the most common choices these days, we'll assume you have a SIP trunk.
You will have a voip dial peer with a destination pattern of only 4 digits pointing towards your CUCM.

On CUCM you will have a SIP trunk configured pointing to the GW. Under the Inbound Calls section of the trunk, you will need to, at the very least, configure the CSS for the calls.
There are various parameters that can assist with digit manipulation, like Significant Digits and Prefix DN, but in our scenario we will not need them.

Now, we're basically done. All that's left is to configure WHATEVER YOU WANT with a DN or pattern of 4444. And I do mean that, it could be a DN associated to a phone, a meet-me, conference now, a CTI RP, etc. As far as CUCM in concerned, 4444 is just another part of the dial plan. Whether it might be a DID, or a DN that only one individual can reach.

And you're done, you've configured a DID in CUCM.

Was the above any different from any other DN / pattern you have configured in CUCM??
Pretty sure you'll answer it wasn't, and that's because CUCM has no special configuration for a DID.

On this simple example we didn't use any digit manipulation, but depending on the scenario, it might be required. For example, telco can only deliver seven digits, while your dial plan is only four digits long. Or you use E.164 and they deliver less digits. Depending on the protocol, you can perform this in the GW or in CUCM, your choice.

My scenario would most likely be a greenfield deployment where you can build the dial plan from scratch and match the DIDs the telco assigned to the internal numbers. In some brownfield deployments you might need to perform digit manipulation to adjust from what is dialed externally and the actual internal DN that will get the call. I've seen anywhere from having to change a few digits, to a complete different number.

I hope this will clarify why adding a DID, is not a special configuration.

Go to CUCM Dial Plan and Call Routing FAQ Content Table

Back to Unified Communications FAQ
Back to CUCM FAQ

Contact:
Any comments, questions, suggestions, contributions, etc. please send them to javalenc@cisco.com. Please make sure the subject is formatted "UC FAQ <anything else>" as I'll have rules in my mail to match them, otherwise, they'll end up in my spam folder.

Rating: 4.4/5 (5 votes cast)

Personal tools