Outbound calls are forbidden

[twasluck]

Call or Registration to xxxxxxxx@(Ln.10001@Via Talk2) has failed. [ V4 xxx.xxx.xxx.xx:5060 UDP target domain=unspecified mFlowKey=844 ] replied: 403 Forbidden; from IP:xxx.xxx.xxx.xx:5060

All of my outbounds calls are forbidden. I have check all my outbound rules, and called my VOIP provider. They tell me my system is generate a busy forbidden error before the calls reaches them. They do see the outbound attempt but says my system blocks it before they can process it. Any ideas?

Sincerely a Rookie,
Twasluck

 

[leejor]

There is an option to block outside calls on an extension basis, if checked.

Did this just start happening? Was it working previously?

Do all extension have the same issue?

Do you have any other outbound routes that do work?

What is the IP that you X'd out (forbidden from ???:5060) ? Is that your providers IP or the IP of the 3CX server?

 

[twasluck]

There is an option to block outside calls on an extension basis, if checked.
Did look and it is not checked.
Did this just start happening? Was it working previously?
Was working fine and this issue has been occurring for the last 2 days.
Do all extension have the same issue?
Yes.
Do you have any other outbound routes that do work?
No.
What is the IP that you X'd out (forbidden from ???:5060) ? Is that your providers IP or the IP of the 3CX server?
I really don't know. I just figured I needed to x it out for security reasons.

 

[leejor]

What is the IP that you X'd out (forbidden from ???:5060) ? Is that your providers IP or the IP of the 3CX server?
I really don't know. I just figured I needed to x it out for security reasons.

Well that IP will tell where the call is being blocked, either internally, or by your provider.

If this issue just began, and a re-check of the logs shows the IP to be that of your 3CX server, then what changed locally? If the IP is that of your provider, then you might want to have another chat with them.

 

[lneblett]

Are the SIP providers showing registered?
Is the number you dialed, XXXXXXX@(ln1001@via talk2) a valid number and is it possibly an international call that is allowed in both 3CX and by your provider?

It would help to identify what is forbidding it (by the ip address).

 

[twasluck]

I just got off the phone with them and they said it is their IP address and showed me how to ping it to confirm. They said it could be something in the codec. I have all my phone set up on G729 but he told me to try G.711 U law. I switched it on 3cx but to no avail. Looking to reprogram the phones.

 

[leejor]

Did you make a change to the Codecs, or something else on your network/router/firmware,etc.? Is that when the problems began?

 

[lneblett]

This is likely not a phone issue as the SIP provider is communicating at this level directly with the 3CX system. I suggest you look at the set-up for the provider. The first thing to check is whether there is a registration for the Trunk. This assumes that it is a register trunk and that your setting calls for a registration on both inbound and outbound calls. If not, it may show as registered regardless. If this is an issue, the 3CX system will tell you in the log that the trunk failed to register. If so, then look at the credentials being used.

You should look at the codecs set for the provider, the IP address set for 3CX and the SIP port. Internally on the LAN, there is no reason to have the phones set to a primary codec of g729 unless the LAN is saturated with traffic and even then, you should be looking at upgrading/fixing the LAN instead. Use g711u and then g711a and finally g729 for ViaTalk. Also keep in mind that with 3CX, the number of licenses available for g729 is only half of that for the others. This is due to the g729 codec still being protected by a patent which must then be licensed by 3CX.

As you did not indicate that inbound calls are failing, this still makes me wonder if the number being sent is correct. Say perhaps that one of the rules is altering the number using some kind of unsupported character. The rule is apparently sending it on, but there is something that Via Talk does not like and in reality, they should be able to monitor and tell what the issue is.

I assume that the provider is ViaTalk in the US, correct? If this is the case, I found a post on another board that, while somewhat old, provides a response to a question about the codecs that ViaTalk supports. In this post ViaTalk indicates that they only support g711u as they do not see a need to support others. If this is your provider, then make certain that the provider set-up has g711u (PCMU) at the primary codec and you may want to eliminate the other two I mentioned above from the list. As I indicated, it is somewhat old, but G711u is the main codec from most providers in the US.