Re: [MMUSIC] Proposal for what bundle should say about demux

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 23 May 2013 22:32 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 F105521F8CB4 for <mmusic@ietfa.amsl.com>; Thu, 23 May 2013 15:32:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.304
X-Spam-Level:
X-Spam-Status: No, score=-0.304 tagged_above=-999 required=5 tests=[AWL=0.133, 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 MgY6Nfhd7Cz8 for <mmusic@ietfa.amsl.com>; Thu, 23 May 2013 15:32:38 -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 50A6421F85C0 for <mmusic@ietf.org>; Thu, 23 May 2013 14:59:14 -0700 (PDT)
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta03.westchester.pa.mail.comcast.net with comcast id fR701l0051c6gX853ZzEbd; Thu, 23 May 2013 21:59:14 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id fZzE1l0063ZTu2S3jZzEg2; Thu, 23 May 2013 21:59:14 +0000
Message-ID: <519E9131.2080400@alum.mit.edu>
Date: Thu, 23 May 2013 17:59:13 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: mmusic@ietf.org
References: <C5E08FE080ACFD4DAE31E4BDBF944EB11350F3C8@xmb-aln-x02.cisco.com> <519E80E4.6010904@jitsi.org>
In-Reply-To: <519E80E4.6010904@jitsi.org>
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=1369346354; bh=CTZa18/rxTs1Ti9Lt/J+3qSiOxOzzY58RABWFv5WaAc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MRJ0c327iZZ+0rDUCTypUChTS9Dq97KIPRaXoVreXF8D0TLA8PLpfqFcutbfiIXwI m4x9w/J2Er0huafLuW+hoS3N0/3y4VcrwxTlI0t9ygUSSvl3r76qbR/uOZljfA1/iq 2t7D5hbhkT7TL+IHoEh5tf3NuenQHXo+lwc559uikK3eeP2M8u8U/Go6HvqZAoIYG5 AZaeqD4MpkWhWCUO91EtYZggyJYRVDmwQtsCvbc/0nvoRbrXFMzaeVMF9zf/nxfdc9 ZTMZysWUTr16Mx9dE4MJqwOq+UdBbnachsmlgyzZD7OPH7crA2iRmJjhKU7QwZhYqd wFEh41+5QMvxw==
Subject: Re: [MMUSIC] Proposal for what bundle should say about demux
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, 23 May 2013 22:32:44 -0000

On 5/23/13 4:49 PM, Emil Ivov wrote:
> Hey all,
>
> So first of all, I'd like to say that I like the approach and think this
> is the way to go.
>
> I have just one concern here. I already mentioned it in the call but I
> am not quite sure what the answer was. So here I go:
>
> On 23.05.13, 21:02, Cullen Jennings (fluffy) wrote:
>>
>> Here's is my proposal for roughly what the bundle draft should say about this demux topic
>>
>> Application will decide which packet processing pipeline to pass an given RTP/RTCP packet to based on what the application knows:
>>
>> 1) If future RFCs define new things (like RTP header extension), that explicitly specify the mapping, check if that future RFC is in use and if so then use that to form the mapping
>
> So my problem with having the above as number one is that while it would
> work perfectly with protocols like XMPP that have good discovery
> support, it would be a problem for SDP O/A based ones like SIP and WebRTC.
>
> The reason is that even when demuxing RFCs like that exist, an offerer
> won't know if the remote party supports them. They would hence always
> need to construct an offer where a fallback to another mechanism could
> be possible (like for example falling back to uniquely allocated PTs).
>
> Now, if the offerer does indeed know in advance that the fancy demuxing
> RFC will be supported, and only then, they would be able to rely on it
> and be careless about PT allocation.

It will work for CLUE, because CLUE won't start using it on the first 
O/A. It will only do so after it knows that it makes sense. And in clue 
it can potentially take precedence over PT. *In theory* we could have 
one switched capture that sometimes gets an H.264 RTP stream, and other 
times gets a VP8 RTP stream. (I don't know if that is likely to happen 
in practice. Jonathan might have more to say about that.)

IMO the "before the O/A completes" issues are separate from the "after 
the O/A completes" issues. I'm still not convinced that the "before the 
O/A completes" issues are important. (We have reliable 183 responses to 
deal with it.) But I'm ok with Cullen using PT to solve that problem if 
he thinks he needs to.

I'm more concerned with having a well defined way of associating packets 
with m-lines in the bundle after the O/A is complete.

	Thanks,
	Paul

> I believe we've built bundle port allocation and trickle ICE (and a
> number of other O/A mechanisms) around the same model.
>
> Emil
>
>