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

Christer Holmberg <> Thu, 18 April 2019 05:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F2C4120355 for <>; Wed, 17 Apr 2019 22:14:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id syfBwZV45n6n for <>; Wed, 17 Apr 2019 22:14:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D042B120304 for <>; Wed, 17 Apr 2019 22:14:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3zJZfXWdq9e0wpvqpHPCyBo1aeVPcG1RLeM8owTyO6M=; b=MN0IYJH0w6dJF9bjweLRQVeyac6AXGg4YyoyBjemFyKj45maTx5h6SsfGKZQ7YFyTs/AhV5X90amejVF/XZBu6eIJnOB6AN8XEarOh40YZZLFa2KXmZMZ+yRywahWxAenT7c6zNXrEIBvlWThDlzvPdyLX/DXUrrO9vkz8q5WEs=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.3; Thu, 18 Apr 2019 05:14:14 +0000
Received: from ([fe80::747a:900a:3053:2184]) by ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1813.013; Thu, 18 Apr 2019 05:14:14 +0000
From: Christer Holmberg <>
To: Roman Shpount <>
CC: Flemming Andreasen <>, mmusic WG <>
Thread-Topic: [MMUSIC] FQDN support in ice-sip-sdp
Date: Thu, 18 Apr 2019 05:14:14 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:14bb:42:6704:49bf:cc7a:912:ee76]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8b6d2d31-a3f0-4c4e-0a8a-08d6c3bcb349
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB3451;
x-ms-traffictypediagnostic: HE1PR07MB3451:
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 0011612A55
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(346002)(366004)(136003)(376002)(189003)(199004)(74316002)(53936002)(7736002)(46003)(25786009)(11346002)(446003)(6916009)(6506007)(4326008)(53546011)(236005)(99286004)(6436002)(478600001)(81156014)(476003)(8936002)(97736004)(6246003)(14454004)(9686003)(68736007)(7696005)(8676002)(55016002)(486006)(81166006)(54896002)(52536014)(256004)(316002)(54906003)(44832011)(2906002)(102836004)(6116002)(76176011)(14444005)(186003)(33656002)(71200400001)(86362001)(93886005)(229853002)(5660300002)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3451;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: U0mxF7ZEH2Rshl40fSKQEGsTvm/PmdShX4gu8d/u0Wlswy8lnhinKVPwav8nEzEa4K5VOT5mld6AW+iBJ/Nqxn4xM7yykCgAK/SjAKNIh/iN5VsYlJcCrJz/7eb746bEnFa/qqvAk9jhg4rG5V9gXfm+XUV5RUswBQvbXdw6Mynq5iekK/m4avIqNsl/9wpFfc1TAhW8gGcIHdjW9imRGcyVWFYCNDZvYZDvnDtljdDwgpdkmWz4ma6jZW76yr5brR52kzQsR4uiA7LWLm8roroYeBI6c3/nEe32IAZc+xPP5hKOt44p9W/gjqLS3FvI7++dAA0htiqy2tgHY+UY+o/qS6Foa/4h5BIMmmlheaspWKwv6/+m57Jk6lklcLlF1yeitg7u97hbmxJBvQhQEicfwHkBRxnMC4x50isGv7Q=
Content-Type: multipart/alternative; boundary="_000_HE1PR07MB316110FB4568C8B72760F21293260HE1PR07MB3161eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8b6d2d31-a3f0-4c4e-0a8a-08d6c3bcb349
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 05:14:14.7609 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3451
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, 18 Apr 2019 05:14:22 -0000

Hi Roman,

I think a pull request would be good. Then we have text to look at - no matter where it will end up.

I also suggest to try to keep the generic text separated from the SDP specifics, so it can easily be moved elsewhere if needed.

Regarding agents that don’t understand the addrtype parameter, perhaps we could define a default IP version of an FDQN returns multiple (unless such default already exists somewhere)? It will of course not help with 5245 implementations, but at least new implementations will have predicatable functionality.


From: Roman Shpount <>
Sent: Wednesday, April 17, 2019 3:17:54 AM
To: Christer Holmberg
Cc: Flemming Andreasen; mmusic WG
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp


On Mon, Apr 15, 2019 at 4:13 AM Christer Holmberg <<>> 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?

Roman Shpount