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

Roman Shpount <> Thu, 11 April 2019 21:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A2A0120220 for <>; Thu, 11 Apr 2019 14:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 S_GQd4T6VH5d for <>; Thu, 11 Apr 2019 14:30:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 29089120086 for <>; Thu, 11 Apr 2019 14:30:09 -0700 (PDT)
Received: by with SMTP id b3so4009141plr.7 for <>; Thu, 11 Apr 2019 14:30:09 -0700 (PDT)
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=iXGmVHzjyqGQh1iBUFrSfTnsDjN1uCMDVUlGaYFsz4s=; b=XLdJcfZZfGkKP7eXGLXEZsFvQaKAAXheWCuVXJqz4PCX/gc95R4ggMp2QfNPrESWgf UQPwjKSDp4Zq2OISTkKnhC1Fv55qSuagCs071nO5Mla8Yuw2i31sM+JwE2bj8JFrcv/X VmT8eXWYjBjQcIaEzWxSiGNF07587GuBa6gp71s9BYsjR9NWjpQZEwYnFBY5CV5UKct6 m5P++Na4gELyIsDWmv8nnvwb0Tzpmmy/5X4zu9xDzjZKJx/dUwvUjhS9AQ7YPeSEnQm/ cf64veetVsSy0bvP6hlKtyCFnx5jhXZJnlqKC1SQ3YQ+lP4Toj3mKCL+DHwsET5H0kKT I+ew==
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=iXGmVHzjyqGQh1iBUFrSfTnsDjN1uCMDVUlGaYFsz4s=; b=iTgCRnlPxbYPGmQui1uiBnqFGkZZxjKo1nvOEqDOblunf3Fpe7k2EW30NTgs2avlSf bzG540v5FqWv68G2W1l9IVIOjd3+6+M36TgkXBqsiI93Z4QoRyBxMWt30goVZMxo/XlI iyf+fJgRqUSFW4pIT4iznDX2rsMpfdCzPm23AK+/MQKJVR1k4+RnptatYruDjFhWhXyx msFgHs+EKDYvl1+yz3LFJxRPJl/i0YRwNuAdbv+7dfP2Nv6RaLZtlWtm9yW+0yfdiN1P lMK2KHPaxSkb+Lw7cTUUweyy9mG1W6Cv78uBjypTJqqvLvxE9wHlkYnvzlQ/bU1ZlYD6 ucRg==
X-Gm-Message-State: APjAAAUpCtYc6GU5ii5kYw5Ng6DFSVBTzn5I/nH3XTyJu9PI2MwKVO2d CCfyGJaiQoXJAkFnBVG2y0tKa3s3/WU=
X-Google-Smtp-Source: APXvYqxiW2bSh5TcmAht/XeEQUNa+HlSa+1/oCC3Hfy6Z9pUUY6WCAF9l1y/NqcBc3QHV4QWlU9n+g==
X-Received: by 2002:a17:902:7885:: with SMTP id q5mr53563616pll.12.1555018208386; Thu, 11 Apr 2019 14:30:08 -0700 (PDT)
Received: from ( []) by with ESMTPSA id q10sm48476333pgh.93.2019. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2019 14:30:07 -0700 (PDT)
Received: by with SMTP id e6so4117473pgc.4 for <>; Thu, 11 Apr 2019 14:30:07 -0700 (PDT)
X-Received: by 2002:a62:4602:: with SMTP id t2mr52083307pfa.26.1555018207256; Thu, 11 Apr 2019 14:30:07 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Roman Shpount <>
Date: Thu, 11 Apr 2019 17:29:53 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Christer Holmberg <>
Cc: Suhas Nandakumar <>, mmusic WG <>, Flemming Andreasen <>
Content-Type: multipart/alternative; boundary="000000000000dcec84058647e3b1"
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 21:30:11 -0000

On Thu, Apr 11, 2019 at 5:10 AM Christer Holmberg <> wrote:

> I **think** I agree with Suhas that the FQDN handling should be a
> separate draft – a generic ICE draft produced by the ICE WG. ice-sip-sdp
> would then specify how it is implemented in SDP (separate a=candidiate
> lines etc).
> Perhaps it could be combined with the mDNS draft?
I am not sure if this belongs to a new draft or mDNS draft. We can decide
this later. What we need to decide now comes down to two choices:

a. Say that FQND is allowed in candidate connection-address but these
candidate lines are skipped. Handling of FQDN lines is defined in the
future specification.

b. Figure out how FQDN is handled. Options written up so far imply either
selecting one resolution result in random or requiring the FQDN resolves to
a single address. I think former is broken and later does not exist in real
life. I would not like this draft to be released with either option. I
think adding address type to candidate brings candidate line connection
address definition in line with SDP c= line specification and should work,
but someone needs to review this. I do not think this will require more
then 2-3 extra paragraphs in the document which I am willing to write. I
agree this is scope creep but FQDN were included in RFC 5245 so people
expect them to be supported by this draft as well.

At the end, this is up to the group to decide. I just need something I can
implement. If option a makes people unhappy then we will need to find
minimal viable option b.

Roman Shpount