Re: [rtcweb] Let's define the purpose of WebRTC

[Randell Jesup <[e-mail]>]

On 11/6/2011 9:01 AM, Tim Panton wrote:
> Almost all of the discussions here in the last few weeks are about interop with existing SIP
> deployments. ( forking,glare, SDP, RTP muxing) The bulk of the use-cases on which that effort is
> based are also around interop with non-browser devices and channels, but the charter
> never mentions legacy interop. It only talks about browser-to-browser and replacing the
> myriad plugins. It also talks about being a platform for innovation, which is now a
> non-goal for the group.

I respectively disagree.  While I (and others) have sat back and let a 
bunch of people argue over that, I assure you that interop has not been 
a major factor in my discussions with other stakeholders or a primary 
use-case for me.  Has interop gotten discussion?  Yes, partly due to 
many of the people arguing here, and partly due to some of those cases 
being tougher, or that interop exposes some tricky edge cases that may 
exist without interop as well.

For example, you mention forking and glare.  Well, I've given very 
non-interop cases of where forking would be useful: contacting someone 
who has 2 desktops, a notebook, a tablet, and a phone all logged into 
the service, or some of the game scenarios, or a very 
non-standard-SIP-like mesh conference using forked invites.  And glare: 
Cullen's classic example of glare is two people talking, browser to 
browser, and one saying "lets add video", and both turning it on.  No 
interop or SIP required for that to cause glare.  And RTP muxing? 
That's to avoid the startup-delay of having to ICE multiple ports (and 
the funny side-effects if they choose different paths).  Yes that does 
add some requirements to think about for interop; that's not subverting 
the charter or drifting from it.

> Iñaki asked a question as to the purpose of WebRTC, so I quoted the charter.
> As I re-read it, I found that we have drifted a _long_ way from those stated goals.
>
> On that basis, I say we have to re-evaluate something - either the charter or what we
> now have. They are (to my mind) incompatible.
>
> As a concrete example - (there are _many_ but to name a current example) - we seem to be
> on the point of dropping the SRTP requirement in order to ease interop with legacy devices.
> How that squares with the charter - or indeed the ITEF's security stance I have no clue.

People have discussed cases where SRTP either doesn't really add to the 
user's security, and if you are interfacing to the PSTN, being forced 
through a media gateway might be merely a HW/$ cost to the service, or 
it might also be a major degrader of the call quality, of the media 
gateway isn't close to either the PSTN gateway or the caller.

These are arguable cases, but for the time being, a number of use-cases 
and possible applications would want to have the option of talking to a 
PSTN gateway, even if that's not the primary use.  That makes it worth 
exploring to see if it's possible while retaining other requirements, 
and not opening the user to bid-down attacks, etc.  Thus far, we don't 
have a great solution or perhaps even a usable one.

For browser-to-browser (webrtc-to-webrtc really), there's much less (if 
any) reason to avoid SRTP.

As for SDES... I don't consider SDES to be secure, especially not in our 
threat model.  The app has access to the keys, and we don't trust the 
app.  It's more secure than no encryption, and it may be better at 
interop, but that's it.  I think I'd oppose SDES use for anything except 
interop cases.

-- 
Randell Jesup
[e-mail]