Re: [MMUSIC] BUNDLE and DATA CHANNEL - Paul's example

Martin Thomson <martin.thomson@gmail.com> Mon, 29 April 2013 18:13 UTC

Return-Path: <martin.thomson@gmail.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 45ADB21F9A5D for <mmusic@ietfa.amsl.com>; Mon, 29 Apr 2013 11:13:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.074
X-Spam-Level:
X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 IgDpVHJ5WeW7 for <mmusic@ietfa.amsl.com>; Mon, 29 Apr 2013 11:13:19 -0700 (PDT)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7C28521F9A48 for <mmusic@ietf.org>; Mon, 29 Apr 2013 11:13:19 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id m6so3082021wiv.7 for <mmusic@ietf.org>; Mon, 29 Apr 2013 11:13:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dsgc1wHvi6UV5itEkPB12okXQPpmFiKczGFKTU/7OAw=; b=F4ig+09V1TajWHezCtovuOg/WeWJquoXOX/bm9Nd1vv+NvvNRTRhBzbRVRBgSLjkln e3nfTg+OgSZhorg4Rd65a0XVp82/6bEokAVVS9fgdZQ+Ct/nCRcASyOg5xq8djZheaTx tVxyrVZhIOkqZJx/ofZATv5IjXtNAHJ3H/t/fwdwkSBCdyHe//mzV0yQ8TNhHFZJzPbh ewiKhb3fBkKpZuXHGPN9w7PPGNJAc1I2VJbnPS8XYwnrEUT7vm99fYH4L6Ej8x/UlNG0 ggAE2ht4Q6BH0prx7aSP+b9Gd1J8IoD197V7hB9CPtC4UGg2c13KbHhpXKR1qhZmrm3F Xr/w==
MIME-Version: 1.0
X-Received: by 10.180.198.49 with SMTP id iz17mr19653488wic.19.1367259198722; Mon, 29 Apr 2013 11:13:18 -0700 (PDT)
Received: by 10.194.33.102 with HTTP; Mon, 29 Apr 2013 11:13:18 -0700 (PDT)
In-Reply-To: <517EA875.1020002@alum.mit.edu>
References: <7594FB04B1934943A5C02806D1A2204B1C3682C9@ESESSMB209.ericsson.se> <517EA875.1020002@alum.mit.edu>
Date: Mon, 29 Apr 2013 11:13:18 -0700
Message-ID: <CABkgnnWOnUZGcHONbf8Mv7kLX0ybwS_tTacU=2kRC0PDUE8m8A@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: text/plain; charset="UTF-8"
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL - Paul's example
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: Mon, 29 Apr 2013 18:13:20 -0000

On 29 April 2013 10:05, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> On 4/29/13 10:41 AM, Christer Holmberg wrote:
>> In your example there is only one SCTP m- line, and in WebRTC I guess it
>> will also be the case, but SDP doesn't prevent you from using multiple SCTP
>> m- lines - unless BUNDLE explicitly forbids it, that is.
>
> I agree. If we want to support that, then the obvious way (for DTLS/SCTP) is
> via SCTP port. That depends on there being a way to specify the SCTP with
> DTLS/SCTP. That has come and gone from the SDP proposal for SCTP.

I don't care whether SDP supports it or not, I care whether it makes
sense to do it at all.

There's a reason why you might not want to mux SCTP - it's a protocol
with multiplexing support.  Multiplexing outside of it is at best a
crude thing to do and at worst a way to dilute congestion signals.

I can understand how you can conceive of scenarios where different
application layer protocols don't play well together enough that you
want more aggressive separation.  I don't see significant value in
supporting those scenarios.

That doesn't completely preclude the future use of SCTP port for
demux, but it does constrain complexity.