That does not appear to address RTP, as the definition provided in the link is -
Rewrites contact IP and port
The “contact” header addresses SIP only. For RTP it is the “connection” header. This is why the setting “NAT tab: Entered external IP/Port, checked Use IP address in SDP” is there along with the local subnet so that when the UCM sees a local IP making a request the UCM responds with a connection and contact header indicating its local IP. If it sees the request from a non-local IP, it will respond with its public IP in both the connection and contact header.
Digging a little deeper, you will see that -
- Rewrites contact IP and port to that of the NAT device by looking at IP address:port info from the packets reaching FreeSWITCH.
- Forces REGISTER expiry to 30 seconds. (Unless sip-force-expires is set)
This is similar to the way Asterisk tries to deal with NAT traversal."
Basically, all the tools are already there to handle the NAT in the UCM to include RTP which the Freeswith tool does not.
Next, the FS tool does not address how the device is to know its public IP. The tool basically says ignore the connection and contact header info IN THE SIP message and instead respond to the source IP and ports as seen at the UCM NIC interface. The UCM must still respond and it will need to tell the remote device what IP and port to use and if the device is non-local it must indicate the public IP. For those that do not have a static IP nor a DDNS FQDN, then STUN is the method used. The same is true as to why GS had you put STUN in the phones. Its a 2 way street as both the PBX and remote device must know and advise as to how the other end is to communicate reliably back.
In the settings on the phone, they should have also had you enable SIP options with a frequency of 30 seconds. As I suspect that you are not port forwarding at the remote end, this will cause a pinhole so that any calls coming into the phone will still be received. I do not know what the register period is, but 30 seconds is too small a period in my opinion; hence why the options request in the SIP settings.
Finally, no the 1 setting in the TOS RTP-Keep alive is not to create a pinhole. This setting is only active during an active SDP session. It is meant to send a packet in order to avoid an RTP timeout.
This is typically used when a call has been placed on hold. The remote side is sending music or whatever, but the other end is usually quite so nothing is being sent. If there are no RTP packets sent, then the other side may have a RTP timeout enabled (the UCM also has one) that will assume that the other end has gone off-line and kill the call when the timer fires. BTW the 1 setting is far too short and is sending extraneous traffic for no good reason. 20 -30 seconds is typically a reasonable period.
There is no point in sending a packet on a RTP port for a pinhole. As the UCM is set with a default RTP range of 10000-20000 and it does not know which port the next call will use until such time as the call is being established, it would have to send a packet out each of the 10001 ports. When the SDP in an INVITE or 200OK is seen, it will then know the ports to use and will bind to same at that time, not before. You can hover your cursor over the setting description to get more detail of what the setting does (in some cases). You will see that it is only active during a session which is only established during a call.