Interesting reply, what side of the road do you think I am on? the odd side or the even side ? there are 10001 ports in that range, all legs start on an even port, and will be replied to on the next port up, all completed calls have a number of legs greater than zero the sum of used ports will always be an even number. So - 20000 or any range that ends on an even number is just asking for trouble (not much but a little 
)
If you can somehow answer this question, then you can say Iām wrong:
Since the RTP range is arbitrary, how would the Linux kernel know that 10000-20000 UDP are related to the SIP session?
1 Like
Youāll have to ask Christian Hentschel that question. Perhaps Linux reads the headers? Perhaps Asterisk was the first and so everyone just knows that 10k to 20k are the RTP service ports that are most likely to be used.
All I can tell you for sure is that it works. aalzate told you that it worked in his first post.
I donāt understand why youāre fighting me on this. You can go test this yourself right now. Just try out the variations and watch what happens. Thatās how I figured it out.
(Edit: Removed duplicate link. The forum didnāt like it. See above.)
One more thing. Please donāt confuse
ip_conntrack_sip - which is what Iām talking about
with
nf_nat_sip - which is the SIP ALG that everyone (including me) says is EVIL and should be banished to the depts of hades.
(Also, the time I have allocated for arguing with strangers on the internet has now expired. I canāt spend any more time on this.)
Searching ip_conntrack_sip only brought up rather old and unhelpful results. It has been renamed nf_conntrack_sip.
Searching for nf_conntrack_sip brought up this wiki article from FreeSWITCH containing a nice explanation: https://freeswitch.org/confluence/display/FREESWITCH/Firewall
So: it is a non-mangling ALG (good - different from the NAT module) and requires standard ports and also for the kernel module to be loaded. You can use non-standard SIP ports with the module and tell it whether to work with media only coming from the signaling proxy or from anywhere.
It does not simply open 10000-20000 UDP for rtp traffic but examines the SDP to open the correct port.
On a FreePBX Distro this module is not loaded by default. On my own router this module is not loaded by default. The module looks helpful but is not necessarily automatically available to help with RTP portsāyou would have to be sure to load it and possibly add extra options for your environment.
Thanks for the new information.
Even assuming that what youāre saying is correct, there must be some Netfilter code that operates on āRELATEDā which behaves as I have described. I have tested it extensively, with many routers and with the FreePBX distro as far back as 2010, and have confirmed that RELATED does precisely as I describe.
And you can test it yourself if you want to. But, you know that Iām right, as the OP has stated very clearly that it all worked just fine with his old system.
And with that, I really must goā¦
The odd ports are RTCP, not the reverse direction for RTP!
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.