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

Roman Shpount <roman@telurix.com> Wed, 17 April 2019 00:18 UTC

Return-Path: <roman@telurix.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA7F1201BF for <mmusic@ietfa.amsl.com>; Tue, 16 Apr 2019 17:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 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] 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 VMq2qWrZOdzH for <mmusic@ietfa.amsl.com>; Tue, 16 Apr 2019 17:18:09 -0700 (PDT)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 57521120199 for <mmusic@ietf.org>; Tue, 16 Apr 2019 17:18:09 -0700 (PDT)
Received: by mail-pl1-x636.google.com with SMTP id y6so11107507pll.13 for <mmusic@ietf.org>; Tue, 16 Apr 2019 17:18:09 -0700 (PDT)
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=s92/C/PjFiJdVHn/Zs8r/uLsfHGHX0WAmn1PuNCdm+k=; b=kHyFEtJLRND/DK/28RMuikQny7Q0IvDlq6Jxu346e7qAAYrDEorx4XyDgKTvbC1QAM 0R7t7UDd5lFsmZ4zNeuPcDm24EbyockVpaObc13/sDGGYpTUx1/L47N51DjG+4QibI+f tn1eKd39dkSWDymu5DztI8y/AfDMAtTwTT5y+vnPhCXuuhpl63CRQZEc2n2ITrYFGB5d zqBULc/IjcU6FEpCUW1lCV3mm4tVZgWasXdLPFctnoCahFp4UfuKvdYl5djGwFlCcqyB crW9yi9Geq2DTsar+dpaK6F5aHFezClG998QMDkE77gDIs81wG3Us2om7PhydxOXFoxm 7O6g==
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=s92/C/PjFiJdVHn/Zs8r/uLsfHGHX0WAmn1PuNCdm+k=; b=ecQ92mzJUvczr1E3DL7fSzMETs4q0ktF5f8KEPg2if2ePy+PAf+Xscb192bc1JJMew 3WwvpP6nWbfg9SVZHeltwHHkCMTI7vAP6Nep+cWcSvKuXrrqGNslLQtRrmj1SZzBYh14 jWwgxS56uaLKUF3FDhtKixisJvgCBTM48z3I0cJtgypQYFLtYHnDKp0nOe5cQpyEPgMw mSgEhFoCUSrYob/l0yXgLwiH5Xh0OjiTjRwrDXchZt+hVMHP4h5w0Rbx3NdT22sMZMcT w+BJzkEzDS2CCqsBfxAnoX7Bm2mQiK1+bEI6WYWYY9KWXIrFdspGgDDSlyCwSimet1Yo I/uw==
X-Gm-Message-State: APjAAAVSUkwklSWDgjhbriDIaihGCX5FPxqjsLhARsOxFXKvHzk0QUKn bHakK/kCWYZ7grgLnSEQGcy/gtLaJas=
X-Google-Smtp-Source: APXvYqxqkOViLp3DZDf+zt3e0n5tb0LafH6qwk5QVp6HfXnqCIugOGJ+qCwFoDT5jQY2tspGe9WlFg==
X-Received: by 2002:a17:902:42:: with SMTP id 60mr47525664pla.79.1555460288606; Tue, 16 Apr 2019 17:18:08 -0700 (PDT)
Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com. [209.85.214.173]) by smtp.gmail.com with ESMTPSA id b15sm72947637pgg.90.2019.04.16.17.18.07 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Apr 2019 17:18:07 -0700 (PDT)
Received: by mail-pl1-f173.google.com with SMTP id f36so11135674plb.5 for <mmusic@ietf.org>; Tue, 16 Apr 2019 17:18:07 -0700 (PDT)
X-Received: by 2002:a17:902:7c8c:: with SMTP id y12mr85263992pll.209.1555460287040; Tue, 16 Apr 2019 17:18:07 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5OKxux4s=4TtA7vQT0X-u+3RS+MVHG=RjgGDHWQ5H1k0OdLg@mail.gmail.com> <CAMRcRGTmYB-CMXA5ToPhdPtLrTeKmdeZCLT-ecxfTYGHEh-HMQ@mail.gmail.com> <CAD5OKxsPDagYEFFMhxGnm3H+gAWEsKmt41rw44GCmorneVytzQ@mail.gmail.com> <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com> <CAD5OKxsbQhU_1ADsnbcHUtfoiK96We004AEmtajO-EvY0dRd7Q@mail.gmail.com> <CAMRcRGSWEQ9UVJUZy9rMzX=HxDBihYNDUfSyqZcR0d=msJXZXA@mail.gmail.com> <98CF630B-5CCD-4CE4-84B4-81A4C53979DC@ericsson.com> <CAD5OKxuxKGbF8e6E9nqE1YU8amr+tsxggRb=BCCu7O6sAipz5A@mail.gmail.com> <ADB632EC-B32F-4932-89AF-69A74B5D89D5@ericsson.com> <CAD5OKxuUwi62CAfwpWcwD1v2Yzs8nY2wSZ7bjXH0yLk9QkdKEw@mail.gmail.com> <1552A692-1020-43CA-B15E-92595729EE8B@ericsson.com> <CAD5OKxvaxL0_fZU7N1VS2Bf6zojjD2qhZZybxf37=jzdEhu=ww@mail.gmail.com> <6EA23696-949C-40CF-BEBE-006A59856BDF@ericsson.com>
In-Reply-To: <6EA23696-949C-40CF-BEBE-006A59856BDF@ericsson.com>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 16 Apr 2019 20:17:54 -0400
X-Gmail-Original-Message-ID: <CAD5OKxsNAZJvpEHaDdQShAYGk=RavRMN7iQp7keh9=aBs++hqQ@mail.gmail.com>
Message-ID: <CAD5OKxsNAZJvpEHaDdQShAYGk=RavRMN7iQp7keh9=aBs++hqQ@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Flemming Andreasen <fandreas@cisco.com>, mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000df15070586aed172"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/2aAsjQYXTQu08Dhka8Pi2k60nMs>
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2019 00:18:11 -0000

Hi,

On Mon, Apr 15, 2019 at 4:13 AM Christer Holmberg <
christer.holmberg@ericsson.com>; wrote:

> >> 1) An ICE agent that uses FQDN needs to provide one candidate per
> address family, and indicate the addrtype for each of those candidates.
> >> 2) Some text regarding backward compatibility. Do we assume some
> default behavior by existing implementations, or do we require an ICE
> option?
> >
> > I do not think we need an ICE option. I think presence of addrtype can
> be sufficient.
>
> But if the peer ICE agent does not support it, and the FQDN resolves into
> both IPv4 and IPv6, we don't know what version it will use.
>

I do not think adding ICE option will help. Unsupported ICE options are
simply ignored so we end up not knowing what address remote agent is using.
Unfortunately FQDN was not well defined in RFC 5245. "Fortunately" I have
not seen anybody actually implementing FQDN In the worst case ICE
nomination fails.  This is no different then having no connectivity for
this specific candidate. Also, if FQDN handling is part of ice-sip-sdp,
then agent should already include ice2 option.

> This being said we need to decide two things:
> >
> > 1. Does FQDN resolution belongs to ICE processing? In this case
> candidate list includes FQDN with address type and ICE processing describes
> how FQDN are resolved and converted to addresses.
> > Or, alternatively, does FQDN resolution belongs to ICE signaling? In
> this case candidate list includes resolved address and ICE agent deals with
> addresses only.
>
> That would not work with mDNS, right?
>
> > 2. Do we specify how to deal with FQDN in ice-sip-sdp or do we specify
> in ice-sip-sdp that FQDN must be ignored and their handling is defined in
> some other draft?
>
> Perhaps the best thing would simply to produce a separate draft, to get
> some text. We can then decide whether to merge it into ice-sip-sdp.
>

I can probably describe this in ice-sip-sdp in about 3 paragraphs. The
background and other text for a new draft will make is much bigger effort.
How about I put together a pull request for ice-sip-sdp and then we can
decide if this requires a new draft?

Regards,
______________
Roman Shpount