In /etc/asterisk/rtp.conf is your usable range of ports (and it is definitive) you need to match that range in your router, it should start on an even number and span at least twice the number of likely concurrent calls. If that file is not the same as you set it in the gui it is likely a bug.
Hi dicko,
Thank you very much. In the meantime, I checked the issue further, found a solution, but did not understand the cause. Thus, I would very much welcome feedback:
-
The RTP Port Range in Asterisk SIP Settings and in /etc/asterisk/rtp_additional.conf are always sychronized. This does seem to work as it should.
-
Our carrier (Deutsche Telekom AG) specifies RTP ports 30000 through 31000 plus inbound port forwarding for UDP packets. In line with recommendations, I did set RTP port ranges of 30000 through 30099 (more than wide enough for me) plus corresponding port forwarding rules. If I recall correctly, port forwarding did make sense one or two years ago. Today, I could not find that to be critical anymore. Furthermore, the carrier also connects if one specifies standard RTP port ranges of 10000 through 20000.
-
To my surprise, if I take a wireshark trace at my WAN interface, the RTP packetsâ ports do never correspond to the RTP port ranges set in FreePBX. I have some older traces on file to compare - in the past, there was also no correspondence between RTP port ranges entered and what wireshark finds. Does this make sense??
-
When upgrading Asterisk SIP Settings from 13.0.14.5 to 13.0.14.6, it changes the RTP port ranges back to 10000 through 20000 regardless of what one did specify before. This did not happen with other recent upgrades which I tested.
-
In my scenario, I did not immediately notice the change of RTP port ranges due to the Asterisk SIP Settings module upgrade - how should I? When reverting RTP port ranges back to 30000 through 30099 yesterday, I did trigger a FreePBX System Firewall issue. It seems that ony may go either with 10000 through 20000 and the System Firewall on or with other port ranges and the System Firewall off. Unfortunately, this is not obvious - at least this was not obvious to me.
Regards,
Michael
rtp set debug on
will show the audio payload as asterisk sees it hopefully bi-directional. Make sure any sip " helper" function on your router is disabled. The rest might be freepbx bugs.
If the RTP port ranges specified in the conf files are not respected (even after asterisk restart) that points to a possible asterisk issue. Itâs hard to imagine how the dahdi config module would have any influence over this, tho stranger things have happened.
The rtp ranges getting reset on upgrading the SIP Settings module sounds like a FreePBX bug, recommend filing a report at issues.FreePBX.org.
Difficult to say for sure, but the Firewall module sounds like it may be working properly, it should recognize the non default port range and allow the traffic. If Asterisk is not using these ports tho, it will be a problem.
When a provider specifies RTP port ranges, that is almost always the ranges that they will be signalling to you where to send the media to them. The rpt.conf port ranges are where Asterisk is specifying to receive the streams. Unless your provider is requring some really invasive rules on you, unlikely, then there should be no reason to change your ranges as they should send the media to where ever you tell them to and as such you shouldnât have to change the rtp.conf default configuration. The provider never dicates where itâs going to send to, only where you are to send to it.
In either case, if you choose to change your ports, itâs usually a good idea to have a range that is a lot more then adequate to cover the number of simultaneous calls youâll have (x2 since itâs only even port numbers it will use).
It does appear form what youâve described there may be a bug in the changing and resetting of default rtp port settings in Asterisk, so if so, itâs a valid bug to report for us to explore. But, my recommendation would be to stick with the defaults if the only reason you made these changes was thinking you had to based on your provider. (Unless Iâm wrong, and they really are dictating the âfrom portsâ for your RTP as if they would reject any traffic that didnât come âfromâ their specified range, possible, but unlikely.)
Dear danielf, dicko, lgaetz, p_lindheimer,
Again, thank you very much for your responses! Over the last 10 days, I have been - unlike in the years before, where I did try to go by the book - ignoring the carrierâs specifications and changed the RTP ports back to the standard 10000 - 20000 range. I have also deleted all RTP port forwarding rules. The only port which I am still actively forwarding to FreePBX is now SIP 5060 UDP.
That led to a completely functional system without any issues - except for the mildly related NIC bundling point which I did file as an issue.
Regards,
Michael
If you donât have the RTP ports forwarded to you it may result in intermitent issues, so you may want to consider whether or not you want to keep it that way. The reason it works âmost of the timeâ is because upon the negotiated signalling, you begin to transmit to them through the ports that youâve requested they send the media to you in. Once you have initiated that, theyâll be able to reach you through those ports as youâve opened up a hole from inside. The things that can go wrong are two fold. Until you do that, the hole isnât opened so any transmission they do to you will get blocked. Secondly, if your firewall re-maps your ports, you may or may not recieve the media, it depends on how aggresive they are in trying to accomodate an âincorrect configurationâ on your part. Some providers may wait until they see your media stream, ignore the signallilng information you supplied them in the SIP dialog, and send the media back to the ports that your stream is coming from. As long as they are doing that, it would continue to work. However, the proper operation would be for them to send the media to your advertised ports. If your firewall has remapped those ports, then the media will get blocked and youâll end up with one way media where as if you had the ports forwarded, they would still arrive at your PBX.
So ⌠the crux here is, it may work now, and it may continue working, but it may also break or even get intermitent problems if you donât have those ports forwarded. The latter could happen because of changes on their side (which would not be anything theyâre doing wrong) or changes on your side because of firewall behavior.
Dear Philippe Lindheimer,
Well, the attitude of Deutsche Telekom AG reflects that they are the incumbent and still dominant carrier in Germany operating hundreds of VoIP servers. While they push for fast migration to VoIP in order to scrap ISDN, they do not care a bit about users of Asterisk and the like. They rather want to sell their proprietary Speedport routers most of which are far too limited in quality and functionality to be used in any (semi-)professional environment. There is technical documentation about Telekomâs VoIP functionality available, hundreds of pages of it, but rather illegible and out of touch with reality, as it tends to be outdated, different servers seem to have different policies at each point in time and issues such as load balancing and proprietary DNS resolution strategies remain behind the curtain. Smaller competitors have working sample Asterisk configurations available for their customers, of course.
In the past, I did only open and forward a small range of ports (30000 - 30099), which are a subset of the range claimed by the carrier. I did also limit that to RTP traffic coming from Deutsche Telekomâs servers. I do hesitate, however, to open and forward ranges very broad ranges, such as 10000 - 20000. Furthermore, limiting port forwarding to traffic originating from the carrierâs addresses is also tricky, as they refuse to reveal from which IP range their traffic is sent, so it is a constant game of watching and updating. Thus, I intend to avoid RTP port forwarding as long as I can while watching for adverse consequences. I did try this last about 18 months ago and as you said, it did work for some time and then it did suddenly stop.
Regards,
Michael