That makes sense. It’s the template file location that the nethserver interface is based on and then writes to the config files from those. That’s good to know! Thanks!
I’ve confirmed that this works for mine too. So should we submit a feature request to expose this as a check-box option in the web interface?
I ran out of time and had to go pick up my daughter, but I placed several incoming and outgoing calls and they all worked. I’ll do more testing tomorrow morning.
Haha! Good answer! I used to program a bit around 15 years ago. As much as I’d love to contribute in that area, all of that knowledge has since faded. So for now, I have the resources to do some solid testing and provide my results.
Thank you, Filippo. Please let me know if there are any specific logs or other information I can provide to help.
I did see a lot of information saying that the shorewall sip ALG modules are known to cause issues and it’s common practice to disable them if the PBX you’re using has settings for NAT. It makes sense to me since you don’t want the router changing packet headers when the PBX is already compensating for NAT.
If a PBX doesn’t have the ability to change packet headers to ‘hide’ NAT, it may be required to have the sip helpers enabled. So the preferred solution would be to have the option to enable/disable them as needed.
In my experience, where ALG has caused a problem with RTP traffic, this was the cause:
(quoted from the link you mentioned)
Most of you will know that NAT changes your private IP address to the
public IP address but not everyone knows that it ALSO changes the source
port. Using our examples above switch A uses IP 192.168.1.8 and 65875
but when this comes out the other side of the NAT it may be seen as
87.45.78.65 and port 87563. Simply put a STUN server detects this and
sends this information back to the switch so it can amend the SIP
packets accordingly.
One way audio was caused by expecting to receive data back on one port, but the port was changed by the router, and therefore the return data was dropped.
@Adam I suppose your PBX has NAT traversal but it could be enabled though console or somth like this. FreePBX and Elastix has NAT feature, STUN does not help coz STUN only informs about NAT
It does and it’s enabled… which is why the shorewall sip helpers were a problem. They come into play when a PBX does not have NAT features. In my experience, it’s a much more reliable solution to let the PBX handle those tasks so there’s no other device sitting in the middle modifying packets and changing ports.