Re: [MMUSIC] BUNDLE and DATA CHANNEL

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 26 April 2013 17:33 UTC

Return-Path: <christer.holmberg@ericsson.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 940F421F9810 for <mmusic@ietfa.amsl.com>; Fri, 26 Apr 2013 10:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.383
X-Spam-Level:
X-Spam-Status: No, score=-5.383 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 ajz2T+IGrJ4a for <mmusic@ietfa.amsl.com>; Fri, 26 Apr 2013 10:33:33 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 923F221F980C for <mmusic@ietf.org>; Fri, 26 Apr 2013 10:33:32 -0700 (PDT)
X-AuditID: c1b4fb30-b7f266d000000cb5-93-517aba6bb444
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 8B.5D.03253.B6ABA715; Fri, 26 Apr 2013 19:33:31 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Fri, 26 Apr 2013 19:33:30 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [MMUSIC] BUNDLE and DATA CHANNEL
Thread-Index: AQHOQgMEIk6q+PHpSI2jUL+JN2f+GpjoHi4ggAB69ACAACdgzw==
Date: Fri, 26 Apr 2013 17:33:30 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C363182@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C35F47A@ESESSMB209.ericsson.se> <51796D46.9030300@alum.mit.edu> <201304252219.r3PMJv6C3392749@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C361D3A@ESESSMB209.ericsson.se>, <517AB252.90602@alum.mit.edu>
In-Reply-To: <517AB252.90602@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+JvrW72rqpAg/29uhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWx5tMz1oLTIhV3r3WxNDDOEuhi5OSQEDCR eH3zOzuELSZx4d56ti5GLg4hgcOMEqcf7GGEcJYwSkycsJ+1i5GDg03AQqL7nzaIKSKgITFp qxqIySygLnF1cRCIKSygK/F4cQxEgZ5Ey4kakOEiAk4S957cZQOxWQRUJd7v+8YIYvMK+Ep0 /26CWtrOJDFrySJGkF5OAS2Jo0+jQWoYgQ77fmoNE4jNLCAucevJfCaIgwUkluw5zwxhi0q8 fPyPFcJWlPj4ah8jRL2OxILdn9ggbG2JZQtfM0PsFZQ4OfMJywRGsVlIxs5C0jILScssJC0L GFlWMbLnJmbmpJebb2IExsbBLb8NdjBuui92iFGag0VJnHeGVGWgkEB6YklqdmpqQWpRfFFp TmrxIUYmDk6pBsayh9qKMzekMTc+37LFtuZDzNldNddSFMu4FavOVx7XumNgfznluPqta7pz 0zMUjD4xuC5TmcDQmt7N967Cb8fjDS2KWZ2Pn2sqKP0XEZpwKlr9ZKPc4yO3Dl4QKKp3OPoo yPNnZMeXE/e3TzrYutaNd3m0fWtVSxafG7NA6Pe//Qm9Tn7uwUosxRmJhlrMRcWJAJZc6Tdb AgAA
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL
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: Fri, 26 Apr 2013 17:33:33 -0000

Hi,

>>>> Yes - we need a way to signal the demux mechanism to be used.
>>>> (Unless there is only one possibility. And we have already disproved
>>>> that.)
>>>
>>> We could use different group "semantics" values to indicate the multiplexing mechanism.  One endpoint could probe the other to discover
>>> which mechanisms it supplies by offering a collection of bundles containing no constituents, one for each mechanism.  The answer will show
>>> which mechanisms the answerer supports.
>>
>> My idea was the endpoint simply lists the media description proto values that it is capable of multiplexing for a given 5-tuple:
>>
>>       Example: a=muxcap: RTP/AVP, SCTP/DTLS
>>
>> ...or something like that.
>
> That is sufficient *if* there is a single mux/demux algorithm per proto.
>
> But I don't think that is true. I think we will need to signal this
> per-m-line, and specify the demux algorithm(s) for streams that bind to
> that m-line.

I don't it matters if there are multiple algorithms - the important thing is that the endpoint is able to mux/demux the specific proto using A algorithm.

Otherwise, we can have different values, one for each algorithm. Note that in my example I used to SDP proto values, but we could use whatever.

HOWEVER, before we go into the details, I would like to know whether people generally think we need a mechanism which allows to list the protos an endpoint is able to mux/demux.

>> Of course, an endpoint needs to be able to multiplex all media that it inserts in a bundle group. But, it may not always insert m- lines for everything it is able to multiplex, so I think an explicit indication would be good.
>
> There may be more than one stream per m-line, but I think we can assume that every stream binds to one m-line.

I am not sure I understand what you mean by "binds to one m-line".

However, keep in mind there can be multiple streams per m- line already today (at least for RTP), so it's not something BUNDLE specific :)

>> It is important to remember that, whatever you multiplex, all media have to use the same IP transport (e.g. UDP).
>
> Unfortunately SDP has a pretty confusing idea of "transport".
> The proto field identifies a whole stack of protocol layers.

Yes, and therefor, when we say "must use the same protocol", we need to make it clear that we refer to the Protocol value in the IP header - not the proto value in the SDP media description :)

I will reply to the rest of your e-mail later, because I need a little more time to read it :)

Regards,

Christer