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

Justin Uberti <juberti@google.com> Fri, 01 February 2019 03:57 UTC

Return-Path: <juberti@google.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 CE53B131200 for <rtcweb@ietfa.amsl.com>; Thu, 31 Jan 2019 19:57:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.641
X-Spam-Level:
X-Spam-Status: No, score=-17.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 KorP4rL780K4 for <rtcweb@ietfa.amsl.com>; Thu, 31 Jan 2019 19:57:06 -0800 (PST)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 4B4A61311F8 for <rtcweb@ietf.org>; Thu, 31 Jan 2019 19:57:06 -0800 (PST)
Received: by mail-io1-xd2d.google.com with SMTP id l14so4641874ioj.5 for <rtcweb@ietf.org>; Thu, 31 Jan 2019 19:57:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8U1Y4Ye3Ux1+pPT9bvBcAgNlPZFyZiff9QTX9l+takY=; b=ZEvwGHqZfpyJ4yqnCF5ux54koFnbgW7XNVT78ufLLujczLQYzpfNketZmgeltON66j vAZEJgb3aTUbZ88CNkCV1UBjEQncu4uxUYGP6MYxB+Tz4YateEFqCY7pVewDlKm3vbyJ wlQN90TdIvVF8RjbBwwZBGkT35ietmjew6ksKWf/dm4ki8cR5jXSYINkRpXeHWdnUAGY ul/TL9QzU4Z7+xz2RFe9C35Ge6l0gm44RZci7apV5ByRHtT0Z/JL4FzlHg93tROGgffl 2gRW13PDBZnfuBW1T2Q99YD3fDV/xiql8UrIu/F2Ee3c132lx0HMeWyNfLXfZMkVnEKu MWAg==
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=8U1Y4Ye3Ux1+pPT9bvBcAgNlPZFyZiff9QTX9l+takY=; b=njrQOI6B78tPLTQ5E/BGLyCctcxxrwtdhh4gHTOz63h+GpdRM0L0a6aoPqRjNCbmFg k31Ka74fFrrcWsq4+g1Y9KmbClUqVWKi87ZQdv1xIGmJiHY1NyDBjuKC/TEUkvQxYuR4 +pX1YAv/dd77+WZ1AQhwYmmum/PsZ1EVg5F/hMdqCsLgONbbz5QSUwRs8vKwnedP5Jqw GkKG1BW7sOBB8iCP59aJcRzDCDYFZRqYwtmWXchRgFzCZp9MEvk07L4AfV9X6f6jkKdb bdLusGhaVcgdb5udCMeau5q5uvT4lLrHJIA88k9l6sH2JWoeTm8bH9DA0jUQwCjCsnQK o8YA==
X-Gm-Message-State: AHQUAuZDlImPN6nOME9Bp+cY404i4bDf+rx/05izAEjV7eSAHEioTlCe u8JA/HSqhRXRK6GxCJX98esfYiR9OXW5xxIoPHv42mJaX1Y=
X-Google-Smtp-Source: AHgI3IaSooz+NGerzgAwtQJ0kqWIcftYFZN8Qm3Bt9yqv9o6zW8XXny1sxVFvPXxfJs4WJGlGGFSxGljXgRzvR39I1c=
X-Received: by 2002:a5e:920d:: with SMTP id y13mr19975520iop.95.1548993425106; Thu, 31 Jan 2019 19:57:05 -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>
In-Reply-To: <CAD5OKxut+Y8NnL2FbFQkubU-8up4eu6F9hOxs-8oBOJoCnTQwg@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Thu, 31 Jan 2019 19:56:52 -0800
Message-ID: <CAOJ7v-2GC2UWBaqSccZh1MKg6E93NrNKQJagzMCOfuE6SxuptA@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Cc: "Dale R. Worley" <worley@ariadne.com>, RTCWeb IETF <rtcweb@ietf.org>, mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dd91f00580cd2251"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/fLzMaQ5RSJUOlZ0h0Iq921RNaYY>
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:57:10 -0000

I looked into this before and it's pretty clear that ICE candidate and c=
line can both contain FQDN.

On Thu, Jan 31, 2019 at 7:14 PM Roman Shpount <roman@telurix.com> wrote:

> 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
>>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>