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

[Bernard Aboba <[e-mail]>]

Paul said: 
> IMO the 2-way handshake as always depended on an implicit commonality > between caller and callee, and/or applications simple enough that it is 
> feasible to encompass all possible options within the first offer.
> 
> So it works well when you are calling from a "phone" and it is likely 
> that the thing you are calling is also a phone. But it doesn't work very 
> well if you are a telepresence system calling another telepresence system.
> 
> Even in more complex cases you can probably get things to work in one 
> O/A exchange if a large percentage of the things you may call have 
> similar configurations.
> 
> But the general case is going to require multiple O/A exchanges, or else 
> exchange of info via some other channel prior to the O/A exchange.
[BA] I agree that the "general case" may require multiple O/A exchanges. However, it would be desirable for common WebRTC cases to be handled with a single O/A exchange,  since common WebRTC cases are presumably less involved then CLUE scenarios. 
Paul said:
> Certainly the offer can describe a bunch of sendonly streams. That is 
> the easy part. The hard part is describing what you want to receive, 
> without knowing what is available to be received.
[BA] I would distinguish statements about capabilities (e.g. what you are capable of receiving) from indications about what you want to receive. In a CLUE scenario, there can be  number of very different configurations that need to be expressed and decided between (e.g. multiple streams to be displayed on multiple screens, etc.).  Whereas in WebRTC, there are a number of use cases (such as multiple RTP streams sent by a mixer, to be displayed on a single screen) that we want to support in as simple a way as possible.  So the question in my mind is "what do we need to do to allow those WebRTC use cases to be handled in a single O/A exchange" while at the same time, not ruling out support for more complex cases, which would require multiple O/A exchanges (or use of out-of-band signaling, as advocated in CLUE).  > Also, it is hard to describe the content of those sendonly streams 
> sufficiently in the offer so that the answerer will know whether it 
> wants them or not.
[BA] In WebRTC use cases, I'd suggest that the decision is somewhat simpler than it would be for CLUE (e.g. it doesn't make sense to reject a screen sharing video stream in a presentation scenario).  So if an Offerer provides some basic info (how many streams it can handle, how much bandwidth, the resolutions it supports, etc.) that will often be enough for the Answerer to send something reasonable, and for the negotiation to conclude in a single O/A.  Of course, the Answerer could select something that the Offerer finds unacceptable, which would need to be cleaned up in an additional O/A exchange.  I'm just saying that we should strive to be able to complete some common uses cases in a single O/A, if possible.  
> This assumes that the Offerer can handle incoming RTP streams up to the maximum number of receive SSRCs before it receives the Answer which can explicitly declare the SSRCs.
[BA] Yes, that is my assumption -- and I believe that it is possible to engineer things so that this will work. 
> >     In addition, since the
> >     sources are known ahead of time by the recipient of said sources, it
> >     is prepared to demux them by SSRC without any signaling/media race.
> 
> *How* are the sources known ahead of time by the recipient???

[BA] I think that Justin was noting that in the "Plan B" proposal, media doesn't flow until each side has gotten the list of declared SSRCs and responded to it.  So the recipient knows the sources ahead of time.