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

[Harald Alvestrand]

On 03/07/11 19:13, Christer Holmberg wrote:
> Hi browser lovers,
> We've submitted a use-case/requirement draft, 
> draft-holmberg-rtcweb-ucreqs-00.txt, that we think could be used as a 
> base when those discussions start.
> The document describes some use-cases, and based on those proposes 
> browser requirement, and application-browser API requirements. It 
> focues on media related issue. Ie issues related to privacy, 
> signalling between the browser and web server etc, are currenly not 
> considered.
>
Some detailed questions/comments:

Section 5.2 lists a number of requirements, but doesn't link them back 
to use cases. For some, this is obvious (they all need them); for 
others, less so. In cases where only one or two scenarios are the basis 
for the recommendation, linking would be good.

There's also some inconsistency between "MUST" and "must" - are they 
intended to mean the same thing here?

Some comments:

F9: echo cancellation MUST be provided. Is this "provided" as in "made 
available", or "provided" as "must be used"? There are situations 
(headsets are one) where echo cancellation is not needed.

F13: The browser MUST be able to pan, mix and render several concurrent 
video streams.
"Render" is obvious, "mix" is a prerequisite for "render" for n > # of 
speakers, but what is "pan", and why do we need it?

F15: The browser MUST be able to process and mix sound objects with 
audio streams.
What is a "sound object", and in which scenario did this one occur?

F18: Which use case mandates the audio media format commonly supported 
by existing telephony services (G.711?), and why is this a MUST? Is it 
impossible (as opposed to just expensive) to handle this requirement by 
a transcoding gateway?

A5: The web application MUST be able to control the media format (codec) 
to be used for the streams sent to a peer. I think the MUST is that the 
sender and recipient need to be able to find a common codec, if one 
exists; I'm not sure I see a MUST for the webapp actually picking one.

In section 7.1, "security introduction", I think it would be more 
accurate to say that "this section will in the future describe"... there 
will be more text here as we get down to the details. Offhand, stuff 
that should get into section 7.2 (browser):

- the browser has to provide mechanisms to assure that streams are the 
ones the recipient intended to receive, and signal to sender that it's 
ok to start sending media (this translates to "STUN handshake" in 
currently-imagined implementations)
- the browser has to ensure that sender doesn't begin to emit media 
until the stream has been OKed ("stun handshake completed" is the 
currently imagined implementation)
- the browser has to ratelimit the # of attempts to negotiate a stream, 
so that this itself isn't a DOS attack
- the browser should ensure that recipient-specified limits on send rate 
are not exceeded
- it would be nice if the browser could keep some secrets from the 
Javascript so that it's not possible for a malicious webapp to use 
permission obtained from one interaction to get authorization for 
sending media from somewhere else (this may be impossible, however)

There will be more here. Good start!