Is it possible to configure Asterisk to associate an RTP stream with a certain call when it’s coming from an IP address that’s different from the media address negotiated in the SDP header?
The port on Asterisk the RTP is sent to is the one that’s in the SDP.
It’s because of a NAT issue on a VPN server, which needs fixing but meanwhile I am looking for a quick temporary solution.
Sometimes what happens is that on a call with a phone on VPN, the phone’s address that’s negotiated for RTP is it’s VPN address and Asterisk sends audio to it, but the return audio that’s flowing through the tun interface appears to be coming from the local machine the VPN server is running on, not the phone’s VPN address.
The RTP destination port is correct.
Many SIP products have a feature where you can set it to “learn” the UDP IP and port used by the other side. It does this by waiting for the UDP stream to arrive on the specified port, and then sending the forward traffic to the IP and port combination from which the traffic was received. I think this is somewhat common behavior when you see a “NAT” feature on SIP equipment, especially in SIP registration scenarios. In Asterisk, I believe this config value was “nat=yes” on older versions of Asterisk, and “nat=force_rport,comedia” on newer versions for chan_sip. I’m not sure what the equivalent for pjsip would be.
For chan_sip, it is nat=comedia. force_rport does something different. Deprecating yes was probably done to make people think about what they really wanted, but people simply translated it.
Note than chan_sip doesn’t actually need this if the peer is obviously natted (not in local nets, and an external address is configured) as the default is auto_comedia.