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.
.jpg "VIP Advocate"){kind=icon}
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.
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.
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.
