topic Re: Unassigned DID numbers going to one extension in IP Telephony and Phones

Unassigned DID numbers going to one extension

robandover385 — Wed, 24 May 2023 13:43:13 GMT

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.

Re: Unassigned DID numbers going to one extension

Maren Mahoney — Wed, 24 May 2023 14:07:12 GMT

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.

Maren

Re: Unassigned DID numbers going to one extension

Roger Kallberg — Wed, 24 May 2023 14:29:00 GMT

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.

Re: Unassigned DID numbers going to one extension

robandover385 — Wed, 24 May 2023 14:34:58 GMT

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?

Re: Unassigned DID numbers going to one extension

robandover385 — Wed, 24 May 2023 14:58:37 GMT

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.

Re: Unassigned DID numbers going to one extension

Maren Mahoney — Wed, 24 May 2023 14:59:31 GMT

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.

Maren

Re: Unassigned DID numbers going to one extension

Maren Mahoney — Wed, 24 May 2023 15:02:48 GMT

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.

Maren

Re: Unassigned DID numbers going to one extension

robandover385 — Wed, 24 May 2023 16:18:46 GMT

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.

Re: Unassigned DID numbers going to one extension

Maren Mahoney — Wed, 24 May 2023 18:12:52 GMT

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.

Maren

Re: Unassigned DID numbers going to one extension

Roger Kallberg — Wed, 24 May 2023 18:24:05 GMT

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.

Re: Unassigned DID numbers going to one extension

robandover385 — Wed, 24 May 2023 18:32:05 GMT

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

Re: Unassigned DID numbers going to one extension

Roger Kallberg — Wed, 24 May 2023 19:28:11 GMT

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.

Re: Unassigned DID numbers going to one extension

Maren Mahoney — Wed, 24 May 2023 20:07:16 GMT

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

Re: Unassigned DID numbers going to one extension

robandover385 — Wed, 24 May 2023 20:10:28 GMT

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

Re: Unassigned DID numbers going to one extension

robandover385 — Wed, 24 May 2023 20:19:22 GMT

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.

Re: Unassigned DID numbers going to one extension

Roger Kallberg — Wed, 24 May 2023 20:26:02 GMT

The SDL traces are also known by Call Manager traces. It includes details on the call processing. On the debugs it depends on what type of connection you have towards PSTN. As a start you can enable debug ccsip message and debug voip ccapi inout as you have a SIP trunk towards CM.

Re: Unassigned DID numbers going to one extension

robandover385 — Wed, 24 May 2023 20:32:35 GMT

Thanks, I'll start with thoes. How would I be able to find out the type of connecttion we have towards our PSTN? I know all of phones are VOIP but then looking at the gateway our interfaces have media-type rj45 on gigabit ports.

Re: Unassigned DID numbers going to one extension

Roger Kallberg — Thu, 25 May 2023 05:01:37 GMT

You will see that in the configuration in the router. Please share the running configuration if you don’t know how to.

Re: Unassigned DID numbers going to one extension

robandover385 — Thu, 25 May 2023 12:28:28 GMT

Re: Unassigned DID numbers going to one extension

Roger Kallberg — Thu, 25 May 2023 13:39:03 GMT

You have a SIP trunk to PSTN. Not related to your question directly, but I would recommend that you do these changes to your configuration.

!**Reference info** !voice class server-group 1 ! ipv4 172.17.XXX.XX preference 2 ! ipv4 172.17.XXX.XX preference 1 ! description *** CUCM Servers *** !! !voice class server-group 2 ! ipv4 198.241.XX.XXX preference 2 ! ipv4 198.241.XX.XXX preference 3 ! description *** IdeaTek SIP Servers *** !**Reference info** !Take all the IPs from the voice class server-group 1 and put into this, if you have more CPE CM nodes add those as well voice class uri CUCM sip host ipv4:172.17.XXX.XX host ipv4:172.17.XXX.XX !Take all the IPs from the voice class server-group 2 and put into this voice class uri PSTN sip host ipv4:198.241.XX.XXX host ipv4:198.241.XX.XXX !Use information in the VIA header to match the inbound direction dial-peer voice 100 voip no incoming called e164-pattern-map 1 incoming uri via PSTN ! dial-peer voice 200 voip dtmf-relay rtp-nte sip-kpml no incoming called e164-pattern-map 2 incoming uri via CUCM

And as well remove any MGCP configuration that you have as you don't seem to be using that at all based on the shared configuration.