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

[Bernard Aboba <[e-mail]>]

Magnus said: 

> 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. 

[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 :)
> 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)?

[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.