Re: [rtcweb] Dual stack RTCweb

[Harald Alvestrand <[e-mail]>]

On 08/15/11 17:14, Olle E. Johansson wrote:
> 15 aug 2011 kl. 11:24 skrev Bernard Aboba:
>
>> ICE is designed to handle dual stack operation.  It can even deal with NAT64, if correctly implemented.
>>
>> Since ICE tests pairs before using them, there is no "happy eyeballs" problem with ICE (e.g. if an IPv6 route doesn't exist, the test will fail).
>>
>> That said, IPv6/IPv4 priorities may need some adjustment in some situations (e.g. if the IPv6 routes are more circuitous than IPv4, it may not make sense to prefer IPv6 over IPv4).
>>
>> That is one of the reasons that I am not enthusiastic about treating the SDP JSON blob as "opaque" (e.g. not subject to adjustment). Doing so without the ability
>> to adjust IPv6/IPv4 priorities will result in poor performance in dual stack operation in some cases.
>>
>>
> Well, if we use SRV records, the receiving part may use SRV to indicate preference.
I think the ICE procedure for connecting doesn't do any DNS lookups.
In which phase of the negotiation are you suggesting we look up SRV records?

Not having any opinion on the idea, just trying to figure out what we're 
talking about.
> Now, if I have an IPv6 only client ICE won't help unless we force turn usage for IPv6 only clients so that they offer dual stack always (like the current recommendation for SIP).
we can't force anything, but I do see IPv6-only clients as a powerful 
argument for offering dual-stack TURN servers.

I'm not 100% sure .... if client A is IPv6 only, and has a dual-stack 
TURN server, while client B is IPv4 only and does not have (or does not 
want to use) a TURN server .... will the connection complete in both 
directions?

It's easier to imagine that dual-stack TURN servers will be deployed 
usefully if only the service provider that wants to support the 
IPv6-only client will have to do anything.