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

Roman Shpount <> Mon, 07 November 2011 03:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C5A6A1F0C35 for <>; Sun, 6 Nov 2011 19:58:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gbDArltRhChs for <>; Sun, 6 Nov 2011 19:58:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2AD601F0C34 for <>; Sun, 6 Nov 2011 19:58:49 -0800 (PST)
Received: by iaeo4 with SMTP id o4so6865182iae.31 for <>; Sun, 06 Nov 2011 19:58:48 -0800 (PST)
Received: by with SMTP id o5mr43342650ict.34.1320638328739; Sun, 06 Nov 2011 19:58:48 -0800 (PST)
Received: from ( []) by with ESMTPS id jm11sm36290628ibb.1.2011. (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 Nov 2011 19:58:47 -0800 (PST)
Received: by iaeo4 with SMTP id o4so6865141iae.31 for <>; Sun, 06 Nov 2011 19:58:46 -0800 (PST)
MIME-Version: 1.0
Received: by with SMTP id y20mr2159131ibh.11.1320638326787; Sun, 06 Nov 2011 19:58:46 -0800 (PST)
Received: by with HTTP; Sun, 6 Nov 2011 19:58:46 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Sun, 6 Nov 2011 22:58:46 -0500
Message-ID: <>
From: Roman Shpount <>
To: Tim Panton <>
Content-Type: multipart/alternative; boundary=000e0cd4b3f0584f9204b11d1266
Cc: "<>" <>
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: Mon, 07 Nov 2011 03:58:49 -0000

On Sun, Nov 6, 2011 at 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.
First of all, this is not about interop. We have a fairly significant
experience regarding real-time communications, but for many reasons most of
this experience is related to SIP. Based on this, experience we know that
there are issues, such as glare, media forking, media negotiation, support
of future codecs, that need to be addressed. If we are asking about
scenarios which have not been relevant to your particular "innovative"
application, it does not mean that other users of WebRTC will not encounter
it. This is all about creating the best possible future proof system we can.

Second, the reason I raised my comment about SRTP was exactly in order to
support future applications that we are not aware about now. I do not see a
why we should mandate something without a good reason. The more control we
will give to developer, the more applications it would be possible to
build. I would strongly support required to implement, but not required to
use model for SRTP. This way SRTP is available to the application developer
but not something they must use. There are places where communications are
illegal, unless they can be intercepted by the "big brother". Things like
Skype are illegal there for this exact reason. I would not argue if this
situation is appropriate, legal, or moral, but it exists. It would be
better that WebRTC would be able to operate in environments like this.
Roman Shpount