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

[Christer Holmberg]

Hi, 

>>>My reason for drilling down so hard on this is that a 
>>>requirement to express set difference complicates a negotiation language 
>>>by a rather large amount compared to just doing set intersection.
>>(The problem is most acute when dealing with ACLs, where adding set 
>>difference usually makes it impossible for an administrator 
>>to figure out what exactly he's specified for any rule set of some 
>>complexity, but it's a problem for any such language.)
>> 
>So, I've been assuming that this group would end up with 
>something similar to CONNEG-style set intersection, in part 
>because that the choice we saw in SIP.  In RFC 2533 
>semantics, this sort of grouping of permitted features into 
>feature sets is certainly possible.  I believe it would 
>handle the issue of related features reasonably well (e.g.
>Video codec FOO can be used with audio codec BAR or BAZ, but 
>not GOO; video codec HOO can be used audio codec BAR or GOO, 
>but not BAZ).
> 
>But it won't be simple if the issue is actually one of 
>overall system constraints.  If the first stream consuming X 
>amount of resources by negotiating video codec FOO with audio 
>codec BAZ means that second one can only have FOO if it will 
>take BAR, the situation will get ugly fast.  In general, 
>CONNEG style negotiation relies on the ability of an end 
>system to express its constraints well, and shifting 
>constraints are hard to deal with.  Functionally, you'd have 
>to restart the negotiation completely after each stream 
>started to consumer resources; that's going to make 
>server-based negotiation pretty hard.
> 
>It seems to me it would be far better to add a "number of streams"
>parameter to the API requesting the supported codecs, so that 
>the host system/browser can determine what it can support for 
>that number of streams.  It may still express feature sets, 
>but it should eliminate those which it could not support over 
>the full set of streams on resource grounds. This has some 
>suboptimal cases, but the overall approach seems to me more 
>likely to complete the negotiation in a reasonable time with 
>acceptable results.

That can be done, but we need to remember that different types of streams can consume different amount of resources.

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.

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.

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

Regards,

Christer