Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 27 February 2014 01:12 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B361A030E for <rtcweb@ietfa.amsl.com>; Wed, 26 Feb 2014 17:12:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 7uStafjX7roE for <rtcweb@ietfa.amsl.com>; Wed, 26 Feb 2014 17:12:16 -0800 (PST)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 574321A020A for <rtcweb@ietf.org>; Wed, 26 Feb 2014 17:12:16 -0800 (PST)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta08.westchester.pa.mail.comcast.net with comcast id XC1F1n00B0QuhwU58DCECE; Thu, 27 Feb 2014 01:12:14 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id XDCE1n0033ZTu2S3NDCEPy; Thu, 27 Feb 2014 01:12:14 +0000
Message-ID: <530E90ED.7000708@alum.mit.edu>
Date: Wed, 26 Feb 2014 20:12:13 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <CAJuyhsz4ZG_ReNEqmu+fTcSDfXxCnKWaVBhYvjf4XsWxSXB1mQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <CAJuyhsxz4X2aDNx2Y1Y2Gi9G0D12Ort95QFD=cQ6s-zM5GK9Uw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <530D1C00.7080701@jesup.org> <530E42B1.4030500@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1BCD34@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1BCD34@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393463534; bh=ItQry7cgucVT2p1J6PcjTQvlPtJeOvz25QZONMpP28s=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EZBcdqXvawx3SMjVirnSZZI5awATmxmdtz9pWn+d3abf/kZYWtTndLTUDkQaaYQAD LK3rbox3nO2nO5shw8pFwUfnBhf01oPkgEiP97Ou8D/+mF0jp+OthUvY8C4OyI2UbA Q3IBYHS9dIL+I+BJovYq7RuHP74WZtBSxneVeeeL/nHEWWY1otpR8qSpYmVkTPNTDm UoPVrfSfGDmsU3jK8nmJvu09ni0zxyFnOU+4eXe1aSrv6m5w7bQ7FNmmSQPJHNvd11 doebu2MYus3v4CKRFgcJdIDqQy6Whx1pLzdYXn45fTzabQWrYjp6qTOTx1vAUs1WaD Yg1bbkX08Wg8Q==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zmYJC3bPg9oIgLgqZGEtoIb_jw8
Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2014 01:12:18 -0000

On 2/26/14 3:02 PM, Christer Holmberg wrote:
> Hi,
>
> Let's also keep in mind that there has been suggestions to negotiate the channels using SDP, but in addition also use DCP (I assume that is what your DCEP abbreviation stands for :) to explicitly open the negotiated channels.

DCEP is the *new* acronym, from the most recent version.

> But, again, as long as JavaScript can access the information (stream id value etc), in order to add it to the SDP sent on the wire, and as long as the usage of DCP is optional (it was earlier indicated that it IS optional) I don't think there should be any impacts on WebRTC.
>
> Regards,
>
> Christer
>
> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: 26 February 2014 21:38
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00
>
> Randell,
>
> I agree that most of this discussion belongs elsewhere.
> But there are a few bits that probably do belong here.
>
> CLUE needs *something* that provides an e2e reliable channel. It could be a lot of things, e.g. TCP or TLS. We decided to go with the SCTP-based data channel that RTCWEB is defining so that we had the potential for a Webrtc endpoint to participate in CLUE without a gateway on the clue channel.
>
> That means we will also be using the same stack between non-webrtc clue endpoints that are using SIP for signaling.
>
> We are still undecided on whether to use DCEP or SDP O/A to negotiate the channel we use. If we use DCEP it will be straightforward for a webrtc endpoint. But that is a little unnatural for the sip endpoints.
> For them, the SDP O/A approach would be more natural.
>
> It doesn't matter much if the *only* channel being used is the clue channel. It will start to matter if there is a desire to use other channels for features that can coexist with clue. E.g. BFCP. (But now we see a proposal to put BFCP over websocket, so maybe it won't ever be an issue for us.)
>
> The important thing is that if clue decides to use SDP O/A for this, (the ejzak draft) then we must be confident that it will be feasible for a webrtc endpoint, via javascript, to participate in this negotiation and use it to set up the clue data channel. That is the part that belongs in rtcweb.
>
> 	Thanks,
> 	Paul
>
> On 2/25/14 5:41 PM, Randell Jesup wrote:
>> On 2/24/2014 10:21 AM, Christer Holmberg wrote:
>>>
>>> I still don't think the information belong to SDP - they define
>>> protocol characteristics. The protocol specification should define
>>> re-transmission timers etc.
>>>
>>> Anyway, we can argue about it later. At this moment I think the focus
>>> should be on whether to move forward with the mechanism to begin
>>> with, and the main feature of the mechanism - which is about
>>> negotiating usage of channels :)
>>
>> This (whether to move forward) is my concern (in addition to Mary's
>> about this being the wrong group - MMUSIC is where the SDP should be
>> and has been).
>>
>> The apparent justification for this document is "This document defines
>> SDP-based out-of-band negotiation procedures to establish WebRTC data
>> channels for transport of well-defined sub- protocols." This seems a
>> pretty sparse justification.
>>
>> We very purposely avoided using SDP for channel setup (after MUCH
>> discussion at Boston and elsewhere).  That isn't to say that for
>> non-webrtc usage, one could define an SDP used to externally-negotiate
>> the settings for DataChannels, which this appears to be.  But I think
>> there should a clearer statement as to "why" we should invest the time
>> to standardize this now, not just that we "can".  For example, if CLUE
>> really wants to use this instead of in-band opens, then maybe there's
>> a reason to do so - but don't expect webrtc endpoints to implement this.
>> And if so, it should be done in CLUE by request to MMUSIC.
>>
>> At this point I don't see need to move forward with this, and
>> certainly not here.  And I certainly don't want this to delay
>> finalizing the stuff needed in MMUSIC for WebRTC use of DataChannels
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>