Re: [rtcweb] Comments on draft-uberti-rtcweb-plan-00

[Harald Alvestrand <[e-mail]>]

The formatting gave me some pause, but just a few points....

 >2.1
 >
 >   These layouts can change dynamically, depending on the conference
 >   content and the preferences of the receiver.  As such, there are not
 >   well-defined 'roles', that could be used to group sources into
 >   specific 'large' or 'thumbnail' categories.  As such, the requirement
 >   Plan B attempts to satisfy is support for sending and receiving up to
 >   hundreds of simultaneous, hetereogeneous sources.

[BA] While I agree that the layouts can change dynamically, I am 
wondering if there is an implication that the burden of determining the 
'roles' is on the mixer.  For example, it might be assumed that the 
mixer allocates an SSRC for the 'large' category, and other SSRCs for 
the 'thumbnails' and then these SSRCs are statically mapped to MSTs and 
rendered.  However, another way to handle it is for the browser to 
handle the role assignment, and I would argue that this could make more 
sense in some cases, particularly since this could make the mixer a lot 
simpler, or even obviate the need for a mixer entirely (e.g. an RTP 
translator might work in some cases).

[HTA] I think what the draft attempts to say and what Bernard is trying 
to say as "another way" are the same thing - we're looking at a scenario 
where SSRCs don't have preallocated roles that dictate whether they make 
sense as a thumbnail-sized flows or a big-screen flow.

The decision can be taken at the sender, at the mixer or at the receiver 
- that depends on application logic, and should be left to application 
logic.


 >2.6.  Simple binding of MediaStreamTrack to SDP
 >
 >   In WebRTC, each media source is identified by a MediaStreamTrack
 >   object.  In order to ensure that the MSTs created by the sender show
 >   up at the receiver, each MST's id attribute needs to be reflected in
 >   SDP.

[BA] While I might understand why the MST ID might be useful to expose 
in the API, I don't see why this needs to be signaled over the wire. In 
general, since WebRTC is supposed to be "signaling independent", we 
should try to avoid signaling things that don't need to be signaled.  
With respect to MST id, a number of approaches seem preferrable, 
including use of an RTP SDES item, or (even better)
allowing the receiver to determine which MediaStreamTrack an incoming 
RTP stream belongs to when the SSRC is first received.

[HTA] I'm thinking about ways to achieve that effect, but that puts more 
requirements on the out-of-band signalling channels, not less. The 
purpose of MSID was to allocate stable identifiers for the streams, 
without prejudging the ways in which these could be associated with each 
other.