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

[[e-mail] (Dale R. Worley)]

> From: Paul Kyzivat <[e-mail]>
> 
> 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