RTP.conf port ranges are set to the default in config file
However it’s not using the range 10,0000 to 30,0000
I’ve had to open up the firewall to allow ports up to 51,000 to get audio. Setting firewall to the default range gives me no audio. Nat is enabled and asterisk has a fixed public IP
RTP Debug below
[2024-09-09 12:02:03] Got RTP packet from xxx.xxx.xxx.134:**54066** (type 08, seq 000129, ts 020720, len 000160)
[2024-09-09 12:02:03] Sent RTP packet to xxx.xxx.xxx.45:**46402** (type 09, seq 028775, ts 019080, len 000160)
The option doesn’t control what the REMOTE side will use for ports. It controls what Asterisk will use for its own. Each side has its own ports, and you can not control what the remote will choose or its range - except by configuring it if it is under your control and allows it.
Thanks, but this doesn’t make sense. We have many older versions of asterisk running which are behind firewalls with a static public IP address. We open UDP ports 10,000 to 31,000 for RTP traffic. On asterisk versions 18 and 20, the settings in rtp.conf appear to be ignored.
An rtp debug shows that audio is passing at port 46568 this means I would need to open up the firewall for those high ports otherwise there is no audio. My understanding is that the ports are negotiated. This isn’t happening. I should say that I’m using chan_sip but this is an rtp problem not a sip issue per say. Any pointers as to where in the code the ports are negotiated would be appreciated. Having run asterisk since v0.9 I’m well aware that there is often gotcha’s in the code
Alice calls Asterisk.
Alice says “I want audio to be sent to me at 192.168.1.100 port 40000”
Asterisk answers and says “I want audio to be sent to me at 192.168.1.5 port 15000”
Each side has their own IP address and port.
Alice will send FROM 192.168.1.100 port 40000 to 192.168.1.5 port 15000 for audio to Asterisk
Asterisk will send FROM 192.168.1.5 port 15000 to 192.168.1.100 port 40000 for audio to Alice
Opening ports is generally meant for audio TO Asterisk.
This is how SIP and SDP works, has always worked, and how Asterisk has always worked including for the configuration in rtp.conf. It controls the Asterisk side. You can’t control the remote side.
By default, you need 5060 incoming on at least one of TCP and UDP (strictly speaking you always need UDP). You need the range of port numbers incoming and UDP that is listed in rtp.conf, for RTP media and RTCP.
RTP - the media stream
(related to the port range in /etc/asterisk/rtp.conf)
It quickly devolved from a discussion of configuring a phone into exactly what is being discussed here. It illustrates that even experienced Asterisk people don’t entirely understand the issue.
The settings for rtp ports in Asterisk only control Asterisk just like the settings for rtp ports in a phone only control the phone. To expand on jcolp’s answer and perhaps make it more clear:
Alice calls Asterisk.
Alice says “I want audio to be sent to me at 192.168.1.100 port 40000”
[Alice will accept UDP packets with a source port # of whatever the heck and a destination port # of 40000]
Asterisk answers and says “I want audio to be sent to me at 192.168.1.5 port 15000”
[Asterisk will accept UDP packets with source port # of whatever and destination port # of 15000]
Each side has their own IP address and port.
Alice will send FROM 192.168.1.100 port 40000 to 192.168.1.5 port 15000 for audio to Asterisk
Asterisk will send FROM 192.168.1.5 port 15000 to 192.168.1.100 port 40000 for audio to Alice
[In other words - the port range configured on Asterisk of, let’s say 10000-20000 is not being used as a filter to DENY incoming UDP traffic sourced outside of that range - it’s being used to DETERMINE what range Asterisk will say it wants in the invite. Asterisk may ONLY ever send UDP traffic with a source port of between 10000-20000 but that directive does NOT block it from getting UDP packets sourced from 40000]
Now, there’s been statements that Asterisk is “symmectrical” in it’s UDP traffic, but (from my understanding) that means that Asterisk wants Alice to send her UDP packets to destination 15000 and it will also source it’s UDP from port 15000 I don’t believe it can possibly mean that Asterisk is expecting when it sources from 15000 that Alice must also source from 15000
I’ve love some confirmation on this. The other FreePBX thread has gotten very convoluted.
Oh and by the way - the fact that it works like this pretty much means that a regular address translator that isn’t SIP-aware is a giant hole in your firewall and you might as well just port-forward the entire public IP on the outside of the firewall to the PBX. Or better yet just plug the PBX into the DMZ and assign it a public IP. Otherwise get a modern firewall that understands how to dive into the SIP packet headers and open and close pinholes as needed.
(Note that this is my personal opinion on firewalls)
Thing is that rather than Alice sending to port 15000 as requested by Asterisk, Asterisk is in fact saying talk to me at port 48000, ignoring the port range specified in rtp.conf
Is there a way to run asterisk -r at the command line and dump it’s internal variables (such as the configured rtp port range, etc?)
Is this Asterisk install “pure” with strictly the config files controlling it or part of a PBX that may have layers more of configuration directives?
With chan_sip I believe it’s also possible to specify rtp ranges in the chan_sip config file for extensions - possibly is there some old fragments of config files floating around on this system?
That’s exactly what I’m doing, but asterisk is offering ports to the far end outside of that range and ignoring the settings in RTP.conf. If I remove them completely so it’s using the defaults it does the same thing
Those lines don’t show what you’ve stated. The first states that it received an RTP packet from the remote side, and they sent it FROM xxx.xxx.xxx.134:47230. The second states that we sent an RTP packet TO xxx.xxx.xxx.45:46592. Those are the IP addresses and ports from the remote side. They don’t contain any information on the IP address/port of Asterisk.
An actual SIP trace would show what is actually being provided back and forth.