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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 23 May 2013 19:04 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 BD64121F8FED for <mmusic@ietfa.amsl.com>; Thu, 23 May 2013 12:04:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.289
X-Spam-Level:
X-Spam-Status: No, score=-0.289 tagged_above=-999 required=5 tests=[AWL=0.148, 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 atDjmIvrIXJH for <mmusic@ietfa.amsl.com>; Thu, 23 May 2013 12:04:06 -0700 (PDT)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id D094C21F9720 for <mmusic@ietf.org>; Thu, 23 May 2013 11:39:34 -0700 (PDT)
Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta13.westchester.pa.mail.comcast.net with comcast id fQgx1l0031ap0As5DWfaGv; Thu, 23 May 2013 18:39:34 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id fWfa1l00K3ZTu2S3iWfaRH; Thu, 23 May 2013 18:39:34 +0000
Message-ID: <519E6265.4090102@alum.mit.edu>
Date: Thu, 23 May 2013 14:39:33 -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>
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB11350F3C8@xmb-aln-x02.cisco.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=1369334374; bh=c0ztsFiaVH3qLWdfU+a1WCKr6SJczr5KyrX76Rr+XK4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PpQZB9GPNf8pBuu2Iq+WOFiWCd0hZ7/Ws9RmfhrD+FbQrmjzzElgoFRiNhUkBx50b /eUMSTi2EYZiDeBKSTA0FJ6SdV1N7LBRKhIt95yRrf2pU2GUtMVWgL3n/fh0V87amS 2s/VcROc9ArQDDZECvGnso6lUBLL2mwY6DFR8DhVzIDmB1zmYSWRWgZP/Xq4lJ1iwT PMsI3sX1gysnJK5DLviC1MrdV2zaPc3mRxTHw9RJ+8cA8hh/fCi7JBS0Dl7RJkorJm OvqkM82+jT4KmqSl4JgZsSeHMN1AaPfy/hDTswUPA28/hsLDWT4HQoyfQA+GQRyTPz lj/0x7lIqoSAw==
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 19:04:20 -0000

Cullen,

I just posted a separate, related, message on associating packets to 
m-lines.

IMO they are complementary, and somewhat layered:

First, the packet should be matched to the m-line.
The m-line then provides an bunch of related info:
- mapping from PT to codec
- bandwidth info
- per-ssrc info
- labels that can be bound to application specific data
- ...

All of that info is then available to help associate the packet to a 
processing pipeline. Then the algorithms you talk about kick in.

Of course that is the hypothetical layering. It is subject to 
optimization. Generally, once one packet has been bound to a processing 
pipeline then the SSRC from that can be remembered, and used to shortcut 
the mapping for future packets that have the same SSRC.

	Thanks,
	Paul

On 5/23/13 2:02 PM, 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
>
> 2) If the PT type is uniquely identifies a mapping, use that to form the mapping
>
> 3) If application knows the SSRC the other side will use, use that to form the mapping
>
> 4) if there is no way to know which pipeline to pass it too, the packet MAY be discarded or the application MAY decide to buffer it until the mapping is known
>
> This is trivial to implement. It meets the requirements for Plan A, Plan B, UCIF, CLUE, and so on.
>
> We could swap the order of step 2 and 3, My thinking for this order was the only time it made any difference the order was if the PT were unique and indicated a different mapping than the SSRC. The only way this could happen is with a SSRC collision so the PT is the one that would be correct not the SSRC. If someone feels strongly the order of steps 2 and 3 should be the opposite way around, I can live with that.
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>