Re: [rtcweb] Why requiring pre-announcement of SSRCs is a problem for conferencing ( Was: New Version Notification for draft-uberti-rtcweb-plan-00.txt )

[Bernard Aboba <[e-mail]>]

Emil said: 

>> How do you plan to demultiplex the media sources without knowing whose> > SSRC belongs to whom?>> Demultiplexing itself shouldn't be an issue.... > > First, many applications may not require such information at all, as
> they may simply be rendering whatever stream they get.
> 
> Others may need this only for presentation purposes (e.g. showing a name
> underneath a video). In this case they would be potentially happy with
> getting it later, asynchronously and merged with other display
> information that the focus may be sending their way.
[BA] Scenarios where the media can be directly rendered, or the required information can arrive later are idealfor potential handling outside SDP (e.g. within RTP/RTCP).   So "known whose SSRC belongs to whom" can be handled adequately without SDP in simple cases (e.g. single media stream per participant). 
> > Consider especially the case of repair flows, for
> > which one must know which primary flow the repair flow corresponds with.
> 
> Applications using such repair flows would need to know about
> stream/SSRC relations relatively early in the process. Roni already
> indicated RTCP is widely used for this purpose and I believe this can
> also be a viable option here.>
[BA] I believe that RTP and RTCP can be used successfully to provide repair and FEC relationships, as well as simulcast and layered coding information.  However, this is trickier than the "simple rendering" or "name" case, because until the relationships are known to the endpoints it may be difficult for them to properly utilize those streams.  Having a reliable signaling mechanism only solves the problem once the Answer has arrived, but it may be desirable to be able to handle media before then.  Similarly, RTP/RTCP info only helps once it has arrived, and of course packets can be lost.  Overall, I believe it is possible to make things work without SDP over the wire, assuming our expectations are set appropriately.  Having RTP/RTCP alternatives available is useful within a framework such as WebRTC where there is no mandatory signaling mechanism, but also in scenarios where rapid response to changing conditions is needed (such as in congestion control).  
> Obviously, for this to work, the WebRTC APIs would need to provide means
> of obtaining and setting this information from/to the browser.
> Applications need to be able to start and stop specific streams, relate
> them as layers or FEC repair flows.
[BA] I hope that you're not talking about application-specific RTCP packets; I would prefer to avoid that if possible.  
> > Given the complexities here, I don't think it's entirely fair to call
> > the signaling "absolutely unnecessary".
> 
> My point is that it could be "absolutely unnecessary" and even
> prohibitive for some applications, nice to have in others, and required
> by others yet.
[BA] There are a number of current scenarios in which frequent signaling is not desirable and in which RTP/RTCP is widely used instead.   As an example, it is one thing to use SDP to communicate the envelope of what a receiver can handle (resolutions, frame rates, etc.).  It is another to use SDP to attempt to signal changes that can happen as frequently as multiple times a second.  If we don't make it possible for that to be "absolutely unnecessary" (or worse, not make it clear that this undesirable) we will have been negligent. 
> Having SDP O/A as the (sole) mechanism that is available to all these
> categories sounds like a problem.
[BA] Since SDP O/A isn't a universal hammer, depending on it exclusively is a fundamental design mistake.