sure…
NS is open source and you and your code are welcome 
@Adam I think we need to be sure that it’s not a bug in the nf_nat_sip kernel module before disabling it entirely.
I’ll try to understand the problem next week, but if someone has more information about sip problems, please share them.
Thank you.
1 Like
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.
Some links to those info would be perfect. Thanks.
1 Like
This is probably the most valid one to mention since it’s in the shorewall FAQ:
http://shorewall.net/FAQ.htm
Thank you @Adam.
I still can’t understand the source of the problem, though.
I read some docs, see these:
http://www.asteriskguru.com/tutorials/sip_nat_oneway_or_no_audio_asterisk.html
Do you think we’ll be safe if we modify NethServer to follow shorewall faq #77? Or we need an option to enable the faq only in case of problems?
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.
1 Like
So we could simply disable the kernel module by default, no configuration switch to implement.
What a about a prop?
Something like:
config setprop NotLoadedModulesList module1,module2
Maybe as default, the prop can list the incriminated modules.
1 Like
That would be an easy fix since most PBXs have the NAT options these days.
I’m not quite sure I understand how this would work. I’m assuming something easier than the current workaround but still requiring some CLI work…?
It should require CLI work only if you want to RE-enable the modules which will be disabled by default 
1 Like
Just to stir the pot a bit… here’s a screenshot from a SonicWall:
The SIP Transformations checkbox is pretty much identical in function to what the shorewall sip helpers do and exactly what I’m suggesting. You know… with user experience in mind and all. 
Edit: It is disabled in SonicWall by default, so that would be a good first step.
1 Like
I just went through the process of manually disabling the sip helpers on another nethserver instance and thought it’d be a good idea to check in on this. Is there anything in the works to set the helpers as disabled by default and/or add an option in the gui?
I’d like to solve this, but I’m still not sure how.
Did you use
loadmodule nf_conntrack_sip sip_direct_media=0
or
DONT_LOAD=nf_nat_sip,nf_conntrack_sip
?
1 Like
I ran these two commands:
rmmod nf_nat_sip
rmmod nf_conntrack_sip
Then edited this line:
DONT_LOAD=
In these two files:
/etc/e-smith/templates/etc/shorewall/shorewall.conf/60options
/etc/shorewall/shorewall.conf
to:
DONT_LOAD=nf_nat_sip,nf_conntrack_sipwe have in development a feature related to this
2 Likes