IETF Logo Mail Archive

Re: [rtcweb] Constraint to disable IPv6 candidate collection

šŸ”“Dan Wing <dwing@cisco.com> Wed, 08 April 2015 00:30 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AED91B2A2A for <rtcweb@ietfa.amsl.com>; Tue, 7 Apr 2015 17:30:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.211
X-Spam-Level:
X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRDNshpLpExv for <rtcweb@ietfa.amsl.com>; Tue, 7 Apr 2015 17:30:49 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45F2F1B2A28 for <rtcweb@ietf.org>; Tue, 7 Apr 2015 17:30:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1294; q=dns/txt; s=iport; t=1428453049; x=1429662649; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=6/JucUHlknlTqXvWc8wZi5Oab4xeF42Nk+tTii/xc0U=; b=auy89lHHYiTYLr/c1W0+M/viXPO17y4sZnrMtgNDq2cLrxyQ3uDiPFQI YE17f5+sE8gWZgbRez5qluhLEEVcjnAfutioN9OI5slwVBG6x+VbTu+mG VLme3HYo+/19eIePBdT2jkBlWNQqetpuVHgAsNAlD5l7c4qK/3Q/B2V5O Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BeBAAjdiRV/5JdJa1cgwWBLsNzCYdPAoEuOBQBAQEBAQEBfYQfAQEEOj8QCxguVwYTiCrMEQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLK4RJMweDF4EWBYsnj1SHFo1FIoQPHjGCQwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,541,1422921600"; d="scan'208";a="139173878"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP; 08 Apr 2015 00:30:48 +0000
Received: from [10.24.196.146] ([10.24.196.146]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t380UlDp014942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2015 00:30:48 GMT
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: šŸ”“Dan Wing <dwing@cisco.com>
In-Reply-To: <CAD5OKxsf6_DQF2u5VrhOzZ0t1uiV88TFyrT2Sudtbv-ytDrCJg@mail.gmail.com>
Date: Tue, 07 Apr 2015 17:30:47 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <A013385E-23AE-402C-9509-36E188B62C9E@cisco.com>
References: <CAD5OKxsf6_DQF2u5VrhOzZ0t1uiV88TFyrT2Sudtbv-ytDrCJg@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/bbDQBxQGDmnI9LnGg9nOKKQOKBI>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Constraint to disable IPv6 candidate collection
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Apr 2015 00:30:50 -0000

On 07-Apr-2015 03:28 pm, Roman Shpount <roman@telurix.com> 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?

-d

v2.23.0 | Report a Bug | By Email