Re: [MMUSIC] WG adoption of other WebRTC data channel usage drafts?; Re: New Version Notification for draft-ietf-mmusic-msrp-usage-data-channel-02.txt

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 06 October 2015 17:29 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D2B1AD0A3 for <mmusic@ietfa.amsl.com>; Tue, 6 Oct 2015 10:29:46 -0700 (PDT)
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 AUUz1LBjVI12 for <mmusic@ietfa.amsl.com>; Tue, 6 Oct 2015 10:29:45 -0700 (PDT)
Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 368971AD094 for <mmusic@ietf.org>; Tue, 6 Oct 2015 10:29:45 -0700 (PDT)
Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-08v.sys.comcast.net with comcast id RtVk1r00226dK1R01tVkQP; Tue, 06 Oct 2015 17:29:44 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-01v.sys.comcast.net with comcast id RtVk1r0043Ge9ey01tVkeZ; Tue, 06 Oct 2015 17:29:44 +0000
To: "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <786615F3A85DF44AA2A76164A71FE1ACDF796695@FR711WXCHMBA01.zeu.alcatel-lucent.com> <5613D9D6.3060009@alum.mit.edu> <786615F3A85DF44AA2A76164A71FE1ACDF796CED@FR711WXCHMBA01.zeu.alcatel-lucent.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56140506.7010006@alum.mit.edu>
Date: Tue, 6 Oct 2015 13:29:42 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <786615F3A85DF44AA2A76164A71FE1ACDF796CED@FR711WXCHMBA01.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1444152584; bh=krdA7sR617RAflaSwjYLa3P0SdaWhHasHgIH8U5/EpQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=QgXDrVFZZm74xCFH1Bcss6dlB9k4hZoMHHDdSOxMkfKWuDkKJLm0taGRrkI7iVsYM vDMQfn6bj5EAgt/Eyt7sAUNcTOkNq7jDdAV+V059qzDmGKRDRp1B8N30hcAez871La z7ffgoQ+qEShkp7XvRARcUdyv0CdArQzSHKCnxShTEDkE4jkbkkTV0gP0iEBD9gq5f T5HRWqmNwVxuISKOEtQ9Bcf2me6ZWe1S5zIK9dL2+rhs+vAyBeNQEEVnNV9PaIgg1E rtqJR0BhKe0aSEp3ArGBrDj0InKYPwPjE7+5ByOKGd/zK+iIJJV0mLwcvdoABhwNoI Df/Q34OTMJ16Q==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/AkguU-jEisM1u9zl1Espgaj5v4Q>
Subject: Re: [MMUSIC] WG adoption of other WebRTC data channel usage drafts?; Re: New Version Notification for draft-ietf-mmusic-msrp-usage-data-channel-02.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 06 Oct 2015 17:29:47 -0000

On 10/6/15 11:31 AM, Schwarz, Albrecht (Albrecht) wrote:
> My understanding:
> The websocket based transport would lead to separate, self contained TCP connections, hence in opposition to the goal in minimizing the number of L4 connections for a WebRTC call.
>
> There might be many, but not "infinite" IP application protocols as candidates for a WebRTC data service, given the "RTC character" and conversational service category.

This isn't just about webrtc.

I wanted to see the data channel spec made less webrtc-centric. It is 
certainly suitable for use in cases when webrtc isn't involved. (The 
data channel sdp draft is part of making that so.)

For instance CLUE is using a data channel. Many uses of clue won't 
involve webrtc at all.

An advantage of defining more protocols over data channels is that then 
an application can use several of them over a single connection.

But I find it interesting to see T140 defined this way, since T140 over 
RTP could be bundled with other media streams. That is another reason to 
try to rationalize the criteria for doing this.

	Thanks,
	Paul

> That set of IP application protocols might be divided in two classes: a) generic and b) application-specific protocols from SDP perspective. Preferably, the majority would belong to (a). Unfortunately, the first three are of type (b).
>
> Paul, don't got a general view / answer on your question.
>
> Regards,
> Albrecht
>
>
> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: Dienstag, 6. Oktober 2015 16:25
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] WG adoption of other WebRTC data channel usage drafts?; Re: New Version Notification for draft-ietf-mmusic-msrp-usage-data-channel-02.txt
>
> This motivates me to ask a question:
>
> How do we decide that an existing protocol should be extended to work using a data channel as its transport?
>
> Do we just do it for every protocol we can think of that could work that way?
>
> Note that many protocols that could run over a data channel could also run over a websocket transport. Should we define all of those too?
>
> (One "answer" to why we should define things over data channel is that this is a path to make them usable from webrtc clients. But such clients can also use websockets.)
>
> 	Thanks,
> 	Paul
>
> On 10/6/15 3:47 AM, Schwarz, Albrecht (Albrecht) wrote:
>> Dear All,
>>
>> like too remind that there are three first WebRTC data channel
>> applications,
>> 1) MSRP based instant messaging,
>> 2) T.140 based text conversation and
>> 3) BFCP based floor control within a WebRTC conference service.
>>
>> draft-ietf-mmusic-msrp-usage-data-channel was/is the precedent for getting a common understanding about application protocol specific SDP usage (on top of the generic control of a DC).
>> The discussion and protocol design are fairly mature in the meanwhile, hence it is time to start the work on the two other applications.
>> We've prepared initial drafts, derived from the "MSRP draft", see:
>>
>> T.140 Text Conversation over Data Channels
>> draft-schwarz-mmusic-t140-usage-data-channel-02.txt
>>
>> BFCP floor control signalling over Data Channels
>> draft-schwarz-mmusic-bfcp-usage-data-channel-01.txt
>>
>> We'd like to request MMUSIC for adoption of these drafts.
>>
>> Regards,
>> Albrecht
>>
>>
>>
>> Re: [MMUSIC] New Version Notification for
>> draft-ietf-mmusic-msrp-usage-data-channel-02.txt
>>
>> Juergen Stoetzer-Bradler <Juergen.Stoetzer-Bradler@alcatel-lucent.com>
>> Wed, 09 September 2015 14:45 UTCShow header
>>
>> Hello,
>>
>> Version 02 of draft-ietf-mmusic-msrp-usage-data-channel addresses
>> Christian's comments to version 01,
>> http://www.ietf.org/mail-archive/web/mmusic/current/msg14537.html,
>> except for the "setup" attribute related one.
>>
>> We'll come back regarding the SDP setup attribute, which can be part
>> of an MSRP over data channel related SDP media description as media
>> level "a=setup" attribute and/or as MSRP sub-protocol specific attribute "a=dcsa:x setup".
>>
>> Thanks,
>> Juergen
>>
>> On 09.09.2015 16:33, internet-drafts@ietf.org wrote:
>>> A new version of I-D,
>>> draft-ietf-mmusic-msrp-usage-data-channel-02.txt
>>> has been successfully submitted by Juergen Stoetzer-Bradler and
>>> posted to the IETF repository.
>>>
>>> Name:		draft-ietf-mmusic-msrp-usage-data-channel
>>> Revision:	02
>>> Title:		MSRP over Data Channels
>>> Document date:	2015-09-09
>>> Group:		mmusic
>>> Pages:		15
>>> URL:            https://www.ietf.org/internet-drafts/draft-ietf-mmusic-msrp-usage-data-channel-02.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-ietf-mmusic-msrp-usage-data-channel/
>>> Htmlized:       https://tools.ietf.org/html/draft-ietf-mmusic-msrp-usage-data-channel-02
>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msrp-usage-data-channel-02
>>>
>>> Abstract:
>>>       This document specifies how the Message Session Relay Protocol (MSRP)
>>>       can be instantiated as a data channel sub-protocol, using the SDP
>>>       offer/answer exchange-based generic data channel negotiation
>>>       framework.  Two network configurations are documented: a WebRTC end-
>>>       to-end configuration (connecting two MSRP over data channel
>>>       endpoints), and a gateway configuration (connecting an MSRP over data
>>>       channel endpoint with an MSRP over TCP endpoint).
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> The IETF Secretariat
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>