Re: [MMUSIC] SDPNEG: How to disable DCEP

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 29 April 2019 12:54 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 52A1F120343 for <mmusic@ietfa.amsl.com>; Mon, 29 Apr 2019 05:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: 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 tdmqGYh0XVh5 for <mmusic@ietfa.amsl.com>; Mon, 29 Apr 2019 05:54:08 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70057.outbound.protection.outlook.com [40.107.7.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF4712034C for <mmusic@ietf.org>; Mon, 29 Apr 2019 05:54:07 -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=eZ98UvZRoDjyFzfJN0O86ZWMzq++JhBRz7u1K2Z1nfo=; b=a7vgPR4bVJaYSHK2DgmV0CkMEWnimH9x2z+/0Vgxj/jeR8greqnXOOV2nR1J09d7h7wGqkBGl+h4vc9Kp+JgGCW3xwmhQN9VzOeM9ulGCwYKo9GyvNpP+QoNriR2OgvBlTbgpOV392dSH1Hkz4GluFK2zi0oJMkhMvTcHXVKBTk=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3258.eurprd07.prod.outlook.com (10.170.246.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.4; Mon, 29 Apr 2019 12:54:04 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321%6]) with mapi id 15.20.1856.008; Mon, 29 Apr 2019 12:54:04 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "Roni Even (A)" <roni.even@huawei.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] SDPNEG: How to disable DCEP
Thread-Index: AQHU+njrOtTA5N+Kv0Ox965sWihq+KZL5CwAgAKAjYCAACw0AIACj2qAgACQLACAAA/sgIABXhC/
Date: Mon, 29 Apr 2019 12:54:03 +0000
Message-ID: <HE1PR07MB316176E6552193AB4B39DC6093390@HE1PR07MB3161.eurprd07.prod.outlook.com>
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>
In-Reply-To: <32fb1138-4bc1-6315-0c2f-d660ecfafdcd@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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: 5935642b-7c18-45f8-a72b-08d6cca1c241
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3258;
x-ms-traffictypediagnostic: HE1PR07MB3258:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <HE1PR07MB3258DAB3E1AC07EB42C0BB0793390@HE1PR07MB3258.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0022134A87
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(39860400002)(136003)(396003)(51444003)(13464003)(199004)(189003)(44832011)(478600001)(68736007)(66066001)(966005)(5660300002)(102836004)(14454004)(81156014)(76176011)(71200400001)(71190400001)(2906002)(7696005)(99286004)(81166006)(316002)(97736004)(25786009)(1015004)(74316002)(6246003)(6606003)(33656002)(55016002)(8676002)(52536014)(26005)(8936002)(186003)(7736002)(110136005)(9686003)(93886005)(6436002)(486006)(6306002)(53936002)(3846002)(236005)(86362001)(6116002)(446003)(54896002)(66556008)(229853002)(256004)(476003)(14444005)(2501003)(66946007)(73956011)(2171002)(11346002)(606006)(6506007)(19627405001)(66446008)(64756008)(76116006)(53546011)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3258; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: rc1cQoFC9des7SAE8GR+B5xX4o8+perTDKfATfo3UKhrFQz+D2VcK8HeORfHLtdAcEIWVPa5RanchKt9F5Uqp2gBLOLNwTPkQEuskhRuDpMGN1//TwYJqgmjq1D2XVKjmX6pwz5pDUGC8nM4Y/l/87rLDKFXEumeB/3zQWxn11i4GVDYROdEhaEDvef93JQPA/kc39W8spr0Wh1AX28cTpE82Sa2WY0BFv7I+RQk0YnBussfzQRi9+bo8DHs4rjoycvZJpxAXD5B8Mw9Y2JLjBNjSAsl/d9Ix6vXvOVpYn/pSnV8RDJt9Jyc1FpkrXTshslV0mgKo7M7+2MWywQe6bVgWzFvsKkPtzS+hQwr1iehdBnnffSDX3FEkeeFw3Uh0Jgrv6GmF7yFGvUyKJmW3EJ4YYzDl5SUhOamsELwS+w=
Content-Type: multipart/alternative; boundary="_000_HE1PR07MB316176E6552193AB4B39DC6093390HE1PR07MB3161eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5935642b-7c18-45f8-a72b-08d6cca1c241
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2019 12:54:03.8918 (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: HE1PR07MB3258
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/DO_xeiUoxO3b1_8NfaIyv4-oJmc>
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 12:54:12 -0000

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 :)

Regards,

Christer




On 4/28/19 7:57 AM, Christer Holmberg wrote:
> Hi,
>
>> I think that sections 6.3 and 6.4 that discuss offer/answer say that dcmap is the indication of ruing non dcep.
>
> Section 6.3 and 6.4 describe how to use dcmap.
>
> I think it would be useful to e.g., have an Applicability section in the beginning of the document, that explicitly indicates that the procedures in the document apply when a data channel is negotiated using the dcmap attribute, and that DCEP is then not used.
>
> But, what if an offerer wants to negotiate a data channel, before deciding what exactly it is going to be used for, but still wants to indicate usage of SDPNEG. Including an empty dcmap attribute?
>
>>     The example in section 7 say that if dcmap is rejected dcep may be negotiated.
>>     Maybe this line form section 7 should be in section 6.4?
>
> Normative text should definitely not be in Section 7.
>
> However, if the answerer does not want to use SDPNEG, I think it's up to the offerer to decide whether to continue the session establishment, or fallback to DCEP.
>
> Regards,
>
> Christer
>
>
>
>
>      -----Original Message-----
>      From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
>      Sent: Friday, April 26, 2019 6:16 PM
>      To: Christer Holmberg; mmusic@ietf.org
>      Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP
>
>      On 4/26/19 5:37 AM, Christer Holmberg wrote:
>      > Hi Paul,
>      >
>      > So, what is your suggestion? __
>
>      It looks to me like the 2nd paragraph of Appendix A is the right place for this:
>
>          A WebRTC application creates a data channel by providing a number of
>          setup parameters (subprotocol, label, maximal number of
>          retransmissions, maximal retransmission time, order of delivery,
>          priority).  The application also specifies if it wants to make use of
>          the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if
>          the application intends to negotiate data channels using the SDP
>          offer/answer protocol.
>
>      I'm inclined to tweak the above as follows:
>
>          ...
>          the application intends to negotiate data channels using the SDP
>          offer/answer protocol, or both.
>
>      And then, the note at the end of the section can be augmented:
>
>          Note: The above SDP media description does not contain any channel-
>          specific information. If data channels are to be negotiated using
>          SDP, then the above will be supplemented as specified in Sections
>          6.3 and 6.4.
>
>      But I'm not sure about "The application also specifies...". Is this referring to something specific in the webrtc API? If so, does it permit both? The presence of dcmap in the SDP will indicate the intent to use SDP negotiation, but must this first be enabled in the API?
>
>        Thanks,
>        Paul
>
>      > Regards,
>      >
>      > Christer
>      >
>      > On 25/04/2019, 1.25, "mmusic on behalf of Paul Kyzivat" <mmusic-bounces@ietf.org on behalf of pkyzivat@alum.mit.edu> wrote:
>      >
>      >      The distribution of specs across multiple documents makes it really
>      >      fuzzy what is normative for what.
>      >
>      >      Perhaps something should be said about the validity of using a
>      >      webrtc-datachannel media stream for establishing data channels via SDP
>      >      with dcmap and/or DCEP. I don't think this is said anywhere else.
>
>      _______________________________________________
>      mmusic mailing list
>      mmusic@ietf.org
>      https://www.ietf.org/mailman/listinfo/mmusic
>
>