Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate?

Roman Shpount <roman@telurix.com> Wed, 06 February 2019 01:03 UTC

Return-Path: <roman@telurix.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C53128BCC for <rtcweb@ietfa.amsl.com>; Tue, 5 Feb 2019 17:03:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.031
X-Spam-Level:
X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
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 K5JGAO9nqm4v for <rtcweb@ietfa.amsl.com>; Tue, 5 Feb 2019 17:03:52 -0800 (PST)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CFA5128CE4 for <rtcweb@ietf.org>; Tue, 5 Feb 2019 17:03:51 -0800 (PST)
Received: by mail-pf1-x436.google.com with SMTP id 64so2322270pfr.9 for <rtcweb@ietf.org>; Tue, 05 Feb 2019 17:03:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8Em3bFbsX//W0Sbg5kR97WtfmM4E8TdthFeA1COv7/M=; b=OjgybrdQ4n2tBv7vlzIUvP4YxB+jPWVV+uMxYIObn+J2eFiog/X+Fl6nNNJcpzvN0t pc3uEw8Xv2RbNfOb7dExvnasmgi+KKSfIOGLMD7N27IEr6x6NIfbVGfDNz1U3SNhv5iS SwmJ/IpYrqpnR/wy/zY5eza+F3GogwpSffyrT3K2rNC+hXtnpLJ7+ZMns67MDu8pRKCK dbExuNkm42iLQjwuiTSwRo8imto089CmuNZxLYkDDyO7G9w15SqiHMr8ruhbQiLDUkZW 9KCAgsrroW6Jz3GlVjsF03PnyuxuuyCa5ejwJNIjbNLLwQ/ljXb/ee5NeIQ+CB+SADnH 2xeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8Em3bFbsX//W0Sbg5kR97WtfmM4E8TdthFeA1COv7/M=; b=B+HrvkiNfmeqyyHAzfls/RvXoqd02YMEaAOlcKJIyS4hvf3w7c7y+KcAcJ3euGpNy0 MpMkxN16Gk1jfIC/sRi79sXMOWFPlMejuz/2b5gT2W+ifIAgDy9olITdg3Vv8wa7n8S5 djO2GF2fnTLJkGfocdAYXMd92B/lsoI7pz4RMgX4uY8918lO+pvmUb/u3Fl2r/+p6orE aN5W4VFlJnKENUg3cv5pNyjfK/nfKdHdeO0oXicm92yCRKszH9NmHpJzqh4dvhs5MYmj Z96QSctl6Pf2TIrJo2z9EoaWk35aG+qt7wvtJDZk3HQ4hgsN3LfDcu8IvU8q/TACzDRu aq5g==
X-Gm-Message-State: AHQUAubsE9sjSJTTPU5GmKkufS0POlT+ZbctB0ihPQUubrv3aAVYR7ed +JNwqr+ivw8zbUW5PHkCh5MAzOk211Q=
X-Google-Smtp-Source: AHgI3IZX9oQlDlfObI3BxDjPQw7/0B0G3HJoItKmLUVWvezPtZ29gt1aWv1Zylq0UebxJTrLcmGKIw==
X-Received: by 2002:a62:1f9d:: with SMTP id l29mr7862664pfj.14.1549415030617; Tue, 05 Feb 2019 17:03:50 -0800 (PST)
Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com. [209.85.210.173]) by smtp.gmail.com with ESMTPSA id m67sm6878069pfb.25.2019.02.05.17.03.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Feb 2019 17:03:49 -0800 (PST)
Received: by mail-pf1-f173.google.com with SMTP id 64so2322239pfr.9; Tue, 05 Feb 2019 17:03:49 -0800 (PST)
X-Received: by 2002:a63:5861:: with SMTP id i33mr7215522pgm.60.1549415028850; Tue, 05 Feb 2019 17:03:48 -0800 (PST)
MIME-Version: 1.0
References: <CAD5OKxuGEPccJUJ1E0bSmz9RW6CWhhSqW+Dke1Cywrjp-dvaoA@mail.gmail.com> <874l9ousuk.fsf@hobgoblin.ariadne.com> <CAD5OKxut+Y8NnL2FbFQkubU-8up4eu6F9hOxs-8oBOJoCnTQwg@mail.gmail.com> <CAOJ7v-2GC2UWBaqSccZh1MKg6E93NrNKQJagzMCOfuE6SxuptA@mail.gmail.com> <CAOJ7v-2ZWxDFAtfoXTB4OsfJBAaFFqZ1jt0SSCCm4Qi3Qqfj6g@mail.gmail.com> <CAD5OKxuAUaCcO8X+ESoekHMq2Ba5-hviZ08G1Vyg_qSh4mR73Q@mail.gmail.com> <CAOJ7v-0T8gbNtr22MiZzVSsAX8+4ZP-pVueKFVOuSSJLBmv8RA@mail.gmail.com> <CAD5OKxtqxcqrQGCWc_2L1np9ftk_Q=prU3MMXk7Y+wbLCq0rYA@mail.gmail.com> <CAOJ7v-1MXjLtBKJ8gN4nVm-Z9m0HB=ye9E6Wcm5zeOx5y2zkSw@mail.gmail.com> <CAD5OKxuZPX3DbDEEVXbVamHynazJkv5G6CDMqMPmdMwiW4SNdg@mail.gmail.com> <CAOJ7v-2c7baQ9UUzxxuA41jbNqeOD8SdqJgCTDAUPXwOZ7r_4Q@mail.gmail.com> <CAD5OKxsc4F4DOW6=u3XU5N3NJ4jPx35Q-8WNF_0MGZziy7=b=g@mail.gmail.com> <HE1PR07MB31617DB79BE41B64AECF082693920@HE1PR07MB3161.eurprd07.prod.outlook.com> <CAD5OKxu7Sjnp6zLo1jxnqS5_3URM6Fj9KrijSLKXERHBqr1Pkw@mail.gmail.com> <24551658-0943-431C-B319-D74B5DC169B9@gmail.com> <CAD5OKxtn4TCZCgV_4r17AqUgbFxgk1NjMBNCR0Gcn-67zRJCwQ@mail.gmail.com> <CAOJ7v-1z4P-=RQfUb1o2JGduuVNs3G-HmXNXxuvrM-4XhRH_9w@mail.gmail.com>
In-Reply-To: <CAOJ7v-1z4P-=RQfUb1o2JGduuVNs3G-HmXNXxuvrM-4XhRH_9w@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 05 Feb 2019 20:03:38 -0500
X-Gmail-Original-Message-ID: <CAD5OKxv72sfohGx1pYwsfb8hki8NPRvJ=2bbv+MrX88gk7xg1g@mail.gmail.com>
Message-ID: <CAD5OKxv72sfohGx1pYwsfb8hki8NPRvJ=2bbv+MrX88gk7xg1g@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Cc: Alan Ford <alan.ford@gmail.com>, Simon Perreault <sperreault@jive.com>, RTCWeb IETF <rtcweb@ietf.org>, mmusic WG <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="00000000000067873705812f4c36"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/0RjrZddA8ij7xFaK9D1hnTQIA_g>
Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 06 Feb 2019 01:03:55 -0000

On Tue, Feb 5, 2019 at 7:57 PM Justin Uberti <juberti@google.com> wrote:

>
> On Tue, Feb 5, 2019 at 10:19 AM Roman Shpount <roman@telurix.com> wrote:
>
>> On Tue, Feb 5, 2019 at 10:03 AM Alan Ford <alan.ford@gmail.com> wrote:
>>
>>> If that update was to be made, this goes against the text
>>> in draft-ietf-rtcweb-mdns-ice-candidates-02 which says:
>>>
>>>    An ICE agent that supports mDNS candidates MUST support the situation
>>>    where the hostname resolution results in more than one IP address.
>>>    In this case, the ICE agent MUST take exactly one of the resolved IP
>>>    addresses and ignore the others.  The ICE agent SHOULD, if available,
>>>    use the first IPv6 address resolved, otherwise the first IPv4
>>>    address.
>>>
>>
>> This is obviously not going to work. At the very minimum ICE client
>> should be listening for connectivity checks on all addresses to which FQDN
>> candidate resolves, including IPv4 and IPv6. It also should do connectivity
>> checks to all addresses. Otherwise, if you have two clients, one dual stack
>> and another single stack, they are not going to see each other, since one
>> will be listening and sending connectivity checks via IPv6 and another via
>> IPv4. This is why language about FQDN was removed from mmusic-ice-sip-sdp
>> -- it was broken.
>>
>
>> For ICE to work, you want to include all possible addresses for FQDN in
>> the candidate list and then proceed with nomination as if they were
>> independent candidates.
>>
>
> I don't think this is correct behavior, but it's really beside the point
> since we can ignore it if we have the one-FQDN-per-address concept we
> discussed.
>

I am not sure why this is wrong, but I agree this is besides the point if
we agree on one-FQDN-per-address. If we agree on one-FQDN-per-address,
rtcweb-mdns-ice-candidates needs to be modified to match. Behavior
currently described there (each sides picks an address in random) is
definitely wrong.

Regards,
_____________
Roman Shpount