Notes from the IETF RTCWEB interim meeting

[Contributor hat on]
I thought it might be useful to share some notes I made after last 
week's RTCWEB telephone call / interim meeting.
This is NOT any kind of official minutes, might blatantly misrepresent 
some viewpoints, and may miss any number of things. Read for entertainment!

-----------------------

The below is produced by copying the agenda and making comments on each 
point.

-----------------------------------------------------------------------------------
Architecture:  30 minutes
draft-alvestrand-rtcweb-overview (Harald covering all drafts - 15 min)
draft-cbran-rtcweb-protocols
draft-holmberg-rtcweb-ucreqs
draft-rosenberg-rtcweb-framework
discussion 15 min
focus on identifying what are the big architecture decisions that are
needed more than actually debating what they choices we should make.

It was almost too successful in that - in that there were nearly no
questions/controversies, and no really important ones.

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.

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

ZRTP
draft-johnston-rtcweb-media-privacy (Alan J - 5 min)
- focus on topic of are we going to have the "ZRTP or not" debate
5 min discussion

Just a continuation of the previous discussion.

NAT Traversal: 30 minutes
draft-kaufman-rtcweb-traversal (Kaufman 10 min)
20 min discussion

This turned out to be on the idea that you could implement ICE with
only a barebones STUN component in the browser itself, and leaving the
rest to Javascript.
The author was severely challenged on implementability, due to the
need to do fairly exact timing in ICE, and was basically told to go
away and come back with a demonstration that it could be done.
(Discussion continued on the list)

RTP Usage: 30 Minutes
draft-perkins-rtcweb-rtp-usage (Colin - 15 min )
15 min discussion

Lots of heat here. Magnus, as part of the old school of RTP, was
adamant that putting audio and video (and possibly other stuff) in the
same RTP session was a Bad Idea.
Several people claim that the cost of opening multiple UDP ports is
significant, and wanted to avoid it.
Discussion ensued, but little agreement; it seems, however, that it's 
clearly OK to use one RTP session for multiple video streams.

Non audio/video data: 25 min
frame issues (chairs 5 min  )
- draft-holmberg-rtcweb-ucreqs
- draft-cbran-rtcweb-protocols
discussion 20 min
* make sure we agree on requirements
* are focused on unreliable data ?

We'd run out of time at this point. The UDP/DCCP/DTLS stack seems to
be the answer people feel is reasonable for the requirements.
"We can build a reliable channel on top of an unreliable one if we
need to" seemed to be a common mantra.

Call ended after 4 hours and an odd number of minutes.

Received on Tuesday, 14 June 2011 11:22:00 UTC