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

Roman Shpount <> Fri, 01 February 2019 20:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 204F7130E84 for <>; Fri, 1 Feb 2019 12:22:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.03
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2quyvbQGta15 for <>; Fri, 1 Feb 2019 12:22:28 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D86E7130E6A for <>; Fri, 1 Feb 2019 12:22:27 -0800 (PST)
Received: by with SMTP id t13so3429614pgr.11 for <>; Fri, 01 Feb 2019 12:22:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZxiszQvP8ZFDDvqn+Bf1lIlGwm+vjhJUim4CvEgEaHQ=; b=P6UXgvFmxnhUSbYRiOimooOaR7ScKbVThYvHTEQ8rvCzm2DbLVxg7Wkjda9Mtxnoqp oTjCBJcnBEBqCQNl3IdzICTyJk3Dvk3Cqrg42O4BRrgxD00dQb9iFS7xZmgT7ZwqCDRr 2Ron1C0Smmx0aoeUWRH1sVsPh4xrRlSf2VlnbMyzHGSXmyr5J8ah6EqyyiVmhDoB39CT v4v6y5+CGogOOHG69VD4qwwRGkC6Uy7vQSw4u+k3/i/dn3dcXWpNwWFPfPDQuLjQM9QX xP+B6sgC6DQbYNQtq+S/PJVOSUZLXWamRqTqkEGcROf4QvgUptDceiQgH7xrcCTxolxI NTJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZxiszQvP8ZFDDvqn+Bf1lIlGwm+vjhJUim4CvEgEaHQ=; b=Ap7lMFkVUWUisEi1Qp+itQwREsZuEIiWI3lstdv+us+qKEkAcdGZ0y0892gwhJ7fZ4 D0204uqAiDrmCNoA7ZVzAUqdGS75NczqHcFh+1vfnhfcoVR9atVQYg/e4uvYM4MX3CEM ZzJbHSzKslpVHJIglw8NBpS9zaVV0xHNJLcATe0DcsioCTkx/o75u6C9yKis/O7GCzfi zcTyLZRs1iGFsnMJsCKszpggZaLk2nMeT0IRpjGyQ7XwIcafVo4CnJKFaw2piPwW7y3z GfbjanfSY5DOSWqi1JeuYdVDF7jkclenzkOnBXphKSx5wmI7nV38p4M/KbBX56oMMMy/ F6Ew==
X-Gm-Message-State: AJcUukcDimdXs8sz0Hruq6wpbU9DcF61OyZ0Umz2lqhbyS62B19aT0gd 1uL/k/ErBwQcwRn+qEvd40nEF1AA1pc=
X-Google-Smtp-Source: ALg8bN5hpoGCwNe0h9Fsle3nr2V7nrqY64s6o6KVRM23P0HC7lRWDSPpQjfvf+bZ2kMIaetHnK6hsQ==
X-Received: by 2002:a63:1f1c:: with SMTP id f28mr37082470pgf.193.1549052547104; Fri, 01 Feb 2019 12:22:27 -0800 (PST)
Received: from ( []) by with ESMTPSA id c13sm10673219pfo.121.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Feb 2019 12:22:26 -0800 (PST)
Received: by with SMTP id z11so3458617pgu.0; Fri, 01 Feb 2019 12:22:26 -0800 (PST)
X-Received: by 2002:a63:b4c:: with SMTP id a12mr3678195pgl.131.1549052545848; Fri, 01 Feb 2019 12:22:25 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Roman Shpount <>
Date: Fri, 01 Feb 2019 15:22:15 -0500
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Justin Uberti <>
Cc: "Dale R. Worley" <>, RTCWeb IETF <>, mmusic WG <>, Simon Perreault <>
Content-Type: multipart/alternative; boundary="000000000000bbdaa90580dae688"
Archived-At: <>
Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Feb 2019 20:22:30 -0000

On Fri, Feb 1, 2019 at 2:39 PM Justin Uberti <> wrote:

> This has all been discussed at length in rtcweb and I don't think any
> significant changes are needed, although I tend to think that we should
> restore the removed FQDN text from mmusic-ice-sip-sdp, which is the only
> thing not in alignment at this point in time.

I agree that FQDN should be put back into connection-address definition,
but  the portion which talks about handling it is completely broken.

Quoting 5245 <>:

   <connection-address>:  is taken from RFC 4566
<> [RFC4566
<>].  It is the
      IP address of the candidate, allowing for IPv4 addresses, IPv6
      addresses, and *fully qualified domain names (FQDNs).*  When parsing
      this field, an agent can differentiate an IPv4 address and an IPv6

      address by presence of a colon in its value - the presence of a
      colon indicates IPv6.  An agent MUST ignore candidate lines that
      include candidates with IP address versions that are not supported
      or recognized.  An IP address SHOULD be used, but an FQDN MAY be
      used in place of an IP address.  In that case, when receiving an
      offer or answer containing an FQDN in an a=candidate attribute,
      the FQDN is looked up in the DNS first using an AAAA record
      (assuming the agent supports IPv6), and if no result is found or
      the agent only supports IPv4, using an A.  If the DNS query
      returns more than one IP address, one is chosen, and then used for
      the remainder of ICE processing.

I think it was discussed in quite a detail why using a random DNS
resolution result is not going to work here.

The only options we have here are:

a. Fix FQDN connection address handling. Probably the most logical way of
dealing with this would be to specify that candidate with FQDN should be
converted as a result of DNS resolution into multiple candidates, with each
candidate corresponding to A or AAAA record in DNS query result. We will
also need to specify how FQDN candidate gets applied to c= line address.
Something that says IN IP4 FQDN, if any A records exist for this DNS name
and IN IP6 FQDN if only AAAA records exist. Once candidate is nominated,
address family in c= line should match address family used for
communications. This will definitely require a lot more work and discussion.

b. Specify that FQDN connection addresses should be ignored until their
handling is defined in a future specification. This seems easy and only
requires a sentence or two to fix.

Roman Shpount