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

worley@ariadne.com (Dale R. Worley) Thu, 23 May 2013 22:35 UTC

Return-Path: <worley@shell01.TheWorld.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 02DD621F8A14 for <mmusic@ietfa.amsl.com>; Thu, 23 May 2013 15:35:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.98
X-Spam-Level:
X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 4ad4RcK298z8 for <mmusic@ietfa.amsl.com>; Thu, 23 May 2013 15:35:05 -0700 (PDT)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB3D21F95E5 for <mmusic@ietf.org>; Thu, 23 May 2013 15:07:51 -0700 (PDT)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4NM7Fkr019872; Thu, 23 May 2013 18:07:17 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4NM7FEH5316045; Thu, 23 May 2013 18:07:15 -0400 (EDT)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4NM7Fck5320993; Thu, 23 May 2013 18:07:15 -0400 (EDT)
Date: Thu, 23 May 2013 18:07:15 -0400
Message-Id: <201305232207.r4NM7Fck5320993@shell01.TheWorld.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
In-reply-to: <519E6265.4090102@alum.mit.edu> (pkyzivat@alum.mit.edu)
References: <C5E08FE080ACFD4DAE31E4BDBF944EB11350F3C8@xmb-aln-x02.cisco.com> <519E6265.4090102@alum.mit.edu>
Cc: mmusic@ietf.org
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:35:11 -0000

> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
> 
> 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.

I think Cullen is addressing both layers together, but his proposal is
best looked at by splitting it into two parts, one that addresses the
first layer and one that addresses the second layer.

The reason that splitting the layers is useful is that the second
layer problem has been solved -- or solved in multiple ways -- but it
is a problem somebody already has to solve, and any legacy situation
has solved it in some particular way.  So we only have to solve the
first layer problem.

As I read it, Cullen proposes that the first layer demultiplexing by

1) looking for an RTP extension header, or RTCP SDES extension
information, that tells which m= line the packet is allocated to

2) seeing if the payload type identifies a unique m= line

3) seeing if the SSRC is specified by some attribute in an an m= line

The second layer demultiplexing is close to the "A vs. B" problem, how
do you differentiate packets for the application processing streams,
which is closely tied to which application processing streams can
share the same m= line, and how that sharing is signaled.

Dale