Now that the SIP messages are flowing properly from FreeSWITCH to the phone, what about the media? A phone call or a videocall is not very eventful if you can't even hear each other, right? We had many problems where the calls would set up properly until the point where NAT would strike the RTP packets that provide the actual media of the call, rendering the call with one-way-audio or even no-way-audio in some cases. In light of this injustice, we created a separate feature that is always enabled and only needs to be manually disabled in a very few set of cases inspired by the fourth pitfall. This feature is called RTP auto-adjust. The reason we need it is because when the phone tries to call us from behind NAT, it will naively advertise its unreachable LAN private address to FreeSWITCH as to where to send the media streams (eg the address written in the text of SDP).
We could guess that since the device is behind NAT, we should really send the audio to the same address that we saved from the SIP message. But that is not always the case since various types of NAT have restrictions and the port mappings sometimes don't exist until the device behind NAT has actually sent a packet. So, in reality we may have no idea whatsoever as to how to successfully get audio flowing to the phone. Thanks to the auto-adjust feature, we still have a fighting chance. As long as we give the phone a valid address where it can send us audio, we can wait until it sends us some packets and use the originating address to determine where to send the audio back. This is not 100 percent guaranteed, as we know, but it's very effective in an otherwise hopeless situation. Just to be safe we only allow this magical adjustment to happen right at the beginning of the call otherwise evildoers may try to steal people's audio streams.
As previously mentioned, this RTP auto-adjust is pretty much enabled by default and will turn on automatically. The way in which you can tell that it is working is by looking for a log message like the one that follows. The message shows you the original media destination and the new one that was detected. This log line prints at the beginning of any call where auto-adjust has triggered.
If you do have one of the two percent of cases where this feature triggers the fourth pitfall and actually breaks things for you, then all you need to do is add this parameter to your SIP profile:
<param name="disable-rtp-auto-adjust" value="true"/>
Otherwise you can also disable it on a per-call basis by setting the channel variable rtp_auto_adjust=false at some point before the media stream has started.