Re: [MMUSIC] FQDN support in ice-sip-sdp

Suhas Nandakumar <> Thu, 11 April 2019 08:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 658AC12029B for <>; Thu, 11 Apr 2019 01:03:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 jcAr1hoywtSi for <>; Thu, 11 Apr 2019 01:03:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C25601202AD for <>; Thu, 11 Apr 2019 01:03:28 -0700 (PDT)
Received: by with SMTP id n4so2967340vsm.3 for <>; Thu, 11 Apr 2019 01:03:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rsWukwhmvaf7CamjeLYtDRZZhotxpD+ZuAIrMqd77xs=; b=QYgCcRl2idK+SZ4HpcA3dw/PAUDOKBQBhAawMLu15dASSV5wMlBHuoJtA0no0VWKT/ klv4bpot0E2pD9YgBN8ipLSViia4V43JegbX7WijzaVTFuFTHOEouDYi/v6YQhL2OHBD voAFINTWchEMqsXPunxCqfq8MtcD69mEAx4cUIxTCoSGLY5z4AN3cLdXfOiBXtQoa/z+ BxVFL1/pHKKrj+3Zn3xgQDha9Q5KEpQvaN3S1AkTdvvi/stTO24fvVAFJPLa7uP0IA6L enNbJqD9LNUhkBhU/NEt5JC/gPFIkNs7MF2Rm1gRwx/Yq7dics/k39/uYrL+Uf5HJYAy C0HQ==
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=rsWukwhmvaf7CamjeLYtDRZZhotxpD+ZuAIrMqd77xs=; b=d4LxGAaP/IiduGM6vdfyCDirBFqzaMbKiSZYLbrWQCVAFijLQ8uGYvNwwv7zNPRl8i NtzB4dhSmPdRi7gvFSNHDHRTrB41c1+WxBauFNpxaVrilRc/t2tv4GPdBRMdsI2Mb3Zk e8eS1Id/v2wL48U2tofqs0el4fjvowgdUNu+Ir/Lgffpb6gdFbgSxx/aHccFjo3LiyYQ VYyNnquA9IDPTiaPZoKlLCvDMRbnMyGXXyUFm2OXctNIRpbxM/THIWaKGAObU6hb8G7m KpxexNnPjcFGsuU9UlBcH59AtvVWvY5D1ZNugaBv4f7WIzAj55aVOBw3DszQGZ/qDoe8 cJFA==
X-Gm-Message-State: APjAAAWId//3fEHcc4a0tgSt/bAv/Vms1JXE2Nq29FyfSoTtwndkhvAK yRQ5hprFawzI35JV1KL36BlIIF0M87ou2WDQdsw=
X-Google-Smtp-Source: APXvYqzBnTdxdVHcB7mNO1dijLc8nsfNVO4onU/5K85u+MCP1lY7Ya02muoOPmeywLLhzBPwUH/UX9H7LzxYGXeWEhQ=
X-Received: by 2002:a67:80c8:: with SMTP id b191mr26298141vsd.184.1554969807868; Thu, 11 Apr 2019 01:03:27 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Suhas Nandakumar <>
Date: Thu, 11 Apr 2019 01:03:17 -0700
Message-ID: <>
To: Roman Shpount <>
Cc: Christer Holmberg <>, Suhas Nandakumar <>, mmusic WG <>, Flemming Andreasen <>
Content-Type: multipart/alternative; boundary="00000000000008d78b05863c9fa8"
Archived-At: <>
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Apr 2019 08:03:36 -0000

On Wed, Apr 10, 2019 at 12:36 PM Roman Shpount <> wrote:

> On Wed, Apr 10, 2019 at 3:13 PM Christer Holmberg <
>> wrote:
>> >Limiting FQDN scope to resolving to just one address is an
>> unimplementable requirement. Currently on large number of devices, FQDN
>> >which is supposed to resolve to IPv4 address only, will resolve to both
>> IPv6 and IPv4 addresses. For instance on virtually all IOS and most
>> >of the Android devices on mobile networks FQDN pointing to IPv4 returns
>> results for IPv6 as well. Essentially what we are specifying now is
>> >that ICE candidates with FQDN address MUST be ignored.
>> Isn’t the main reason for allowing FQDN to enable usage of mDNS?
>  It is now. Nothing in the latest language that I propose prohibits mDNS
> draft define how FQDN are supposed to work when mDNS is used. All my
> language states that default treatment for FQDN is to ignore it which keeps
> mDNS backwards compatible. I would also suggest adding an ICE option to
> specify that mDNS is supported. This being said, I am not sure mDNS
> prevents IPv4 address being resolved as IPv6 through DNS64, so mDNS is
> likely going to end up with two addresses for a single candidate.
> In my opinion, the current ICE procedures assumes one IP address:port per
>> candidate. If we allow a candidate to be associated with multiple IP
>> addresses:ports, we would have to modify the ICE procedures in order to
>> handle that: how a candidate can be part of multiple foundations (one for
>> each resolved IP address:port), how the freezing/unfreezing procedure work,
>> whether connectivity checks are sent to all resolved addresses, how the
>> state of the candidate is set if one IP address:port succeeds but another
>> doesn’t. Or, should the candidate be split into multiple candidates (one
>> for each resolved IP address:port)? Etc etc etc etc etc. All of that could
>> probably be done, but I think it would be quite a bit of work- an update
>> (or even a bis) to RFC 8445. It is **NOT** an ice-sip-sdp specific issue
>> in my opinion.
> I am not suggesting changing that only one address is supported per
> candidate. What I am suggesting is that candidate needs some sort of hint
> when FQDN is used to specify how address should be resolved. Here is my
> proposed solution:
> Add a candidate extension which specifies candidate address type,
> something like addrtype which can be set to "inipv4" or "inipv6". If IP
> address is used and it does not match the addrtype candidate extension,
> this candidate is ignored. When FQDN is used, it is resolved using A DNS
> request when addrtype is inipv4 or not present and using AAAA DNS request
> when addrtype is inipv6. Address family in c= line, when FQDN is a default
> candidate must be IN IPV4 if addrtype is inipv4 or not present, and must be
> IP IPV6 if addrtype is inipv6
> Example:
> a=candidate:2319437384 1 udp 2122260223 8a2fd7b5-41d5-4c15-ad83-d33a0d66a75a.local
> 60454 typ host *inipv4*
> a=candidate:2319437384 1 udp 2122260223 8a2fd7b5-41d5-4c15-ad83-d33a0d66a78b.local
> 60454 typ host *inipv6*
I am not for or against the proposal. I am sure its fine.  I am concerned
about the scope of this change and current implementations who are willing
to support this new extension. Why can't this be in a total new draft ?

> This keeps each candidate line to one address and works in cases when FQDN
> resolves to one IPv4 and one IPv6 address due to something like DNS64.
> Regards,
>  _____________
> Roman Shpount