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

Neil Stratford <> Wed, 09 November 2011 12:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80F5621F8B54 for <>; Wed, 9 Nov 2011 04:53:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.512
X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C4dmZhCBWq1g for <>; Wed, 9 Nov 2011 04:53:17 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7480221F8B4E for <>; Wed, 9 Nov 2011 04:53:17 -0800 (PST)
Received: by ywt2 with SMTP id 2so2031918ywt.31 for <>; Wed, 09 Nov 2011 04:53:16 -0800 (PST)
MIME-Version: 1.0
Received: by with SMTP id pa3mr2351327igc.12.1320843195496; Wed, 09 Nov 2011 04:53:15 -0800 (PST)
Received: by with HTTP; Wed, 9 Nov 2011 04:53:15 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Wed, 9 Nov 2011 12:53:15 +0000
X-Google-Sender-Auth: dcMM3tcTaRyq6SnVY5jBkO0Lpik
Message-ID: <>
From: Neil Stratford <>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <>
Content-Type: multipart/alternative; boundary=14dae934057778b83204b14cc5cc
Subject: Re: [rtcweb] Let's define the purpose of WebRTC
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Nov 2011 12:53:18 -0000

Wouldn't it be great if we had an opportunity to start from a clean sheet,
carry no legacy baggage and design a platform for the future? Isn't that
the opportunity presented by WebRTC?

It will always be possible to gateway to legacy SIP devices, even if we
have to bridge the media. It seems there is far too much focus on interop
and not enough on what is best for the WebRTC platform.


On Wed, Nov 9, 2011 at 11:58 AM, Iñaki Baz Castillo <> wrote:

> 2011/11/9 Muthu Arul Mozhi Perumal (mperumal) <>om>:
> > I am thinking we could burn SRTP into the browser such that the decision
> of whether or not to use SRTP vests solely with the browser.
> The "browser" cannot decide that. Probably you mean the user, that
> person that in 99.999% of cases does not know what "encryption" or
> "SRTP" is, and in 85% of cases does not matter about security.
> > If a WebRTC browser is exchanging media with another WebRTC browser they
> always do SRTP/SRTCP.
> The browser has NO way to determine whether it's exchanging media with
> another browser or not. And what you state is that, in case the peer
> does not annouce support for SRTP then the browser should downgrade
> security to plain RTP. The user (web visitor) has no way to know
> whether the WebRTC application will contact a WebRTC browser or
> another device at the media plane.
> > If either side isn't WebRTC compliant they end up with RTP/RTCP.
> So no security. Bad.
> > This way we don't need to trust the JS, instead trust only the browser.
> You mean the user.
> > We can also interoperate with legacy devices without taxing them.
> Sorry, but WebRTC is about "realtime communications for the Web",
> rather than "SIP business coming to the Web". SIP uses RTP, including
> RFC's about SRTP. If you want SIP interoperability with a WebRTC
> device, then make your work as vendor and add security to your SIP
> devices rather than asking no-security for WebRTC.
> Please, take a look to XMPP/Jingle !!  They implement SRTP and ICE
> from the beginning!! *Do* your homeworks as SIP vendor.
> This is a problem of SIP vendors/telcos, this is not a problem of
> WebRTC. You should implement SRTP in your legacy and non-secure SIP
> devices and make them valid for communication across the open Internet
> in which security is a MUST (Internet is not a telco wallen garden).
> The main purpose of WebRTC is not to interoperate with insecure
> devices, do we all agree here?
> I don't support this kind of arguments in favour of non mandating SRTP.
> PS: Somebody could argue that, in the Web, neither HTTPS or
> WebSocket+TLS is a MUST but optional per website, so why to make SRTP
> mandatory? That would be a very different argument I could understand
> and discuss about. But forcing a *new* specification to be insecure
> just to allow interoperability with non-secure devices is not welcome.
> WebRTC is for the Web, not for SIP.
> PS: This kind of discussions give the reason to recent comments like
> the one from Tim Parton. This WG is too much focused on SIP
> vendors/telcos which are not fully interested in RTC communications in
> pure Web/Internet environments, but in making the web browsers a new
> SIP phone for integratting them into their telco business. Bad.
> PS: I'm also interested in interoperability between WebRTC browsers
> and SIP devices (as much as you), but I assume that just a few SIP
> devices MUST be able to interop with WebRTC (those that have done
> their homeworks by implementing SRTP and ICE).
> And those discussions are becoming very boring. There are not new
> arguments at all. It seems than within next weeks/months, SIP
> telcos/vendors will continue requesting not mandatory SRTP just to
> facilitate their business without investing in improving their
> non-secure devices. This is a no-go.
> Regards.
> --
> Iñaki Baz Castillo
> <>
> _______________________________________________
> rtcweb mailing list