Re: [MMUSIC] SDPNEG: How to disable DCEP

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 29 April 2019 13:34 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 180B1120315 for <mmusic@ietfa.amsl.com>; Mon, 29 Apr 2019 06:34:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 KatDkmVBFhHa for <mmusic@ietfa.amsl.com>; Mon, 29 Apr 2019 06:34:20 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FC8A1200C7 for <mmusic@ietf.org>; Mon, 29 Apr 2019 06:34:19 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x3TDY7wM016346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Apr 2019 09:34:08 -0400
To: Christer Holmberg <christer.holmberg@ericsson.com>, "Roni Even (A)" <roni.even@huawei.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <8A9AAAC7-FB2D-4884-BAC6-268B98C7A0F0@ericsson.com> <eba7d468-a2a3-8c5f-c2b0-fa515fb2e55c@alum.mit.edu> <81169C37-95F2-418A-A221-CCC623392CD2@ericsson.com> <563cf2bd-474a-8fef-ceaf-e2c72ebc6dc4@alum.mit.edu> <6E58094ECC8D8344914996DAD28F1CCD18CDE434@dggemm526-mbx.china.huawei.com> <A3797048-4BD3-46ED-8231-3C90F52C89BC@ericsson.com> <32fb1138-4bc1-6315-0c2f-d660ecfafdcd@alum.mit.edu> <HE1PR07MB316176E6552193AB4B39DC6093390@HE1PR07MB3161.eurprd07.prod.outlook.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <2a06aebe-262b-dbad-4bf8-66c9a5dabf86@alum.mit.edu>
Date: Mon, 29 Apr 2019 09:34:07 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <HE1PR07MB316176E6552193AB4B39DC6093390@HE1PR07MB3161.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/YlGYhTo5p9bg6XNmxHC9qztPoQk>
Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP
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: Mon, 29 Apr 2019 13:34:22 -0000

On 4/29/19 8:54 AM, Christer Holmberg wrote:
> Hi,
> 
> 
>>You seem to be suggesting that using dcmap is mutually exclusive with
>>using DCEP to negotiate channels. While I guess it would be possible to 
>>make such a rule I don't see why it is necessary, or a good thing. Why 
>>not allow them to be used together? (E.g., use SDP to establish the SCTP 
>>association and negotiate some initial channels, and later use DCEP to 
>>negotiate some additional channels.)
> 
> You are right - one can use both SDPNEG and DCEP for the same SCEP 
> association (read: same m- line).
> 
> But, if I establish the SCTP association - but do not negotiate some 
> initial channels using SDPNEG - the peer won't know that I support 
> SDPNEG, so I assume it will always try to use DCEP.
> 
> Having explicit support indicators, that are separate from the actual 
> protocol indicators, is always good in my opinion.
> 
> But, perhaps we should have thought about that earlier. Let's make 
> whatever clarifications are needed and ship the document :)

Yes, maybe this should have gotten more thinking up front, but that is 
water over the dam.

ISTM that for a particular use an application will likely be coded to 
negotiate a data channel via DCEP or SDPNEG, but not both. But at the 
same time it might be possible that different usages within the 
application *might* work differently in this regard. (E.g., the 
application might call a library that internally needs a data channel 
and negotiates it via DCEP.)

I don't think it is essential to know a priori which are supported. If 
lack of support is discovered via a failure to negotiate then so be it.

But I am interested to hear what others think.

	Thanks,
	Paul