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

Roman Shpount <roman@telurix.com> Fri, 01 February 2019 03:14 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 B9307130ECF for <rtcweb@ietfa.amsl.com>; Thu, 31 Jan 2019 19:14:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level:
X-Spam-Status: No, score=-2.03 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, URIBL_BLOCKED=0.001] 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 RHG9l8BhfbE9 for <rtcweb@ietfa.amsl.com>; Thu, 31 Jan 2019 19:14:23 -0800 (PST)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 E52EB126C01 for <rtcweb@ietf.org>; Thu, 31 Jan 2019 19:14:22 -0800 (PST)
Received: by mail-pl1-x629.google.com with SMTP id u6so2447566plm.8 for <rtcweb@ietf.org>; Thu, 31 Jan 2019 19:14:22 -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=bzI9e6dhSaNyiNuyS+bmjXvde8O/aNUPbXnpY/0DOnU=; b=COqs5h2beNETnzLa++GD7RJghu6wMIbOa3mLnodvLjVH977tNkOQXYTtMEFGRmYYtm 04IqZYRyEnfI1nDGzeGqn5/hrRa9FuZRge21cOHypA9ZdKZz1bdJcesI1c5gWrIz5aB/ gOc76L18bQxXsE6zuau1JZavJfHwq3yUqbQSHFeyva50ZOJTXi4Oo842/Tk0IbjvfZ13 s+rVNeAW9Qf2+JOTju//bEtZ3wyGGVKXUJ/iCMSMl4UZplmT0SMZbMd91I0Wmio3hPsn 28hKBlc+32OqFhvVsKh7kapHJlLX8ex+BEjJPL4O5WQ7XMfp2HscMmmIbViBmSjJLA5G yQKg==
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=bzI9e6dhSaNyiNuyS+bmjXvde8O/aNUPbXnpY/0DOnU=; b=Cs1EcZjp5S49nzLLUEIdSzYm39lorDllAXlE6UJ21ZniM5U7FX7l+GEz6NhN/QMnX3 Lg6V6cyxJc2oOrckbZJh8kBnQ7je4HuxDLDuN/kpsmb1zzKIt/Ojag9QjgDRJduaWzK3 H9FMzF4TYcKKuJWk6Iwt+ji45WdOiLeDr4of9APxkhxHTLMnfWxT0zlP2IVWo21zD6Hp WGNk5BW51pScvKRxFBz5lTXDFfIucgcjnQOMUX+64NEGkj0nrCtrZOlDUvjFk1HksuxY /vo8x/fzbVkEyJIeenW1zuok1BYugJb8MZqgqE35aBgLtl46/JnZLJ7synJ9AQ/Ui1mH /oUw==
X-Gm-Message-State: AJcUukd7NQ5RQmzDNWxVImVCAPO0U2i1kayvmh20A2B1CA5zX0J0rxt7 m+FNK3NmpcReDYaMWE4dV+iQhg==
X-Google-Smtp-Source: ALg8bN5qkhAN+E29NChoEtBWlpg3IGO+5IUqxeBtZgS1YDO6f7iRuGKjLy4qGAotW7RhiqZvsU/ILg==
X-Received: by 2002:a17:902:2969:: with SMTP id g96mr37345142plb.295.1548990862280; Thu, 31 Jan 2019 19:14:22 -0800 (PST)
Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com. [209.85.210.175]) by smtp.gmail.com with ESMTPSA id h74sm15017473pfd.35.2019.01.31.19.14.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Jan 2019 19:14:21 -0800 (PST)
Received: by mail-pf1-f175.google.com with SMTP id h3so2466306pfg.1; Thu, 31 Jan 2019 19:14:21 -0800 (PST)
X-Received: by 2002:a63:df13:: with SMTP id u19mr34028331pgg.294.1548990861376; Thu, 31 Jan 2019 19:14:21 -0800 (PST)
MIME-Version: 1.0
References: <CAD5OKxuGEPccJUJ1E0bSmz9RW6CWhhSqW+Dke1Cywrjp-dvaoA@mail.gmail.com> <874l9ousuk.fsf@hobgoblin.ariadne.com>
In-Reply-To: <874l9ousuk.fsf@hobgoblin.ariadne.com>
From: Roman Shpount <roman@telurix.com>
Date: Thu, 31 Jan 2019 22:14:11 -0500
X-Gmail-Original-Message-ID: <CAD5OKxut+Y8NnL2FbFQkubU-8up4eu6F9hOxs-8oBOJoCnTQwg@mail.gmail.com>
Message-ID: <CAD5OKxut+Y8NnL2FbFQkubU-8up4eu6F9hOxs-8oBOJoCnTQwg@mail.gmail.com>
To: "Dale R. Worley" <worley@ariadne.com>
Cc: mmusic WG <mmusic@ietf.org>, RTCWeb IETF <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000d81c10580cc8a6b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/64OwyhmlpgupJRoD9v6EXAiC4mA>
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: Fri, 01 Feb 2019 03:14:26 -0000

Hi Dale,

This is exactly what I've thought. I have added RtcWeb group to the email,
since they have a draft which describes using MDNS
candidates: rtcweb-mdns-ice-candidates (
https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-02) This
draft talks about replacing host candidates addresses with MDNS FQDN. What
it does not talk about is what ends up in c=/m= line in this case. In the
currently Chrome MDNS experiment, Chrome produces something like this:

v=0
o=- 5433632304511147701 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS 6bb347f4-f699-4522-99ea-215c10022f50
m=audio 59372 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
*c=IN IP6*
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:1962264367 1 udp 2122260223
3557773f-5f01-46a4-aa14-54ab35b3d778.local 59372 typ host generation 0
network-id 1 network-cost 10
a=candidate:980827103 1 tcp 1518280447
3557773f-5f01-46a4-aa14-54ab35b3d778.local 9 typ host tcptype active
generation 0 network-id 1 network-cost 10
a=ice-ufrag:3iia
a=ice-pwd:HMo0mGLq8nYb9pfnG/nH3pNI
a=ice-options:trickle
a=fingerprint:sha-256
8D:22:EF:E4:8B:7F:B3:F0:69:2E:B2:1D:4B:F1:6F:DE:62:BE:B8:DC:92:A3:F7:E5:1B:E8:87:6D:BE:E2:44:48
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:4224017887 cname:aHDhJbcPUEXkWfRL
a=ssrc:4224017887 msid:6bb347f4-f699-4522-99ea-215c10022f50
ffd9edfb-e99c-4cc3-a1dd-817f0327d021
a=ssrc:4224017887 mslabel:6bb347f4-f699-4522-99ea-215c10022f50
a=ssrc:4224017887 label:ffd9edfb-e99c-4cc3-a1dd-817f0327d021

As you can see c= line is "c=IN IP6" and is missing the contact address,
which so far breaks every client except Chrome, including Firefox.

I was curious what should go into the c= line and if this would work
anywhere, or if this is completely misguided

Regards,
_____________
Roman Shpount


On Thu, Jan 31, 2019 at 9:48 PM Dale R. Worley <worley@ariadne.com> wrote:

> Roman Shpount <roman@telurix.com> writes:
> > I wanted to see if it was ever decided if c= line should contain IN IP4
> or
> > IN IP6 when default ICE candidate address contains FQDN.
> >
> > For instance, in the following SDP:
> >
> > m=audio 59372 UDP/TLS/RTP/SAVPF 0
> > *c=IN IP6 3557773f-5f01-46a4-aa14-54ab35b3d778.local *
> > a=rtcp:9 IN IP4 0.0.0.0
> > a=candidate:1962264367 1 udp 2122260223
> > 3557773f-5f01-46a4-aa14-54ab35b3d778.local 59372 typ host
> > a=ice-ufrag:3iia
> > a=ice-pwd:HMo0mGLq8nYb9pfnG/nH3pNI
> > a=rtcp-mux
> >
> > Is it correct to use "c=IN IP6
> 3557773f-5f01-46a4-aa14-54ab35b3d778.local "
> > or should it be "c=IN IP4 3557773f-5f01-46a4-aa14-54ab35b3d778.local"?
>
> In regard to ICE *candidates*, RFC 8445 makes it clear that a candidate
> is an IP address, not an FQDN:
>
>    2.1.  Gathering Candidates
>
>    In order to execute ICE, an ICE agent identifies and gathers one or
>    more address candidates.  A candidate has a transport address -- a
>    combination of IP address and port for a particular transport
>    protocol (with only UDP specified here).  There are different types
>    of candidates; some are derived from physical or logical network
>    interfaces, and others are discoverable via STUN and TURN.
>
> The discussion of "default candidates" is a little vague due to the fact
> that the ICE specification factors out ICE from any protocol that uses
> it, but the default candidate is always a *candidate* and thus an
> address, not an FQDN:
>
>    5.2.  Lite Implementation Procedures
>
>    Next, an agent chooses a default candidate for each component of each
>    data stream.  If a host is IPv4 only, there would only be one
>    candidate for each component of each data stream; therefore, that
>    candidate is the default.  If a host is IPv6 only, the default
>    candidate would typically be a globally scoped IPv6 address.  Dual-
>    stack hosts SHOULD allow configuration whether IPv4 or IPv6 is used
>    for the default candidate, and the configuration needs to be based on
>    which one its administrator believes has a higher chance of success
>    in the current network environment.
>
>
>    5.3.  Exchanging Candidate Information
>
>    The using protocol may (or may not) need to deal with backwards
>    compatibility with older implementations that do not support ICE.  If
>    a fallback mechanism to non-ICE is supported and is being used, then
>    presumably the using protocol provides a way of conveying the default
>    candidate (its IP address and port) in addition to the ICE
>    parameters.
>
> Dale
>