I have a problem and I hope that someone could help me. I want to configure an external soft phone extension (internet) into my freepbx in my LAN. I did a try with 5060 port and all work correctly, but I want not forward 5060 from outside to my LAN because I don’t want expose my PBX on internet.
So I did a NAT forward for a different port, let’s say 4000 to my pbx (5060), and the external extension can register on my pbx but after 6/7 seconds the call drop. If I use a forward from outside 5060 to my internal 5060 I don’t have any problem. (Obviously I have forward 10000-20000 ports range too).
I think that when I forward 5060, my pbx ‘resend’ the communication on the same port and…everything works, but not when I use a different port. Is like from inside to outside the communication doesn’t pass when I use a different port.
The external extension inside the frepbx, is configured as NAT=yes and with 4000 port.
Did you disable SIPALG on the Router?
In my case there is no VoIP traffic no need to disable it for me, see example… but in your case you must disable SIGALG (which you find in ->IP Firewall → Services
SIP does not like NAT, now you are add port translation to it, you are adding problems.
If you do not want to use the default port, i.e. 5060, then change that at the pbx and use the same port number on your forward rule, but do not translate
That’s what he actually did - the PBX has been told not to be surprised by the uris in the SIP headers to refer to port 4000 while the packet actually comes to its port 5060 due to the port forwarding, and to put the public address and port 4000 into the messages it sends itself instead of the actual private address and port 5060. Some PBXes can live with that and some cannot, but as this one offers a corresponding configuration and has accepted the call, that should not be the issue.
Dropping a call after 6-7 seconds is a weird behaviour. There is nothing similar in the signalling timeouts unless someone has tampered with them, normally it takes 31,5 seconds for the called side to drop the call because it hasn’t received an ACK. Or there may be unidirectional RTP at one end and the phone or the PBX may tear the call down due to not receiving any RTP, these timeouts are usually less than 5 seconds if implemented at all.
So @surfparadise, you’d have to use packet sniffer to sniff into a file, simultaneously at the internet-facing and PBX-facing interfaces, to have a look using Wireshark at what stage the call breaks and why.
