We can not get our VOIP provider to work with DID because their system requires 3 logon fields (endpoint, userid and password).
We can add DIDs on the provider endpoint, but then the supplied called number is always the main account number, never the DID.
they could fix it by using authentication by IPaddress, but that's not supported by 3cx,I think.
Authentication by Ip address is essentially a trunk as worksighted described. In fact this requires no authentication because as the name implies, they validate your account on the basis of your public IP address. Therefore it has to be a static IP. Otherwise you will be heading into management nightmares with a dynamic IP. Hence they know that its you based on the request sent. If they match user id and public IP you specified in initial setup, they will authorize the call. If no they will reject. If you register your provider from home, they will reject - this is one of the drawbacks trunks have. Yes we support trunks. However I think that even the other option (the one you have at the moment) may work. When you have 3 pieces of information, it is very common that the endpoint and the user id are the same. Is this the case? They should not be using the endpoint for authorization purposes. It is common practice to only use User id and Password.
I would try and see if there is a tweak on the voip provider account's web interface to see if the endpoint can be masked with the other DID's you have. This is per provider - not all support it. But usually there are cases where you can dial a DID and the routing between the main number and the DID will be done at the provider's switches instead by 3CX. On incoming they will merge and use association of phone numbers by account. If the provider is really flexible, they will keep the DID number in the "To" part for example (instead of substituting it with the main number) and you will be able to route it based on source id/did matching to where you want it.
I am interested in the Sipgate problem reported isyman.
A small clarification : If the call is dropping after 30 seconds this is not related to DID issues. I can explain the DID concept but it is definitely not the cause of this problem. This is happening because ACK is not received. To troubleshoot this you will need to get hold of a register packet and its ok first and we analyze it. Sipgate are not receiving Acknowledgment of call setup (even though the call has been initiated and you are currently talking). If this is not received in a timely fashion (30-32 sec) they drop the call because in voip, a missing ACK after 200 OK leads to incomplete call setup hence an invalid/stale call. This is very common and clearly shows a NAT or incorrect contact information during sip message buildup. At this point we can eliminate SIpgate as the cause of this problem. Sipgate is a robust provider and their implementation works under all sorts of network topologies. It could also be related to how the provider is configured in 3CX as well because the configuration in the provider section must correlate with the network topology currently around you.
Some questions to better understand the setup:
How does this occur? When you make an outgoing call, incoming, or both? Do you have NAT? What type?
Do you have correct portforwarding on your router?
Does Stun resolve correctly? Does it resolve localip:5060 publicip:5060 hence no translation? or with translation? (BTW Sipgate works in both cases)
Test to perform: If you register Sipgate directly with a softphone or hardphone without having 3CX proxy'ing the call. What happens in this case? Remember to remain connected for more than 30 seconds. If you surpass this time you are safe and call will go on.
To really analyze this a wireshark capture of the call is a must. You can send it directly at
[email protected]. Also an important point I forgot to mention - what version of 3CX are you using? Ideally use the latest version - at the moment 7.1 beta - this is a very stable version. We called it beta for the simple reason that the 3CX Call assistant and the new Call Reporter are still in Beta.