Re: [rtcweb] Constraint to disable IPv6 candidate collection

[Roman Shpount <[e-mail]>]

On Tue, Apr 7, 2015 at 8:30 PM, 🔓Dan Wing <[e-mail]> wrote:

> On 07-Apr-2015 03:28 pm, Roman Shpount <[e-mail]> wrote:
> > It is possible to run into interop issues with end-points that support
> ICE and DTLS-SRTP but do not support IPv6, such as current versions of
> Firefox. Chrome currently offers googIPv6 constraint, which enables or
> disables IPv6 candidate collection. Unfortunately, this constraint is
> Chrome specific, provided via deprecated interface (PeerConnection
> constructor), and when this constraint is not set, Chrome collects or does
> not collect IPv6 candidates pretty much in random. Without setting this
> constraint, the same Chrome browser on the same network includes or does
> not include IPv6 candidates with no identifiable pattern. Because of this,
> we currently set googIPv6 constraint to false. Our only other alternative
> would be to examine the SDP and remove the IPv6 candidates and replace c=
> line with IPv4 address. In anticipation of IPv6 support being enabled by
> default, and to avoid SDP mucking, it would be better to define a
> constraint that can be used to suppress IPv6 candidate collection, which
> can be provided via current constraint interfaces.
>
>
> What is the interop issue?  Are v6 candidates mistakenly attempted to be
> processed by Firefox and failing?
>
>
setRemoteDescription fails when SDP has an IN IP6 address in the c= line. I
think parsing SDP iwth IPv6 addresses is fully supported by Firefox.
_____________
Roman Shpount