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