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

Harald Alvestrand <harald@alvestrand.no> Thu, 07 November 2013 06:40 UTC

Return-Path: <harald@alvestrand.no>
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 F2C3111E8180 for <mmusic@ietfa.amsl.com>; Wed, 6 Nov 2013 22:40:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 3Uut8B86SiOR for <mmusic@ietfa.amsl.com>; Wed, 6 Nov 2013 22:40:06 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D921E11E810B for <mmusic@ietf.org>; Wed, 6 Nov 2013 22:40:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 41DD139E05D for <mmusic@ietf.org>; Thu, 7 Nov 2013 07:40:02 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKIDcF4OxE9t for <mmusic@ietf.org>; Thu, 7 Nov 2013 07:40:01 +0100 (CET)
Received: from [31.133.161.198] (dhcp-a1c6.meeting.ietf.org [31.133.161.198]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B776839E03A for <mmusic@ietf.org>; Thu, 7 Nov 2013 07:40:00 +0100 (CET)
Message-ID: <527B35BE.2070004@alvestrand.no>
Date: Thu, 07 Nov 2013 07:39:58 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <03FBA798AC24E3498B74F47FD082A92F3D87235B@US70UWXCHMBA04.zam.alcatel-lucent.com> <527B28D1.9090006@alum.mit.edu>
In-Reply-To: <527B28D1.9090006@alum.mit.edu>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
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 06:40:13 -0000

On 11/07/2013 06:44 AM, Paul Kyzivat wrote:
> On 11/6/13 8:54 PM, Ejzak, Richard P (Richard) 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.
>
> If SDP had a richer syntax (e.g., a recursive structure like XML),
> then I think this would be a good idea.
>
> But given the syntax bounds we must live within I don't think it flies.
> We are already stretching things a lot to get Bundle to work in the
> current form. And we haven't yet extended Bundle to include the data
> channel SCTP m-line. (That is a desire of RTCWEB.)
>
> If we attempted to also bundle data channels, then we would end up
> with the following (not using SDP syntax):
>
> Bundle(
>   rtp m-line
>   rtp m-line
>   ...
>   Bundle(
>     sctp m-line
>     channel m-line
>     channel m-line
>     ...
>   )
> )
>
> I really don't want to even think about how to do that in SDP.
>
> Also, if we really thought this was the right thing to do, then it
> would probably be right to have separate m-lines for each SCTP port
> multiplexed on the same UDP port. That would give yet another level of
> nesting!
>
>     Thanks,
>     Paul

I agree with Paul here.

For normal (as I think of it) WebRTC usage, we want one m-line to
describe the SCTP association, and the channels are completely invisible.

Richard's proposal makes the channels visible, but otherwise retains the
syntax of the WebRTC usage.

Having an alternate SDP description of an SCTP association would add
parsing complexity, reduce interoperability and generally be a pain in
the posterior.

Let's just not go there.