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

Roman Shpount <roman@telurix.com> Tue, 05 February 2019 18:19 UTC

Return-Path: <roman@telurix.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C121311B5 for <mmusic@ietfa.amsl.com>; Tue, 5 Feb 2019 10:19:21 -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=ham 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 iCUP-HFUr4rh for <mmusic@ietfa.amsl.com>; Tue, 5 Feb 2019 10:19:19 -0800 (PST)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 4C39C1311D7 for <mmusic@ietf.org>; Tue, 5 Feb 2019 10:19:19 -0800 (PST)
Received: by mail-pg1-x531.google.com with SMTP id d72so1720937pga.9 for <mmusic@ietf.org>; Tue, 05 Feb 2019 10:19:19 -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=5C7Wzh1W2jkgNal52qiy3718jGsLLm53TwMcxaUG1jI=; b=q2kGLaBq55xRiugKR0/C+IeJgryuM8x9QjCIwd9nUEJjLXqemV630s+BNKPp5vXvDK mDwNS0BNbb4vJdUGgM1pW/cjMqpFWjJhu7j2MxOXDTm2dVkMw+bJ/lPfxQQz3xxDt01H dFuQBnIcsLx3wc0z0Kh+vV+15skhOAB4QxLCChKd5iy1Wq/wWdyzUs2UrMYaFMR2U8zb mR2ENhScWrQ4pjggIMM7JmZxGGHL8eRnTP3WdvH5xTP4AcHXih6IXWuEFqbJZTcRBtQK 8rYAwYIQBLaud1BAuCShKLT6LfznqPU8sdzUfyDhjDVeYwAQ/4bn8mxLM3DpyCI2ObZa kTDA==
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=5C7Wzh1W2jkgNal52qiy3718jGsLLm53TwMcxaUG1jI=; b=leDS9pYowOqn661t+rwrsFGBYbotLnTpbEmdBTZMvnnfEn1O8f52OnxK3B4qpMydyd liGEkxIgkSnUX2RQ1bS5jgdUnvKOWx8QvY3FbK1RMVrIw8lhLLbPSsjiQHLwTD9o980i Z05Non7i0An97WTv/sFg9IxYF47GMH4CNtP9rScL7RwMluJjSBVQ8zngYYQGKO7hj0SM XAbOP1q5wyYN8F+3sO6nRQUEfPx45FymSa8klnME9POBzgm0GeHf2c/uaHqNgiVsIQM/ ABYoTJhZZK343LO32mWdaZm/30LKlDMVjHX6Ow7whTCJrNpfJwZCc8H2nO0jVwmF1rpD JESA==
X-Gm-Message-State: AHQUAuaxgj/ZGgLEfhdih/ZkAa2l0a+QD8WPmzK68XCTTaMU0KRcvczG Esth5u2Jhtu6mqAd4WHHQcQ9bQ==
X-Google-Smtp-Source: AHgI3Ia0+ZXEFkbGFM/uf/Lxu7wWrB2j+kAuFQYpYX9UUl0NC/xluV4LBjLr8c0pqaGpVif6u1nqLg==
X-Received: by 2002:a65:6553:: with SMTP id a19mr1321543pgw.267.1549390758510; Tue, 05 Feb 2019 10:19:18 -0800 (PST)
Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com. [209.85.214.181]) by smtp.gmail.com with ESMTPSA id x186sm5095034pfb.59.2019.02.05.10.19.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Feb 2019 10:19:17 -0800 (PST)
Received: by mail-pl1-f181.google.com with SMTP id u18so1846577plq.7; Tue, 05 Feb 2019 10:19:17 -0800 (PST)
X-Received: by 2002:a17:902:8b88:: with SMTP id ay8mr6476391plb.55.1549390757224; Tue, 05 Feb 2019 10:19:17 -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>
In-Reply-To: <24551658-0943-431C-B319-D74B5DC169B9@gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 05 Feb 2019 13:19:06 -0500
X-Gmail-Original-Message-ID: <CAD5OKxtn4TCZCgV_4r17AqUgbFxgk1NjMBNCR0Gcn-67zRJCwQ@mail.gmail.com>
Message-ID: <CAD5OKxtn4TCZCgV_4r17AqUgbFxgk1NjMBNCR0Gcn-67zRJCwQ@mail.gmail.com>
To: Alan Ford <alan.ford@gmail.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, Simon Perreault <sperreault@jive.com>, RTCWeb IETF <rtcweb@ietf.org>, mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b3e5af058129a5d8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/hF0WLd2R3JVG03Sec8THXfEM5J8>
Subject: Re: [MMUSIC] [rtcweb] What goes into c= line address when FQDN is used for the default candidate?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Feb 2019 18:19:27 -0000

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.

But there’s a bigger problem here, which is how to cope with an FQDN is not
> resolvable. So the intention, as I understand it, is that when these host
> candidates leave the mDNS domain and are thus not resolvable, they will be
> treated as peer reflexive candidates.
>
> But at that point there is no address family information available, so how
> does an ICE agent know to do pairing with these candidates, which requires
> the address family to be known?
>

I do not think this is a problem. For peer reflexive candidates, ICE agent
knows address family/local address/port where connectivity check was
received and the address family/remote address/port from which the
connectivity check was received. Everything, including the address family
is known in this case and agent can proceed with nomination as with any
other peer reflexive candidate.

Regards,
_____________
Roman Shpount