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

[Joshua Colp]

Mark Michelson wrote:

<snip>

>
> 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.

I wouldn't do this. There's no guarantee that the address specified here 
is actually bound on the local system. The documentation specifically 
says for SDP.

> 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.

Fine.

> 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 "::".

Fine.

> 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.

See comment above.

> 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.

Fine.

> 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.

Fine.

> 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?

So, yes. In an ICE scenario the code will provide candidates for all 
local addresses. If you are bound to only one then all the others will 
fail. This should be taken into account - but it ultimately 
(potentially) lessens the chance of a better route.

Cheers,

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org