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

Christer Holmberg <> Fri, 12 April 2019 09:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15C041201DD for <>; Fri, 12 Apr 2019 02:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 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, 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 jj_WBzbcDm68 for <>; Fri, 12 Apr 2019 02:32:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 60C4712018D for <>; Fri, 12 Apr 2019 02:32:50 -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=iD8y/DlriOpBgmqDAjUu0k7DJhIV1dlhdtdCNMn/7QQ=; b=dwT2AvQGeIvPks/3w3Wt9G7UaGmBty6snGlVoM8sr1U2KUTdSynC8lewvCC0VJIGLXcIxCfPiLCcFVB772AcIkgCqeyz2HHi2dDnVVEk04u66dwXeRLLCDhJMz5Snqb+czMRzDp+rm04BWKYpkHKCqN+eThLqRntfNwc+7k5eNA=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.9; Fri, 12 Apr 2019 09:32:46 +0000
Received: from ([fe80::a832:85f:a8bb:73b9]) by ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1792.007; Fri, 12 Apr 2019 09:32:46 +0000
From: Christer Holmberg <>
To: Roman Shpount <>
CC: Suhas Nandakumar <>, mmusic WG <>, Flemming Andreasen <>
Thread-Topic: [MMUSIC] FQDN support in ice-sip-sdp
Date: Fri, 12 Apr 2019 09:32:46 +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: cb4af067-1377-470d-869d-08d6bf29d28b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4249;
x-ms-traffictypediagnostic: HE1PR07MB4249:
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 0005B05917
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(366004)(39860400002)(396003)(189003)(199004)(44832011)(36756003)(8936002)(81156014)(476003)(2616005)(486006)(478600001)(66066001)(82746002)(81166006)(4326008)(5660300002)(14454004)(93886005)(33656002)(76176011)(8676002)(446003)(53936002)(11346002)(97736004)(6246003)(6436002)(68736007)(186003)(256004)(26005)(6512007)(102836004)(6506007)(105586002)(86362001)(71200400001)(316002)(25786009)(71190400001)(106356001)(2906002)(58126008)(54906003)(6486002)(6116002)(7736002)(305945005)(83716004)(229853002)(3846002)(99286004)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4249;; 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: aifgBH4AR51Qu5oNbT1Qrmb1i9P7fZGTQmMWM71Si9YNx3WVllkL5e50m66Wk8PZz/+1AAcLYCsJEPchzWeZUR3dXbdxoMfEXJoWnu6djIYJv5Gr4YajjpEg377/aXxNBb7ImyLs/13lGpB3SwK6C+CTLhvpVDEzEYag9Ptp+r+P29wqelRVfwICT6ujKaWy/FyaxbWwvbVHg01utRWyVSbu5C9yBCnssDUPH+CVBHqXgVqbe2BzzmTg/P1xJCmzQMvSZJTqmC2FhyZymo8pt6+CdMMPSfey5ge9yWvQEMuQ618qyVJgVcdA3lRrLQ+8UHMMRjx6ausquY1zUeqWorZVxJ6VsA0aWIhs9TcxQy3EIajQ3QLoKlHDiL5kPUc0+30puHKIa/an+ufTCKDkkyikKAcrHboliE6YFhqnKMQ=
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: cb4af067-1377-470d-869d-08d6bf29d28b
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 09:32:46.5436 (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: HE1PR07MB4249
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, 12 Apr 2019 09:32:53 -0000


>> 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.

As far as the technical solution is concerned (using separate a=candidiate lines for each IP version family etc), I think it looks good.

As far as documenting is concerned, I think the SDP specifics (separate a= lines etc) could be defined in ice-sip-sdp - but I would not object to having a separate draft.

My point is that I don't see FQDN support as SDP-specific, so I would like to have generic ICE FQDN text documented somehwhere, which the SDP-specific procedures then reference.