Showing results for 
Search instead for 
Did you mean: 

Unassigned DID numbers going to one extension


We are having an issue where we have unassigned DID phone numbers that all end up at one directory number, but then if we setup a translation patterns for that DID, then it routes to the directory we just assigned it to. We are trying to see if there is a way to have all unassigned DID numbers go to a not in service voice recording. We are running CUCM 12.5 and our voicegates are Cisco 4351 using SIP trunks. I know we have voice class pattern-maps configured on the voice gateways, as e164 ^3162184[2-8]..$ but don't know where those are getting pointed at in CUCM. I have searched for these numbers in the route plan report but they don't show up. 

1 Accepted Solution

Accepted Solutions

@robandover385 Things look much better now. After you added the huntstop command to your dial peer 150, the CUBE does not loop the call back to the provider. Instead, it sends a 404 Not Found to the provider. 

The provider does Acknowledge the CUBE's 404 Not Found message but yet again they send a new invite this time to phone number 3162184660. The only way to fix this is to contact IdeaTek and ask them to stop redirecting unsuccessful calls to 3162184660. 

Please also see the below ladder diagram of your call.



View solution in original post

51 Replies 51

Maren Mahoney
VIP Advocate VIP Advocate
VIP Advocate

If all unassigned DIDs are ending up at a single internal directory number, and if a translation pattern in CUCM is 'fixing' the problem for a single DID, this tells me you have some kind of translation pattern that is capturing all incoming numbers that do not have a more specific match (such as ! or XXXXXXXXXX) and routing it to the DN that is ringing.

You can use the Dialed Number Analyzer (and selecing "Trunk" from the menu) to track an inbound call and see how CUCM is pathing the call. (Meaning: How is it 'finding' an inbound match and reaching the DN.)

Give the DNA a try and let us know if you have questions about the output.


I ran teh Dialed Number Analyzer and attached a screenshot of the results. Can you help me get a better understanding of it, cause to me it looks like the number is going to a blocked translation pattern?

In DNA select Analysis > Trunks. Find and select the inbound trunk. Enter the calling party number and called party number shown in the SIP Invite message generated by the trunk towards CUCM. Then run the analyzer.


Roger Kallberg
VIP Expert VIP Expert
VIP Expert

As @Maren Mahoney wrote you likely have a translation pattern that is hit for the unassigned number to direct it to the one directory number. You should look at what partitions that the CSS used as the inbound calling search space on the trunk in CM “see”. In one of these PTs there is very likely a TP that matches the unassigned numbers and translates the called number to the directory number that receives the calls currently. Once you find that you can modify it to send the calls to whatever you want. DNA is as Maren wrote very handy in finding out what happens to a call based on the configuration in place. You can find out what happens without using DNA, but it requires a little more effort and also understanding on how the system operates.

Response Signature

So in CUCM under device>trunk I can see that both of our SIP trunks are using the CSS-Gateway-ALL and then when I go to Call Routing>Clas of Control>Calling Search Spaces and I go to the CSS-Gateway_All, and I see the selected partitions. And then I go to Partitions under Calling Search Space, I just see the name and description. Then I can see that all the translation patterns we have configured are using this same partition, but I don't see translation pattern setup for unassigned number.

When you go to Call Routing > Class of Control > Partitions and select a partition, you can see what objects in your dialplan are using that partition by going to "Related Links", selecting "Dependancy Records" and then clicking Go. You will see a pop up with a list of the different kinds of objects that are using that partition. My guess is that the 'offending object' is a translation pattern, but I could be wrong.


I found this but then it shows as 1691 records are using this partition This is where I have trouble finding it sine we are a school district, pretty much everything goes in this partition.

Please try the DNA again using the parameters I described above. That should tell you the inbound call flow. Let us know what you see.


I’m sorry but that screenshot doesn’t show anything that is useful. It just shows the name of the CSS that is used in the inbound direction on the trunk. You’ll need to look at each of the partitions that are in the CSS to see what translation pattern(s) these hold to find what is matching the unassigned numbers.

Response Signature

Here is a screenshot of running the DNA analysis on the trunk.

That is not the result that was expected at all. This would indicate that it’s not the CM that matches the call to unassigned numbers. Maybe you need to pull the logs from the gateway, enable the appropriate debugs beforehand and the SDL traces from the CM to be able to see what’s going on with this.

Response Signature

Is it possible that the Trunk is sending digits to CUCM in a different format like E164 or truncated to a DN?

It could be because on the gateway I can see "voice class e164-pattern-map 1" and in that list I see e164 3162184[2-8]..$ and then I see the dial-peer voice group reference the e164-pattern-map 1 in the sh run config. 

Do you happen to know what appropriate debugs I should enable on the gateway? What is the SDL traces from CM?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers