Initially I reported what I thought was an issue with how I had the DID configured and was inquiring about wildcards and their usage. For some reason some, but not all calls, to the desired DID would result in a recording from the PTSN side that the number dialed was not a working number. I assumed that I was missing something.

However, after getting with the provider it appears that when a call comes into their service they may send the call to the UCM using a different server and therefore from a different IP. They will use this to load balance the demands and as a result the call could come from one server or their other server depending upon the circumstances at the time. The trunk is registered to the provider domain and authenticated.

The problem appears to come into play whenever the inbound call is is sent to the UCM with the IP address of the server that the UCM did not originally register with…despite the domain. In other words, if the UCM registered with the provider at PX-TX.domain.com and the server at the time had an IP of 74.22.22.22 (example only), then it appears that the UCM will now only accept calls from that particular server IP and will reject with a response code of 404 not found should the IP address be different say - 74.22.22.23; yet the domain is the same. The provider only uses the two servers. DNS Srv on the outbound eliminates the issue from occuring on the reverse.

The 404 code gets fed back to the PSTN network which then gives the message of not a working number. Call again and it may go thru …depending upon which server handled the call and if the UCM registered with that server. I assume that others may provide a different error message. I tested quite a bit with the provider and we could make the issue appear or go away at will by following which IP the UCM registered to and from which IP the incoming call originated.

Using 3CX does not exhibit this issue.

Any help is greatly appreciated. I submitted an update to my ticket, but have not heard back as of yet, so am hopeful that others may know the solution.

I had the same issue this morning, I’ve worked around the issue by creating a dummy peer trunk using the second IP and created my inbound route on this dummy trunk. So far this has solved the issue. Did you received a answer from the GS support with a better solution?

No, obviously i’m running the latest firmware, but the issue is still there as you can see in this post. I think that there’s no harm to answer a old post. Maybe at some point somebody will find that post like I did and will be happy to know that there’s a workaround.

There is huge difference between firmware. Answer that belong to 1.0.6.11 (Atersik 11) is usually useless as user resolved it long ago or your answer will not work on this fw. I understand why you reply