Re: [rtcweb] No Plan

[Bernard Aboba <[e-mail]>]

Jonathan said:
 
"I think No Plan and Plan B are largely isomorphic in a WebRTC context.  The primary difference is that rather than using a=ssrc and a=receive-ssrc (and whatever other Plan B attributes would be needed) to control sources within an m-line, instead direct Javascript APIs are used for the same semantics. It's up to the application to communicate the relevant information end-to-end, in parallel to however it communicates the SDP blob."
 
[BA] The use of O/A to turn sources on/off is definitely one thing that "No Plan" avoids, and that's something in its favor.  However, I don't think that's the only difference. 
 
As I see it, No Plan, when added to Plan B, results in simplifications along several dimensions.  I don't think that No Plan prohibits use of a=ssrc lines either in the API or over the wire, but it does makes it clear that they cannot be required for de-multiplexing (which No Plan handles via PTs) or rendering of incoming streams (which can be handled via APIs without MSID declarations).  Basically, No Plan says "Don't try to Bundle more things than you can de-multiplex using PTs".  It's a bit like telling a snake "don't eat an elephant whole, chop it up into bit sized pieces".  Yes, you could try it the other way,, but is the added complexity (and indigestion) really worth it? 
 
Personally I wouldn't say it is a "No Plan" no-no if createOffer were to produce SDP with a=ssrc lines, or if setRemoteDescription were to process a=ssrc lines included by the remote peer.  What I think No Plan would have a problem with is if undeclared sources couldn't be rendered, or if O/A were required to turn already declared sources on/off, which can happen so rapidly that O/A couldn't possibly handle it.  Also, requiring O/A for dropping streams breaks congestion control because in a highly congested situation, the signaling packets would probably get dropped along with the media, so that the signaling to drop streams couldn't get through.  A sender MUST be able to drop streams in that circumstance. 
 
In answer to questions about "whether you can declare separate streams for screen sharing versus other video" I would think that No Plan could allow a=ssrc lines for that, but if you just wanted to send them and have the application figure out which was which (e.g. via app-specific signaling) you could do that too.  
 
One area where I think all the  Plans are weak is handling simulcast/layered streams.  I don't think max*sssrc makes sense because it groups together sources, and streams (including simulcast, layered streams and FEC).  A receiver really needs to be able to declare the maximum number of sources it can receive and the maximum number of streams it can send, as well as declaring the simulcast and layering schemes it can handle.  This is NOT the same as actually stating what it will be sending or receiving at any given moment.  In general, it will be up to the sender to make the decision based on the feedback it is getting.  
 
Another comment on "No Plan" relates to the need for an RTP extension to declare things like simulcast and layered stream dependencies.  These dependencies can be expressed in SDP as alluded to in  Plan B, and they also can be described within some codecs (e.g. H.264/SVC allows this).  IMHO, SDP O/A does have a role here, in describing the receiver capabilities (what simulcast/layered streams it can support) as well as the sender capabilities (what the sender is capable of sending).  Since neither an RTP extension nor individual payloads can provide reliability, having this done in O/A via reliable signaling has an advantage.  But as long as the streams sent by the codec is self-describing, I don't think an RTP extension is needed.  
 
However, the case of FEC is a bit trickier for No Plan.   If you don't declare the FEC SSRCs and dependencies in SDP, then you do need to encode this in RTP, and the codec-specific route may not be sufficient (opinions?).  Also, doing this purely in RTP could create some problems if the descriptions were lost because the receiver could end up trying to render a FEC stream, with bizarre results.  So this is one area where it seems to me that "No Plan" may need some additional thought.