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

From: [email-masked] (Dale R. Worley)
Date: Tue, 7 May 2013 16:30:18 -0400 (EDT)

> From: Magnus Westerlund <[email-masked]>
> 
> 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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 May 2013 15:28:21 -0700

> the SDP trap, we need to ensure that the solutions around are not SDP

[BA] Indeed.  It is one thing to chain the WebRTC API to the SDP boat anchor;  it is another thing to require use of SDP eyeglasses to navigate the ship by REQUIRING SDP to be used in order to make sense of RTP SDES packets.  Overall, I think that various aspects of WebRTC (including things like signalling resolution or frame rate changes) should be handled in RTP/RTCP rather than in signalling so as to maintain WebRTC signalling independence. 

>Thus, using SDES items for in stream bindings are something I
> support, but the label should be done in such a way that it can be
> handled as labels for a particular purpose and thus be included in other
> signalling solutions.

[BA] Agree. 

> - Application related usage of video streams, for example if a SSRC is
> currently carrying a main video or a thumbnail and thus which negotiated
> constraints it tries to adhere to.

[BA] I believe that this is often handled today by cooperation between the mixer and application without new RTP/SDP functionality (other than simultcast/layering support).   For example, the mixer can decide to forward a higher bandwidth simulcast stream or more layers since the audio indicates that the stream relates to the speaker.  The application sees the change and promotes the stream to the main video and demotes the stream previously occupying the main video to a thumbnail.  Why couldn't this approach work for WebRTC as well?  Isn't enabling dynamism the goal of frameworks such as AngularJS? 
 
> - Is the this SSRC part of a simulcast set, and if which quality strata
> does it carry

[BA]  This could potentially be indicated inband within the codec, which would enable a receiver to figure things out before the Answer arrived. 
 
> - Is this SSRC a related repair or retransmission stream to another
> primary media carrying SSRC.
> 
> One issue is that for example the first can easily be a dynamic process,
> some implementations will reconfigure a SSRC between application purpose
> due to user or application input.
> 
> Just these three above examples points to one very clear issues in
> making progress here. We must try to clearly define the usage different
> people see. See which is the same, which is orthogonal and which must be
> possible to have in place at the same time.
> 
> This is the realization we have come to with in the discussion around
> the SRCNAME proposal:
> http://tools.ietf.org/html/draft-westerlund-avtext-rtcp-sdes-srcname

[BA] Yes, there are advantages to additional SDES information that should be explored further, particularly in situations where signalling independence is a goal.  Personally, I was ok with the initial drafts of SRCNAME, but am not sure it can be stretched to handle all the simulcast/layering info (since that may end up in-band within the codec anyway) .

> This discussion has proven the importance of having common terminology
> and I hope we can make progress with the grouping taxonomy, because that
> document will discuss both object names and different possible relation
> ships between these different types of object, like RTP sessions, SSRCs,
> FEC groups.

[BA] IMHO, I think it has proven we do not have agreement about some very basic architectural issues :)
> media stream (specific SSRC) can be captured with its own unique Media

[BA] I don't know that each SSRC has to be bound to its own unique Media
Description (e.g. only one SSRC to an "m=" line).  I also don't think that each
SSRC should have to have its own a=ssrc line either.  As long as it is possible
to figure out what parameters apply to a given SSRC (some of which could
be transmitted within the codec and some within SDES), that is enough.  
Applications are built today and they work without the restrictions being
proposed in either Plan A or Plan B.   Handling these things isn't even all
that complicated. 

> I also think it is important to realize that a particular SSRC may at
> the same time have multiple relationships, for example it can be the
> primary for a retransmission, part of a FEC group, be a particular
> simulcast quality strata.

[BA] Personally, I'd like to see an Internet-Draft describing what existing
implementations do before advocating that we allow infinite degrees of
flexibility here.  For example, there are implementations that use distinct
SSRCs for different simulcast streams and layers (which is why things like
SDP SSRC groups and SDES SRCNAME can be useful to bind them together).  

> Please don't bind identifier and group ides to SDP concepts. Lets use a
> level of indirection that both enables usage without SDP in certain
> cases, and which can be bound to other signalling solutions in the future.

[BA] I agree -- and thank you for sending this to the list.