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

[Ted Hardie]

On Wed, Mar 16, 2011 at 12:11 AM, Christer Holmberg
<christer.holmberg at ericsson.com> wrote:

> 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?

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.

> 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.  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.

regards,

Ted Hardie

> Regards,
>
> Christer
>