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

Matthew Kaufman <matthew.kaufman@skype.net> Tue, 15 November 2011 00:43 UTC

Return-Path: <matthew.kaufman@skype.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D23621F8E45 for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 16:43:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scZg5V7GAVHZ for <rtcweb@ietfa.amsl.com>; Mon, 14 Nov 2011 16:43:01 -0800 (PST)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id AE8B221F8E3E for <rtcweb@ietf.org>; Mon, 14 Nov 2011 16:43:00 -0800 (PST)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 0AD6C7FE; Tue, 15 Nov 2011 01:42:59 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=+L4MoEPnfHaSpg tZD7iZ5D6XZbQ=; b=tMbSPgPlzEaGmEGCKczcVkIP4LwXwu5Ol9sHXQeWXBKy7s gomIv4k+rZuuyZgfCNGfxGIGVOf0gqkSN6ZPl3FTT7MFFrN5fpu7fSGSPcthVaax tfsTiZ15PiKb3LYNbkrDigqmq5ndIrJMmagsCoJDGsEKICOGIF+ax75Rb6R2A=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=VvE7MUSPshhQZbnSiTYujV /IM5gt0LuJPWT6DnbxYcbdMSHek+fIf9iZ1N1fH+Ykd6uH/6T3VY4ULIHKD2g5yw xQ9z6xCBAbd19PI0OBlxJLyFCFQm4jVe2DxNGS232/QFOlh2GGUOyL5UJfQu6UQs AlBtOdmkkXahfHcR4tMIY=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 093AC7EB; Tue, 15 Nov 2011 01:42:59 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id D8A7F1672681; Tue, 15 Nov 2011 01:42:58 +0100 (CET)
X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net
Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnEfclMh4slS; Tue, 15 Nov 2011 01:42:57 +0100 (CET)
Received: from dhcp-103b.meeting.ietf.org (dhcp-103b.meeting.ietf.org [130.129.16.59]) by zimbra.skype.net (Postfix) with ESMTPSA id 635EB3506F2C; Tue, 15 Nov 2011 01:42:56 +0100 (CET)
Message-ID: <4EC1B58E.7060206@skype.net>
Date: Tue, 15 Nov 2011 08:42:54 +0800
From: Matthew Kaufman <matthew.kaufman@skype.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Roman Shpount <roman@telurix.com>
References: <CALiegfkVNVAs_MyU_-4koA4zRwSn1-FwLjY9g_oZVkhi9rSK5Q@mail.gmail.com> <CAD5OKxt=k_Mon_GMs1w-bGMgpk12h6ZQ=FkoRVsTp4271iMSLA@mail.gmail.com> <CABcZeBNMTgwH-R_jd-AiEJ8tELTeFMNm-bAJohRg2RxD5e+kZQ@mail.gmail.com> <CAD6AjGRBmrAqB3CEWxtaXnryPA5App13S2jJPAt+7HwWZsQFzA@mail.gmail.com> <CABcZeBNtoizuRymVMxF4CdiLu1Nju63C0xkWJHjoarpxeLXjyA@mail.gmail.com> <CALiegfk=oJJ20GhKQBKA7aspHhUyQ-s+DR-qSi4XV455Nj718w@mail.gmail.com> <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> <CAD5OKxvN5YY13UGQeZGL-znzw9UR_2oXS_RV8FQx1MW8hqWzqg@mail.gmail.com>
In-Reply-To: <CAD5OKxvN5YY13UGQeZGL-znzw9UR_2oXS_RV8FQx1MW8hqWzqg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Let's define the purpose of WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Nov 2011 00:43:02 -0000

On 11/7/11 11:58 AM, Roman Shpount wrote:
>
> 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.

Or not.

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

The best possible future-proof system would be one that exposes 
low-level access to the primitives needed to construct anything. That is 
not, unfortunately, what is currently proposed.

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

Do you want *your* browser to be able to switch to plain RTP for the 
call you're making from a place with an unsecured wi-fi network (as 
essentially all are at this point, given the ease of cracking the 
typical schemes used for wireless security these days) ?

I don't. Even though I do agree that there might be external reasons why 
service providers might want the browser to have that ability.

Matthew Kaufman