[asterisk-dev] Rules for binding with regards to RTP

[Mark Michelson]

During some testing being performed at Digium, a bit of unexpected 
behavior was discovered. While testing local RTP native bridging (also 
known as packet-to-packet or P2P bridging), RTP packets sent from 
Asterisk had an unexpected source IP address. In the configuration, 
Asterisk was bound to 127.0.0.1:5060, and the other party (we'll call 
him Bob) was bound to 127.0.0.2:5061. The endpoint configuration for Bob 
in Asterisk had the media_address set to 127.0.0.1. When inspecting RTP 
packets sent from Asterisk to Bob, the source IP address of the packets 
was 127.0.0.2, rather than 127.0.0.1.

The reason for this is that res_pjsip_sdp_rtp.c always binds a wildcard 
IP address ("0.0.0.0" for IPv4 or "::" for IPv6) RTP streams. In most 
cases, this causes no issue, but in cases like this, where there are 
multiple valid addresses from which to send a packet, the result may not 
be as expected. After all, the media_address that was specified for Bob 
was 127.0.0.1, so one would probably expect that media packets sent from 
Asterisk to Bob would have that as the source address. Even if no media 
address were specified, you might expect the signaling address of 
127.0.0.1 to be used as the source. However, since RTP is bound to a 
wildcard address, we're at the mercy of the system's network stack to 
pick a source IP address.

I propose the following algorithm as a fix for this issue:

1. If we are sending a media offer, and there is a configured 
media_address on the endpoint to which we are sending the offer, then 
bind the RTP stream to the media_address. This means that the rtp_ipv6 
setting will be ignored in this scenario.

2. If we are sending a media offer, and there is no configured 
media_address, and the rtp_ipv6 option indicates a preference for the 
same address family as the signaling address being used for this call, 
then bind the RTP stream to the signaling address. For instance, if the 
signaling address being used is IPv4, and rtp_ipv6 is set to "no", then 
we will bind the RTP stream to the signaling address being used for the 
call.

3. If we are sending a media offer, and there is no configured 
media_address, and the rtp_ipv6 option indicates a preference for a 
different address family than the signaling address being used for the 
call, then bind the RTP stream to a wildcard address of the family 
indicated by the rtp_ipv6 option. For instance, if the signaling address 
being used is IPv4, and rtp_ipv6 is set to "yes", then we will bind the 
RTP stream to "::".

4. If we are responding to a media offer, and there is a configured 
media_address on the endpoint, and that media_address is of the same 
address family as the offerer's media address for the given media 
stream, then we will bind the RTP stream to the media_address.

5. If we are responding to a media_offer, and there is either no 
configured media_address on the endpoint or the media_address is of a 
different IP address family than the offerer's media address for the 
given stream, and the signaling address for the call is of the same 
address family as the offerer's media address for the given stream, then 
we will bind the RTP stream to the signaling address for the call.

6. If we are responding to a media_offer, and there is either no 
configured media_address on the endpoint or the media_address is of a 
different IP address family than the offerer's media address for the 
givent stream, and the signaling address for the call is of a different 
IP address family as the offerer's media address for the given stream, 
then we will bind the RTP stream to a wildcard address of the same 
family as the offerer's media address.

In general, the algorithm attempts to honor configuration preferences 
first and fall back to binding RTP streams to wildcard addresses as a 
last resort. I'm interested in your feedback on this issue, specifically

1. Do you think the signaling address should be taken into consideration 
for this algorithm?
2. Does moving away from a wildcard binding have the potential to cause 
issues, e.g. with NAT or symmetric RTP?

Thanks for your feedback!