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!