Re: [MMUSIC] BUNDLE and DATA CHANNEL

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 26 April 2013 15:27 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 7EBA521F99ED for <mmusic@ietfa.amsl.com>; Fri, 26 Apr 2013 08:27:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level:
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 TbPoZBcyjVOa for <mmusic@ietfa.amsl.com>; Fri, 26 Apr 2013 08:27:48 -0700 (PDT)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id D269B21F9871 for <mmusic@ietf.org>; Fri, 26 Apr 2013 08:27:47 -0700 (PDT)
Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta03.westchester.pa.mail.comcast.net with comcast id UaQz1l00A1swQuc53fTnP4; Fri, 26 Apr 2013 15:27:47 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id UfTn1l00B3ZTu2S3bfTnP0; Fri, 26 Apr 2013 15:27:47 +0000
Message-ID: <517A9CF2.2080504@alum.mit.edu>
Date: Fri, 26 Apr 2013 11:27:46 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "Dale R. Worley" <worley@ariadne.com>
References: <7594FB04B1934943A5C02806D1A2204B1C35F47A@ESESSMB209.ericsson.se> <51796D46.9030300@alum.mit.edu> <201304252219.r3PMJv6C3392749@shell01.TheWorld.com>
In-Reply-To: <201304252219.r3PMJv6C3392749@shell01.TheWorld.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366990067; bh=P56SeGv3cF78lN9pR/5AHN2WO/MmQcd9VAULJvvfA78=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fHw0+Uv5JtsO5WH2n/ujslV8INdIqlWXQzaThAqFRVNkdiDA4UnlJ0vrUqt9xZw8q jEyOCHtHx8lXtSnsn2LMEwqTlVcyd89U/nsjUtepH2sDPE2GUUdilfkrwd/ky80kz7 Z8FjlnXsiPcJrWX7s+5FA+VVXcpwdPedKi4O5SGmFhXW1N1VKQuHfVtmTltblMcyHg jwRyClOrt8TFUBAWCf8BdouLtH0utynux5E2lmmfjMkJGfvaPAyi9WruzMb9H/Oo4t Uqn08QKTwjOS50qPVGdyzv2NA7etUO2dutY0ojtlwfYegIOGvF5uJ2t9y6eecRcwdV eC9Byuu2ybv3Q==
Cc: 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 15:27:48 -0000

On 4/25/13 6:19 PM, Dale R. Worley wrote:
>> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
>>
>> 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.

We *could*. But I suspect it is a sub-optimal mechanism. It doesn't 
scale very well.

It appears that there can be multiple demux mechanisms in use within the 
same bundle. At least, there can be one for distinguishing data channel 
packets from RTP packets. And then some other mechanism for sorting out 
the RTP packets.

And it *may* make sense to use SSRC to demux some RTP, and the new RTP 
extension to sort out some others. (Whether these should coexist is TBD.)

So I suspect that the demux indication should be signaled per-m-line, 
with some rules for when/how the different mechanisms can coexist.

> 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.

This seems a good argument for not going this way!

	Thanks,
	Paul