Re: [MMUSIC] Demultiplexing via indexes in RTCP SDES packets

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

> From: Magnus Westerlund <[e-mail]>
> 
> I do agree that part of a solution is the possibility to bind one or a
> set of SSRCs to a particular usage that is signalled somehow. However,
> there is several different types of bindings that is needed here. Just
> binding to a m= line is likely short sighted, restrictive and incomplete.
> 
> I support your proposal of including a level of indirection enabling us
> to avoid having to update the SDP for any addition of SSRCs, which a
> a=ssrc based solution would require.
>
> However, SDP is not the only signalling solution, it is the currently
> dominating one, but if you ever is going enable us of breaking out of
> the SDP trap, we need to ensure that the solutions around are not SDP
> specific.
> [A lot of examples of additional "binding" information that is
> needed.]

What you say is true, but those aren't the problems I'm looking at.
My assumption is that any problem that needs to be solved will be
solved (by somebody else) in a way that is workable in "SDP without
bundling".

Once that has been solved, then how do you solve the problem in a way
that is workable in "SDP with bundling"?

The latter is the part of the problem I'm looking to solve.  It breaks
into two parts:  One part is the particular way bundling is signaled
in SDP.

The other part is the way that the RTP/RTCP over the bundled
connection is demultiplexed.  At this layer of analysis, all that is
needed is to be able to sort the RTP and RTCP regarding which m= line
it is associated with.

The remaining parts of the SDP provide the other binding information
that you discuss -- once the RTP is associated with the correct m=
line, the problem is reduced to what the problem would be without
bundling.

Of course, if the signaling protocol isn't SDP, the demultiplexing I'm
considering does not apply.  But in that case, "bundling" as such
isn't a consideration, because "bundling" is essentially how to use
only one transport association to carry all of the packets described
by an SDP description.  Presumably any newer and better signaling
protocol would be designed to not have the limitations of the existing
SDP, and so the bundling problem would be taken care of from the
beginnin.

> I think one important question here is if you really want and think it
> is possible to bind have each different usage or purpose for an RTP
> media stream (specific SSRC) can be captured with its own unique Media
> Description (m= block)?

I've previously believed that media sources can be separated into a
small number of "roles"; that any application intrinsically defines a
(very) small number of roles; and that the multiple SSRCs for the
multiple media sources that all have the same role can all be sent
under one SDP m= line without confusion.

But it appears that the above belief is not true, so I'm considering a
different demultiplexing algorithm, one that does not require distinct
payload type numbers for different m= lines (and thus can support a
large number of m= lines and a large number of payload type numbers
for each m= line).

A fundamental problem with this sort of demultiplexing is how to do it
without putting a prefix or encapsulation on every RTP packet (as that
makes it harder for intermediate devices to see the nature of the
contained data).  But we can do indirection, following the SSRC from
the RTP packet to information carried in the corresponding RTCP.

Dale