RE: Notes from the IETF RTCWEB interim meeting

[Contributor hat on for me too!]

Same disclaimers as Harald.

Just to add a couple of things I noted and I think is important from a W3C perspective:

>
>Use Cases & Solution Requirements: 45 minutes
>draft-holmberg-rtcweb-ucreqs (Christer - 15 min)
>discussion (30 min)
>
>Holmberg went through the requirement scenarios one by one, and the
>chairs said "if you don't want this to be a scenario we should
>support, shout".
>Important discussions:
>
>- The "multiparty video communication" scenario (no centralized
>server) gathered commentary. People pointed out, among other things,
>that this required mixing of audio streams in the client, and
>reasonably advanced control of audio (since the scenario suggested
>placing people's audio streams in stereo space by panning).
>- The "multiparty game" scenario (also without central server) also
>requires mixing of audio streams with locally generated audio. Even
>more control.
>- The "telephony terminal" scenario is a driver for supporting DTMF
>tone signalling as a separate payload type. Given that there are ~3
>different ways to do DTMF signalling over SIP and RTP, this could turn
>expensive.
>
>No scenario was rejected outright. I think we can assume that they're
>all in the set we need to design for support of.
>One interesting input was Keith (Keith Drage?) who wondered if WebRTC
>was going to throw away the IETF's years of work on supporting
>centralized conferences without even thinking about it (XCON and
>friends). I think it would be good if the WG concludes that we're not
>intending to preclude their use in any way. It's unlikely that they
>will be reasonable to use in all scenarios, of course.

Here I think that the discussion regarding panning/mixing (present in some use cases) of audio concluded that this was questions for W3C; so this is something for this WG to take into account (and possibly discuss with the Audio WG).

>
>Security: 30 minutes
>draft-rescorla-rtcweb-security (Rescorla 15 min )
>discussion 15 min
>
>This generated a *lot* of heat. Once we got down to what the heat was
>actually about, it seemed that:
>- Asymmetric exchanges, of whatever type, protect the keys against the
>server. This is a Good Thing, except where wiretap capability is
>required - and, as EKR pointed out, the server has a *lot* of ways to
>mount a MITM attack even with asymmetric key exchange if it knows it
>needs to wiretap when the call starts.
>- SDES (passing keys via SIP/SDP) compatibility was required for
>backwards compatibility/interoperation. So at least in some cases, the
>server will know the keys, and the keys have to be API-accessible in
>this case. Two mechanisms requires more support than one mechanism, so
>one needs to have a good use case for requiring both.
>- EKR was dismissive of the idea that people would use the
>verification mechanisms in ZRTP and friends in a secure way. Others
>(in particular Alan J, I think) argued that people who had reason to
>be paranoid would use them when available, and that this was "good
>enough security".

I think that it was mentioned that it must be very simple (e.g. indication in the browser chrome) to undertstand that mic and cam is being used be the web application, and likewise that it must be an intuitive way to revoce the permission to use mic and cam.

Received on Tuesday, 14 June 2011 11:54:38 UTC