No incoming calls

[matt-pfuk]

Hello,

I have an issue whereas I cannot receive incoming calls at all but can make outgoing calls. I have triple checked all the ports, settings and such, but I cannot seem to work out why its not receiving calls..

Can anybody shed some light on my issues?

Thanks,
Matt

 

[willow]

you will need an incoming rule set up so that the system knows where to point the DID to.

 

[matt-pfuk]

you will need an incoming rule set up so that the system knows where to point the DID to.

I dont have any inbound rules setup, I'm not sure how to do those, is there a page you can point me to that will help me???

 

[willow]

If you go to the console for the 3cx there is a menu tree for incoming rules. You just need to define your DID, then select where you would like it to go to.

 

[Wentil]

Hi, Folks --

I have a similar problem. I am using two SIP Trunk providers: Viatalk and Voicepulse, for a total of four trunks, eight channels. Our phone server is located remotely, at a datacenter, and all of my extensions are external, connecting into that phone server from different locations.

3CX has registered successfully with the Trunks, and the external extensions have registered successfully with the 3CX Server.

I can make outgoing calls, but I cannot receive incoming calls from the trunks. I have tried both with the standard redirect-to-extension setting at the Trunk level and also with implementing DID.

This may be because the external extensions are registering with their local, non-routable 192.x.x.x IP addresses, but I never had a problem with this same setup using Asterisk. Everything worked smoothly, incoming and outgoing calls, with no need for STUN or ICE.

The only reason I am interested in transitioning to 3CX is the nice GUI and good anti-hacking controls, but if this can't be resolved quickly I will need to switch back to Asterisk, as not being able to receive calls isn't going to work for me.

Thanks, hope someone has some helpful insight?

-- Wentil

 

[leejor]

I can make outgoing calls, but I cannot receive incoming calls from the trunks. I have tried both with the standard redirect-to-extension setting at the Trunk level and also with implementing DID.

This may be because the external extensions are registering with their local, non-routable 192.x.x.x IP addresses, but I never had a problem with this same setup using Asterisk. Everything worked smoothly, incoming and outgoing calls, with no need for STUN or ICE.

The only reason I am interested in transitioning to 3CX is the nice GUI and good anti-hacking controls, but if this can't be resolved quickly I will need to switch back to Asterisk, as not being able to receive calls isn't going to work for me.

You will either have to make use of STUN on the remote extensions, or, run the 3CX proxy server on a PC at the remote site. The sets would then use the proxy server, and it would connect to 3CX. The 3CX server log will show you what is happening to your incoming calls. if the remote sets are registering with a private IP, then 3Cx has no way of contacting them.

 

[Wentil]

if the remote sets are registering with a private IP, then 3Cx has no way of contacting them.

The thing that puzzles me is that Asterisk had no problem, and the remote sets were doubtless doing the same thing -- i.e., registering with their local IP address. I did not need to set up a separate proxy server at each remote location.

After all, each remote extension -has- an established connection to the 3CX server. 3CX should be able to contact them through that existing, registered connection.

Is there no other suggested solution?

-- Wentil

 

[leejor]

Never having used Asterisk, I can only assume that it was using another method to determine the public IP of the router that the sets were behind.
With 3CX the set will need to register using the public IP and port, that is the only information that 3CX has to reach them. Are the sets not STUN capable?

After all, each remote extension -has- an established connection to the 3CX server. 3CX should be able to contact them through that existing, registered connection.

They may be able to register, but it is only a one way connection at that point, not an "established" connection. 3CX will try to contact the set at the IP it uses in registration, not the public IP where the SIP message originates.

It may be that Asterisk is being somewhat creative with SIP standards, I don't know

 

[Wentil]

Never having used Asterisk, I can only assume that it was using another method to determine the public IP of the router that the sets were behind. With 3CX the set will need to register using the public IP and port, that is the only information that 3CX has to reach them. Are the sets not STUN capable?

That's exactly my point -- there was no need to determine the public IP of the sets, as it used the existing connection. Moreover, even if the physical IP address of the router that the sets are behind was obtained, unless that router was set to forward external requests on those ports to the sets, they are unreachable. However, the sets already have an established channel in place with the server -- that must have been the route that Asterisk was using to ring them, since neither proxy servers nor special port-forwarding router configs were required.

They may be able to register, but it is only a one way connection at that point, not an "established" connection. 3CX will try to contact the set at the IP it uses in registration, not the public IP where the SIP message originates. It may be that Asterisk is being somewhat creative with SIP standards, I don't know.

Unfortunately, if 3CX requires public addresses, proxy servers or port forwarding in order to connect calls to each endpoint, I won't be able to use it the way things are set up here. I'm going to have to go back to Asterisk, as it doesn't need any of those things. *sigh* 3CX had really seemed like a good package, too. If I was putting together a more conventional every-phone-inside-the-LAN setup, it would probably have worked better for me.

Thanks for taking the time to help out, Leejor, it's muchly appreciated. Take care.

-- Wentil

 

[leejor]

Unless the sets that you are working with do not have STUN ability (meant to be used only within the same LAN as the PBX), then I don't see the issue in making use of it.

 

[eagle2]

Asterisk vs. 3CX

Asterisk systems normally don't care about STUN, so remote extensions may register with their local address (in case of STUN it is replaced with public one, plus port translation). Instead of this, Asterisk takes care about what address the SIP/RDP packets came from and returns packets to the same address.

This approach, nevertheless is not fully adhering to SIP standards, in most cases is simplifying setup and is overcoming NAT issues (no need for STUN, Outbound proxy, etc.) and causes SIP traffic to be treated like normal (e.g. http) traffic. This may not work in more complicated environment (nested NATs, etc. or special firewall settings). This means (and may be observed with wireshark) that SIP/SDP messages utilize local addresses, while SIP/RTP traffic is received from /sent to public address(es), just as any other traffic over Internet.

In your case this could be the problem -- for correct handling 3CX needs the public address of the remote extensions to be part of the SIP/RTP messages and is ignoring the source IP address of the packets arriving (as stated by SIP standard). You should use STUN and/or Outbound Proxy to solve the issue.


On the other hand some routers/firewalls support so-called SIP ALG (Application Level Gateways) which rewrite SIP/RTP packets and replace public with local address and vice-versa. 3CX manuals advise to switch off SIP ALG and to use STUN for 3CX Phone Systems and remote extensions instead (STUN is used to discover external public address and this address to be used into SIP/SDP messages instead of local).

Note that STUN may be incompatible with SIP ALG and/or Symmetric NAT and this could cause problems with 3CX Phone System or remote extensions. Firewall checker can show the problem, if any.

Best Regards

 

[SY]

Hi,

Please check following parameter:

ALLOWSOURCEASOUTBOUND
Citation from http://www.3cx.com/blog/docs/3cx-phone-system-parameters-table/ :
When set to “1″, 3CX PhoneSystem will use source IP/port of SIP request instead of Contact field provided by SIP entity. Media Server will use source of incoming RTP traffic for destination of outgoing traffic.
This parameter may be set when external entities cannot provide correct information for some reason, including (but not limited to):

remote entity is behind double/triple NAT
external SIP device doesn’t support NAT traversal (RFC3581)
external SIP device implementation provides inconsistent information (bugs in implementation)
remote network has a SIP ALG somewhere and the SIP ALG performs incorrect modifications of SIP messages
Setting this parameter may assist with resolving some issues with remote extensions or VoIP Providers which have NAT traversal issues.

NOTE: This is provided for experimental purposes only and may create unpredictable results with different devices or network layouts.




In v10, it is not experimental parameter and it is set to 1 by default.
if you restore a backup made by previous version of 3CX Phonesystem this parameter can be set to 0 or even be absent.
Please check it and add this parameter manually or change its value to 1.

If problem will persist then kindly post citation from Server Activity Log page.

Thanks in advance

 

[eagle2]

Hi Stepan,

This is exactly the point and thanks for this post -- using ALLOWSOURCEASOUTBOUND parameter must be able to solve NAT issues (but may not work in nested NAT environment). The Asterisk systems are using the same mechanism by default.


In general (a brief summary), to solve NAT issues within SIP/SDP messages, you need one of the following at client's side:
- STUN enabled client / terminal, note that STUN may not work in some symmetric NAT environments
- SIP ALG (SIP NAT) enabled gateway - must be checked for correct operation
- local outbound proxy like 3CX and 3CX tunnel or just a VPN tunnel
or at server' side:
- using source addressort of RTP media instead of address into SIP/SDP messages -- what the above setting is supposed to force
- outbound proxy or session border controller; they are supposed to replace the content of SIP/SDP messages using the same or similar mechanism

The router at client's side normally will NAT only the addresses into packet headers and will not translate the SIP/RTP messages. The router at server's side, if not SIP ALG capable, will also translate only the addresses into packet headers. You need static NAT / port forward for certain ports in order 3CX server behind NAT to operate correctly (STUN or static external IP for providers).

There is no universal solution or recommendation, cases may differ. Various terminals and clients may use different methods. I never came across a good guide or tool for testing the environment and suggesting solution. The 3CX firewall checker is good for server's side and is not applicable for client's side. May be a combination of several mechanisms will do the job. I don't think an Asterisk extension would be easier to set and/or debug or will operate correctly always (a comparison earlier in this threat). Tests must be performed in each specific environment. Understanding what's exactly happening is important to solve issues.

Best regards,
Orlin.

 

[SY]

Hi Orlin,

Completely agree.
Thanks for your comment.

I think that "3CX tunnel" is the very good sample of an approximation to the ideal implementation of:

- SIP ALG (SIP NAT) enabled gateway...

and

- outbound proxy or session border controller; they are supposed to replace the content of SIP/SDP messages using the same or similar mechanism