Re: [MMUSIC] [dispatch] SDP negotiation of data channel sub-protocols

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 07 November 2013 19:03 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 8D75D21E8144 for <mmusic@ietfa.amsl.com>; Thu, 7 Nov 2013 11:03:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.137
X-Spam-Level:
X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_55=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUJXfYYHn6tU for <mmusic@ietfa.amsl.com>; Thu, 7 Nov 2013 11:03:33 -0800 (PST)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 77E0821E8140 for <mmusic@ietf.org>; Thu, 7 Nov 2013 11:02:34 -0800 (PST)
Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta15.westchester.pa.mail.comcast.net with comcast id mcV61m0060Fqzac5Fj2aaJ; Thu, 07 Nov 2013 19:02:34 +0000
Received: from dhcp-a6d1.meeting.ietf.org ([31.133.166.209]) by omta08.westchester.pa.mail.comcast.net with comcast id mj0R1m00k4XQ1zz3Uj0U2p; Thu, 07 Nov 2013 19:00:32 +0000
Message-ID: <527BE349.5080809@alum.mit.edu>
Date: Thu, 07 Nov 2013 11:00:25 -0800
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.1.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <03FBA798AC24E3498B74F47FD082A92F3D87235B@US70UWXCHMBA04.zam.alcatel-lucent.com> <2F68552E-F18B-4A54-BD52-732EEDB02B52@oracle.com>
In-Reply-To: <2F68552E-F18B-4A54-BD52-732EEDB02B52@oracle.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383850954; bh=eEGDMZIWkrAcKX1Rz1y3aS3POIONhGhI9VgTWhnYWjs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oeedM1HHXw2a5sWtCH4+fuuAIchaugUIVz7xQFzRIYGxxspbDuMK7kQ7x1wlVK6os Zc4ufBZH5B1TUPY12UivCuL2+bbwUEqAdqNafuGCjhNlYIy9xf4bw2wnnyJxWaGp/f gQdtgChzvS6FDWCg6RL26e5U63c5twJ1yr33M/1BpJZvJrbfNWjVrcPHrjHuZcLYIB 55v8v1//1wa/2biG6Zz8Kzuk6KzXP72DEH76lkPXqFXRtFwWodEh08tPel48lTJfX/ 9si4TXp3t4n7vaWO/P6P6FWKer+6kzUq2zkzHm3x98dN5nzYVikbT6Wq4qaPvZJu6O 0K1R19kdAPQXw==
Subject: Re: [MMUSIC] [dispatch] SDP negotiation of data channel sub-protocols
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 07 Nov 2013 19:03:38 -0000

Hadriel,

Did you see my reply to Richard?
In principle I agree with you, but in practice I don't think it is 
feasible to go that way.

The audio/video/application thing merely reflects a case where SDP got 
it wrong in the first place. Technically codecs are identified by a 
mime-type/subtype, but the type is put in the type field of the m-line, 
and the subtype is put either into the format field of the m-line or 
into an attribute.

When doing it over in a new context we can simply represent it as 
type/subtype.

	Thanks,
	Paul

On 11/7/13 10:14 AM, Hadriel Kaplan wrote:
>
> I had assumed the proposal was to make this draft-thing usable in SIP or other protocols, not just WebRTC.  True?  If not true, and this is only for WebRTC, then yeah do whatever and please ignore this email.
>
> Technically SCTP is a transport, not a media type.  By having multiple sctp-based application/media types in the same m-line, it's semantically equivalent to putting audio+video in the same m-line.  Even your example SDP in the draft shows this, since MSRP is a "message" media type while one of the others is a "application" one.
>
> To put this more concretely, pretend that we had standardized not only MSRP, BFCP, and T.38 fax to run over SCTP, but also video and audio too.  Maybe not real-time video, but rather TV-style streaming of video or whatever.  So now you'd have SDP with one m-line for "SCTP" with audio, video, message, and application types within it.
>
> I'm ok if the group consensus is to do it anyway, but my point at the mic was to make this more obvious to people - that by doing this, SDP semantics are not being consistent.  I realize that consistency no longer matters at the altar of WebRTC expediency, but just thought it should be pointed out... if for no other reason than to have this stored in the email archives.
>
> -hadriel
>
>
> On Nov 6, 2013, at 11:54 PM, "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com> wrote:
>
>> Please excuse this one-time cross-posting but I understand that this issue and the following drafts now move from dispatch to MMUSIC.  Please respond only on the MMUSIC list.
>>
>> draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt
>> draft-ejzak-dispatch-msrp-data-channel-00.txt
>>
>> At the mike, Hadriel Kaplan proposed an alternative approach to the one I presented in dispatch yesterday (and in the first draft above), and I hope to get consensus on the list regarding which approach I should document going forward.
>>
>> Hadriel’s proposal is to represent each data channel to be negotiated with SDP with its own m line and use BUNDLE to link them together onto a single SCTP association.  This is in contrast to the proposal in the draft that keeps all the information about data channels within a single m line.
>>
>> I think Hadriel’s proposal has some significant disadvantages:
>> 1)      BUNDLE would need to be extended to add this new form of muxing, just to put Humpty Dumpty back together again.
>> 2)      This approach requires WebRTC browsers to deal with tracking multiple m lines representing a single SCTP association; else the application has to implement the BUNDLE extensions for data channels.
>> 3)      It makes the gateway scenario simpler at the cost of complicating the direct e2e scenario.
>> 4)      It unnecessarily adds additional requirements on an important rtcweb dependency (BUNDLE) to support this work.
>>
>> There are some advantages to Hadriel’s scheme (simplifies gateway scenarios, more closely resembles current SDP usage of sub-protocol attributes), but the disadvantages seem more significant to me.
>>
>> Comments, please?
>>
>> Richard
>>
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>