[RTW] Review of draft-holmberg-rtcweb-ucreqs-00 (Web Real-Time Communication Use-cases and Requirements)
Harald Alvestrand
harald at alvestrand.no
Wed Mar 9 15:01:38 CET 2011
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!
More information about the RTC-Web
mailing list