Re: [rtcweb] Constraint to disable IPv6 candidate collection

[Harald Alvestrand <[e-mail]>]

Den 09. april 2015 11:31, skrev Roman Shpount:
> On Wed, Apr 8, 2015 at 5:20 AM, Iñaki Baz Castillo <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     2015-04-08 0:28 GMT+02:00 Roman Shpount <[e-mail]
>     <mailto:[e-mail]>>:
>     > it would be better to define a constraint that can be used to suppress
>     > IPv6 candidate collection
> 
>     I'm against any approach or option that treats IPv6 as "optional" or
>     less important than IPv4. IMHO if Firefox fails (even) to parse IPv6
>     candidates, the vendor should fix it.
> 
>     Said that, it is very *sad* that Firefox fails to parse an SDP due to
>     an IPv6 address in the c= line. Come on! this is about a grammar
>     defined more than 15 years ago!
> 
> 
> We will retest Firefox 37 for IPv6, but this was really not the reason
> for the constraint, but an illustration of the problem. This issue was
> brought up as one of the examples of SDP mucking that is currently
> required to deal with interop issues. Until IPv6 is implemented by
> default in both Chrome and  Firefox, we will be in the state of
> transition. During this transition all surrounding services would need
> to be updated to IPv6 and tested with the browser implementations. Until
> this happens, IPv6 as a feature would need to be disabled in the
> JavaScript client code.

<rant>
Just to make sure we're all on the same page here:

This is NOT what we're talking about.

We're talking about the c= line, which is meaningless semantic noise
added to SDP for backwards compatibility, and which all conformant
WebRTC implementations will ignore in favor of the ICE candidate lines.

The only purpuse the c= line has in the WebRTC context is to serve as
fodder for intercepting proxies that read the SDP and take action based
on the c= line because they don't understand ICE candidates.

The claim that has been made is that putting IPv6 addresses into the c=
line causes parsing of the SDP to fail in certain contexts.

If the only example of this issue is an old version of Firefox that will
go away at the speed at which Firefox replaces old versions - I say
"good riddance", and let's ignore the issue - it does not need solving.

If the issue exists for other ecosystem components (such as the
aforementioned proxies), this is a sad statement about the state of the
art in SDP parsing - but I could see an argument for changing the
generated default for this (semantically meaningless) value to be
something that makes fewer spec-violating parsers behave strangely.

This is NOT about introducing IPv6 - we've got address families in ICE
candidates for that, and nobody's reported a problem with those.

This is SOLELY about how far we bend over in order to not provoke broken
SDP parsers.

</rant>