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

Christer Holmberg <> Fri, 26 April 2019 07:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0AE8712008C for <>; Fri, 26 Apr 2019 00:02:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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 xHThT53WuyGk for <>; Fri, 26 Apr 2019 00:02:34 -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 611E8120182 for <>; Fri, 26 Apr 2019 00:02:33 -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=xbSP2fe8aOdcXlHkix75G3l0zKRYPtn4Vl7NyqH6T5k=; b=Byuy1QoyeeYlNMdOYDk2wHnzhhpcWskDA03I+ypJECSqVYrvGXJA0GQj480cFRySF5WTZRWLllxxujoujU8EmDKfsdzsseFrVz1W/0GXbCzTbWW6gewF+Ook6uxAzE0tB7qUMIM+mQqLDbU3rp0LOcm6GQGKt/qqwyL9KVyTpXo=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.5; Fri, 26 Apr 2019 07:02:30 +0000
Received: from ([fe80::d925:d8b5:d1df:4706]) by ([fe80::d925:d8b5:d1df:4706%4]) with mapi id 15.20.1856.004; Fri, 26 Apr 2019 07:02:30 +0000
From: Christer Holmberg <>
To: Roman Shpount <>
CC: Suhas Nandakumar <>, Flemming Andreasen <>, mmusic WG <>
Thread-Topic: [MMUSIC] FQDN support in ice-sip-sdp
Date: Fri, 26 Apr 2019 07:02:30 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f9ae2e52-5cfc-4378-a75c-08d6ca152643
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB5536;
x-ms-traffictypediagnostic: VI1PR07MB5536:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 001968DD50
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(396003)(39860400002)(346002)(366004)(189003)(199004)(76116006)(6116002)(71200400001)(76176011)(97736004)(91956017)(6436002)(14454004)(7736002)(11346002)(446003)(5660300002)(36756003)(2616005)(82746002)(73956011)(966005)(2906002)(4326008)(478600001)(66946007)(66446008)(66476007)(99286004)(58126008)(790700001)(6916009)(54906003)(71190400001)(64756008)(66556008)(5070765005)(316002)(486006)(81166006)(14444005)(68736007)(6506007)(81156014)(8936002)(8676002)(86362001)(3846002)(102836004)(53546011)(25786009)(517774005)(26005)(44832011)(66066001)(6512007)(476003)(6306002)(54896002)(606006)(236005)(186003)(440504004)(53936002)(229853002)(93886005)(33656002)(6246003)(83716004)(256004)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5536;; 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: +/TJIQwQTr4IQu31ktEHbLq4oouIY62iUbSHlCWoLfgIRKhUepogYoU2iicCZwcyYufCnx9KliTXiYrvqfC1joMsIJwXYjq+hLbccK1SUzNX2kLerGHQ1VMqPvhpcPOcfcvNC7/6m+Oih0aYtH3IXmW31cmK98c5tf1xbOZzupK7H31WuZjpxkiKhwRFG6gDw98QVTfAktkkykO7AZr69ZW48VKKUR5Aq4NNxsuq6xvV8VeR3cttfKDQdE7rmwH7PFbLcB2R8QAWAn4YJLU+inheELxnWkwGIJ1WUBweXDqBiWVmIx7MZ7YFdEbI3AmX/qXaLX1RUzFHniJx/7yXCAx2FbmcMCq/JRZVJmqgzpMg+OkPe5FydvzS6+4fMmmkuBADnl+gy+mP4wbNWrX1ZJpBbAuGBc+4qXAq09odH0A=
Content-Type: multipart/alternative; boundary="_000_52CE9A69B70941CD9BE8A59EE44D55A7ericssoncom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f9ae2e52-5cfc-4378-a75c-08d6ca152643
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2019 07:02:30.3446 (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: VI1PR07MB5536
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: Fri, 26 Apr 2019 07:02:38 -0000


>Simon Perreault advised to remove FQDN support from the definition of connection-address. We are now trying to figure out a way to add FQDN support back.
Perhaps the text should then say something like “for advising on usage of FQDN in the candidate-address”, or something like that. “Address selection” sounds confusing.



Roman Shpount

On Mon, Apr 22, 2019 at 4:34 AM Christer Holmberg <<>> wrote:

The draft contains the following text in the Acknowledgements section:

   “Thanks to Thomas Stach for text help, Roman Shpount for suggesting
   RTCP candidate handling and Simon Perreault for advising on IPV6
   address selection when candidate-address includes FQDN.”

I am not really sure what “advising on IPv6 address selection” means, and I can’t find any text in the draft that would be related to this.



From: Suhas Nandakumar <<>>
Date: Sunday, 21 April 2019 at 23.24
To: Christer Holmberg <<>>
Cc: Flemming Andreasen <<>>, Roman Shpount <<>>, "<>" <<>>
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp

Hi Roman

   Do you have an ETA on the pull request


On Wed, Apr 17, 2019 at 10:14 PM Christer Holmberg <<>> wrote:
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

mmusic mailing list<>