[RTW] Review of draft-holmberg-rtcweb-ucreqs-00 (Web Real-Time Communication Use-cases and Requirements)

[Christer Holmberg]

Hi Ted, 

>>Take video conference as an example: the stream for the main display (e.g. representing the active speaker) might use a very resource consuming codec/format/resolution, while there can be a number of streams for small "thumbnail" 
>>displays that require much less resources.
>
>Just to be sure I understand the example, the assumption here is that the "Active speaker" stream can switch to a different speaker, so that there would be a renegotiation for both the previously "Active speaker" and the newly 
>selected one, right?

The stream can switch to a different speaker, yes.

Whether a renegotiation is needed depends on how the system is built up. If there is a middlebox that mixes the streams etc there will be no need to renegotiation, because the broswer will always receive the streams from that middlebox - no matter who is the active speaker.

But, in peer-to-peer scenarios I guess a re-negotiation would be needed.

>I think this is pretty workable, provided we don't have to restart the negotiation from the beginning.  If there are multiple known good feature sets for each speaker, switching among them isn't such a problem.  It's easier, 
>obviously, if it is a straight swap (high-end codec moves from speaker A to speaker B).  It's a little harder if the codecs available for B are different, but it still works reasonably well if the resource consumption is similar.  
>But if switching from speaker A to speaker B forces a complete renegotiation of all streams because speaker B's requirements are very onerous, we can expect some impact on app performance.

True. 

But, renegotiation in general should be supported, in my opinion. 


>>We also need to ensure that we don't make life to difficult for the web app developer, by mandating him/her to browse through a potentially large list of alternatives before requesting streams.
>
>My personal concern is more with complexity than size.  If there is a large list of capabilities, all to the good.  But if the complexity of the feature sets is high or the interaction among them high, you can end up with least-
>common-denominator behavior pretty easily.  There are some ways to improve that--CONNEG allows for named features sets, for example, and well-known names for common clusters could significantly speed processing--but we don't want to 
>make computing the optimal set intersection a major drain on time or resources.
>
>>So, I agree that being able to query for different alternatives is a good thing, but it should also be possible for the web app to simply request an explicit stream set (based on web app logic and/or an offer received from the 
>>remote peer), which is then either accepted or rejected by the browser. And, if rejected, it would then be good if the browser provided some information on why it was rejected. The web app could then either query for alternatives, 
>>OR simply try to request a new stream set (based on the error information provided by the browser for the previous request).
>
>I really don't think the browser providing information on why it was rejected is all that useful; we don't want these to be consumed by humans.

Well, I don't consider the web app a "human" :) 

The web app doesn't need to forward that information to the users (humans), but the web app itself may use the information.

>I personally think it is better if the web app passes down a list of requested feature sets and lets the browser compute the best intersection.  You could manipulate that by having the web app decompose the offers itself and pass 
>them down one by one in the order it felt was appropriate, taking the first match.  There's no API difference there, it's just a bunch of serial one-possibility offers rather than a full set.  But the typical APP is going to want 
>"give me the best I can get", at least at my guess, rather than wanting to keep on top of what the preferred set intersections are itself.

We would need to define what those feature sets are.

Also, it might work when the web app represents the originating user, ie the one who is going to send the initial offer.

And, in case the web app terminating users, and it uses SIP, it needs to be able to request the explicit codecs etc (rather than a featre set) that it receives in the SDP offer.

Regards,

Christer