Re: [rtcweb] Usecases for innovation.

Wolfgang Beck <wolfgang.beck01@googlemail.com> Thu, 03 November 2011 08:18 UTC

Return-Path: <wolfgang.beck01@googlemail.com>
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 2620D11E80DC for <rtcweb@ietfa.amsl.com>; Thu, 3 Nov 2011 01:18:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.641
X-Spam-Level:
X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1]
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 G22GX99uSPLG for <rtcweb@ietfa.amsl.com>; Thu, 3 Nov 2011 01:18:43 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5150A11E80C9 for <rtcweb@ietf.org>; Thu, 3 Nov 2011 01:18:43 -0700 (PDT)
Received: by faas12 with SMTP id s12so1507729faa.31 for <rtcweb@ietf.org>; Thu, 03 Nov 2011 01:18:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HTFAXbcZWv4SlfkyfHPDpAP32lnClLuIDdzPexiRqM8=; b=dkpzHA4mX4T20yg/QNjH7XmIEi9GTDfES9DsLxEGv77jYl1NdShcIFfU2nAFwEX+Oi b21PT6hgWEjcf6XA5uzx9R8r4DQ+KxnSQe917kb7Mkd8GHicLqrX8XbO6ZzpzU659yoO zvbsxKOSwcvtn1tx/DsdaoXvaZDtAXdV1t1m4=
MIME-Version: 1.0
Received: by 10.223.58.134 with SMTP id g6mr983825fah.0.1320308322254; Thu, 03 Nov 2011 01:18:42 -0700 (PDT)
Received: by 10.152.18.197 with HTTP; Thu, 3 Nov 2011 01:18:41 -0700 (PDT)
In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6CD0F1@inba-mail01.sonusnet.com>
References: <084BA945-E5AB-480D-8608-1340E8C8125F@phonefromhere.com> <CALiegfkrPeBRG=URtM7=xmVHgHrQkhf9bGBL1JUE2h9ofbj=OQ@mail.gmail.com> <CAAJUQMjqxfLmOogr1hrSceOba=nrMpfXQ+4yn_yH=+tOxmcZKw@mail.gmail.com> <4EB1840D.6070405@jesup.org> <387F9047F55E8C42850AD6B3A7A03C6CD0F1@inba-mail01.sonusnet.com>
Date: Thu, 03 Nov 2011 09:18:41 +0100
Message-ID: <CAAJUQMjNKpkr9OQK4ow=8CFETo8ezg=nKdG9WxL1fUJr=3=wpw@mail.gmail.com>
From: Wolfgang Beck <wolfgang.beck01@googlemail.com>
To: Ravindran Parthasarathi <pravindran@sonusnet.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Usecases for innovation.
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: Thu, 03 Nov 2011 08:18:44 -0000

On Thu, Nov 3, 2011 at 2:12 AM, Ravindran Parthasarathi
<pravindran@sonusnet.com> wrote:
> IMO, low level API are nothing but exposing (secured) RTP library API from browser to web developer. Of course, it helps in case the web development focused on special web-application like
>
> 1) Proprietary SDP next generation mechanism (if ROAP proposal is accepted as default API mechanism) implementation. Of course, lot of flames on SDP already and alternative proposal for the specific deployment is possible.
> 2) Signaling mechanism like H.245 (Media description of H.323) which does not direct well fit with SDP
> 3) RTP specific enhancement services like adding proprietary RTCP extensions.
>
The API must hit the right level. If it is too low-level, security
will be hard to achieve. If it is too high-level, it can't be used for
anything new. What worries me about ROAP is this protocol stack:

SDP
ROAP
proprietary JS client protocol
HTTP
...
SDP+ROAP may require a complexity of the JS client protocol that is
not really needed by the actual application.
However, running code wins. Maybe this isn't a problem.

> Thanks to Randell for sharing his experience and burning issue in WebRTC. I understand that security & privacy should
> be the main focus of this WG.
We have less security issues if both parties are using the same
server. With trapezoid style interconnection/federation security
relevant information can get lost. You can get into transit scenarios
where all your signaling is routed through providers that you don't
know. If Facebook or Google became big hubs to interconnect small
RTCWEB providers, how would they use this signaling information?

>
> The proprietary signaling helps for time to market but provides the manageability & scalability issues in the long run.
FYI, here's one of the presentations that motivated RTCWEB in the first place:
'The End Of Application Protocol Standardization (?)'
http://www.ietf.org/proceedings/80/slides/plenaryt-5.pdf


Wolfgang Beck