Re: [MMUSIC] ICE candidate address selection update draft

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Jonathan Lennox [mailto:[e-mail]]
> Sent: Tuesday, August 07, 2012 2:53 AM
> To: Dan Wing; 'Ari Keranen'
> Cc: [e-mail]
> Subject: RE: [MMUSIC] ICE candidate address selection update draft
> 
> On Tuesday, August 7 2012, "Dan Wing" wrote to "'Jonathan Lennox', 'Ari
> Keranen', [e-mail]" saying:
> 
> > Mine would be to take the list of IPv6 and IPv4 addresses and try
> them
> > in the order described by ICE (which currently recommends following
> > the OS's default, which is sometimes hard to get depending on the
> OS).
> > But if the first IPv6 candidate didn't return a connectivity checks
> > quickly (let's say, 150ms), initiate a connectivity check on the
> > highest priority IPv4 address next.  In that 150ms, based on ICE's
> > pacing, many IPv6 addresses will have been tried.  150ms gives plenty
> > of time for IPv6 to 'win', before using an IPv4 resource that is
> > likely shared with IPv4-only devices.
> 
> Can't this result in the endpoints getting out of sync with the order
> of the checklist?  If one side has started IPv4 while the other hasn't,
> you won't have the outbound packets coming from one side to create the
> port bindings.

Don't we already have that problem if both peers are dual-stack, and 
one side has many more IPv6 candidates than the other side?


But, to avoid the problem you describe, seems we should try IPv6
and try IPv4 in a somewhat parallel fashion.  Echos of Happy 
Eyeballs.

-d