IETF Logo Mail Archive

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

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 12 April 2019 09:32 UTC

Return-Path: <christer.holmberg@ericsson.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 15C041201DD for <mmusic@ietfa.amsl.com>; Fri, 12 Apr 2019 02:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 jj_WBzbcDm68 for <mmusic@ietfa.amsl.com>; Fri, 12 Apr 2019 02:32:50 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80059.outbound.protection.outlook.com [40.107.8.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C4712018D for <mmusic@ietf.org>; Fri, 12 Apr 2019 02:32:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; 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 HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4249.eurprd07.prod.outlook.com (20.176.166.146) 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 HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1792.007; Fri, 12 Apr 2019 09:32:46 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>
CC: Suhas Nandakumar <suhasietf@gmail.com>, mmusic WG <mmusic@ietf.org>, Flemming Andreasen <fandreas@cisco.com>
Thread-Topic: [MMUSIC] FQDN support in ice-sip-sdp
Thread-Index: AQHU6jzz/50YAJx2kEqY4siuQ2NZYqY0606AgADVT4CAAEAVAP//1AeAgADQ14CAAETnAIAAnHWAgAD8QQA=
Date: Fri, 12 Apr 2019 09:32:46 +0000
Message-ID: <ADB632EC-B32F-4932-89AF-69A74B5D89D5@ericsson.com>
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>
In-Reply-To: <CAD5OKxuxKGbF8e6E9nqE1YU8amr+tsxggRb=BCCu7O6sAipz5A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com;
x-originating-ip: [89.166.49.243]
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: <HE1PR07MB4249124A80E674F7427FFA4E93280@HE1PR07MB4249.eurprd07.prod.outlook.com>
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; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com 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: <3EEBAD0B140A744CB10AB31014C12DF1@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
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: <https://mailarchive.ietf.org/arch/msg/mmusic/oH6IR4Gz_n-rsfqMcbV7GrCo12k>
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: Fri, 12 Apr 2019 09:32:53 -0000

Hi,

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

Regards,

Christer

v2.23.0 | Report a Bug | By Email