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!
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
