Unassigned DID numbers going to one extension

[robandover385]

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. 

[robandover385]

I redid the call and then opened the folder in the translatorx program. I attached a screenshot of the out put and also highlight one of the calls.

[Roger Kallberg]

Does that call actually ring on any device as you stated in your original post? I ask because the logs indicate that CM results in unallocated number and that would not route the call anywhere.

[robandover385]

Yes, it actuallys goes to one extension. I went to the person's desk and then called that number from my cell and it rang on their desk phone. We have multiple unassigned DID numbers that some how end up on that one extension.

[Roger Kallberg]

Can you please do the call again and capture the output from these debugs running simultaneously?

• debug ccsip message 
• debug voip ccapi inout 

That way we would see what happens in the gateway.

[robandover385]

Ya, I can do that. We have 2 gateways, do I need to run the debug commands on both? To turn off the debug commands, do I just add a no in front?

[Roger Kallberg]

To turn off all debugs you do undebug all, or u all in short. You can also turn off individual debugs by adding no in front. I trust that you know how to get the output to show in the terminal session? If not you do that by term mon and you turn it of by term no mon. I would say that it’s best if you do the debug on both.

[robandover385]

Honestly I forgot how to show the output in the terminal session, but I ran the debug commands on both of our gateways at the time of the calling the 316-218-4591 DID number and I called it from my cell the 316-494-2895 and attached the log file.

[Roger Kallberg]

Need a computer to look at the file(s) and as it’s 11 pm where I’m at I’ll look at it another day.

[Roger Kallberg]

You’re not following the instructions that @Maren Mahoney layed out for you for how to use DNA. This is what she wrote “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.”

In your screenshot you have no calling number. This could have an effect, although not all that likely. But it’s better if you where to follow the instructions given verbatim as there is a thought behind it when given.

[tylrsrh]

You are facing a challenge in routing unassigned DID phone numbers to a "not in service" voice recording in your CUCM 12.5 environment. You have already checked translation patterns, partitions, and calling search spaces in CUCM, as well as voice class pattern-maps on your Cisco 4351 voice gateways. However, you have not found the unassigned numbers in the route plan report. You should review the translation patterns and their configuration on your notebook, ensure that partition and calling search space settings are correct, and thoroughly analyze the route plan report. Additionally, consider using a route pattern instead of translation patterns

[TechLvr]

@robandover385 Based on the logs you have shared, here is what's happening. 
Your inbound call from IdeaTek matches dial peer 100 on the way in to the CUBE, and then dial peer 150 on the way out toward CUCM. Since CUCM does not find a match for this unallocated number, it responds with 404 not found. Then CUBE sends the call back to IdeaTek using dial peer 200 since it's the next best match. IdeaTek redirects the call toward the CUBE this time on line 3162184660 for some reason. 

Solution: 
The solution to this problem is very easy. All you need to do is apply the command "huntstop" to dial peer 150 as below. This command instructs the CUBE to stop looking for dial peers other than 150 if the call is meant for CUCM. This way, when the called number is unallocated, the caller will hear a recording announcing that the call cannot be completed.  

dial-peer voice 150 voip
huntstop

[Roger Kallberg]

As always @TechLvr great analysis. Apart from your advice I would also recommend to add the huntstop command to the server group by this command.

voice class server-group <tag>
 huntstop 1 resp-code 404 to 404

This will stop the call to hunt between the servers in the server group when a 404 response is received. This can be used on the server group towards PSTN as well.

What I also would suggest is to make modifications to the configuration in the gateway so that there is no chance to get into a call route loop as is what basically happens now when the call is sent back to the service provider and they send the call back again, strangely enough as you pointed out to another number. Likely the easiest way to accomplish this is to either not drop the outgoing prefix in the called number in CM, if that is used, or add a voice translation rule inbound from CM on the dial peer used in the inbound direction from CM. Something like this would work.

voice translation-rule 10
 rule 1 /\(.*\)/ /0\1/
!
voice translation-profile ADD-PREFIX-IN
 translate called 10
!
dial-peer voice 100 voip !Inbound dial peer from CM
 translation-profile incoming ADD-PREFIX-IN
!
voice translation-rule 20
 rule 1 /^0\(.*\)/ /\1/
!
voice translation-profile REMOVE-PREFIX-OUT
 translate called 20
!
dial-peer voice 200 voip !Outbound dial peer to service provider
 translation-profile outbound REMOVE-PREFIX-OUT

And change the E164 map used for sending calls to the service provider to only include one entry with a match for 0T.

By this the call routing loop should not occur.

[robandover385]

Thanks for this. I was trying to add the huntstop command to the voice class server group but got an invalid input detected at "huntstop", when I'm in the voice class server group and run ?, I don't see the huntstop command listed. The only options I see are description, exit, help, hunt-scheme, ipv4, ipv6, no and shutdown.

For the second part, would I just need to go to config mode and copy/paste the config? Or would I need to make some changes?

[Roger Kallberg]

What version of IOS are you using? Sounds like you might be an an older version that do not have this command in the server group.

Yes that is correct, just do a conf t and then paste the whole thing. For the E164 number map though you'd need to copy what you have now and then put a no in-front of each line in it and then add a new line that looks like this e164 0T.

[robandover385]

We are running version IOS 16.12.04 and ISR software 16.12.4.