[rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)])

Harald Alvestrand <harald@alvestrand.no> Wed, 21 September 2011 09:05 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 00FEB21F8C82 for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 02:05:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.845
X-Spam-Status: No, score=-108.845 tagged_above=-999 required=5 tests=[AWL=1.754, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id mmYC6cWv+ez3 for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 02:05:22 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no []) by ietfa.amsl.com (Postfix) with ESMTP id 163CA21F8C88 for <rtcweb@ietf.org>; Wed, 21 Sep 2011 02:05:22 -0700 (PDT)
Received: from localhost (localhost []) by eikenes.alvestrand.no (Postfix) with ESMTP id D838139E0A7 for <rtcweb@ietf.org>; Wed, 21 Sep 2011 11:07:49 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([]) by localhost (eikenes.alvestrand.no []) (amavisd-new, port 10024) with ESMTP id mhbyh8eP1yGD for <rtcweb@ietf.org>; Wed, 21 Sep 2011 11:07:49 +0200 (CEST)
Received: from [] (c213-89-141-213.bredband.comhem.se []) by eikenes.alvestrand.no (Postfix) with ESMTPS id F0B8539E088 for <rtcweb@ietf.org>; Wed, 21 Sep 2011 11:07:48 +0200 (CEST)
Message-ID: <4E79A964.2050007@alvestrand.no>
Date: Wed, 21 Sep 2011 11:07:48 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <CA+9kkMAwnnKKO5+q6ey4Z0QNxax1QF21vVtw8FNsHy_rmfenjQ@mail.gmail.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <CALiegfkTdCAeEdZbXP1Y9L6i4Anjrgf1CG6ZNj35WGoHL3p_Ew@mail.gmail.com> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <CEA0AC9E-6387-4066-95DC-0D70302E80A7@ag-projects.com> <4E77C3EC.9060801@jesup.org> <CAD5OKxtciYxaVpb7b3G9yMg1A97b9dkjkOpppZcSRzS5SAO3+A@mail.gmail.com> <DB86C19C-781C-4FD2-ADE2-D6E1C0EE1D61@ag-projects.com>
In-Reply-To: <DB86C19C-781C-4FD2-ADE2-D6E1C0EE1D61@ag-projects.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)])
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: Wed, 21 Sep 2011 09:05:23 -0000

On 09/20/2011 09:28 AM, Saúl Ibarra Corretgé wrote:
> On Sep 20, 2011, at 12:59 AM, Roman Shpount wrote:
>> Randell,
>> What I fail to understand is in what way would adding signaling to the web browser would  make things easy to build? How is what you are proposing better then 2 or 3 well written samples?
>> On the other hand, if you decide to build such simple signaling interface, depending on what use case you are trying to address you will end up with very different libraries. You have to decide how complex you want to make this library on the server vs the client side. You will need to decide if the purpose of this library is to simplify browser-to-browser or browser-to-PSTN calls. There is going to be a large number of very complex decisions none of which have obvious answers and will greatly affect the overall library design.
>> Most importantly, I think this is a misconception that you can build something that can be developed in 20 lines or less and be useful. Real-time communication is order of magnitude more complex then most of the web related applications. You need to deal with multiple event sources, deal with event collisions, negotiation failures, call state machines. And this is what required for the basic call setups. Once you start dealing with transfers, conferences, call status monitoring, things become even more complex. It is almost impossible to develop something that is simple to use that serves more then one or two specific use cases. If we try to invent something like this we might never finish.
> +1.
> If we add some signaling protocol to the browser to ease web developers then someone might say "why don't we also add X, Y and Z". The browser only needs the media plane, the signaling can be elsewhere, and it's far better to have it elsewhere.
> As Roman pointed out, RTC applications are not something that can nor should be done in 20 lines of JS. It's just complex. If people want to make simple apps they can build a simple JS library using an invented simple protocol. But RTCWeb shouldn't encourage this IMHO.
Let me just say that I totally disagree on this point.

The developers of applications that need audio and video capabilities 
are not RTC developers. Their main focus and main skill set will lie 

In a little more than 20 lines of code, it is possible to set up a call 
using a variant form of the existing W3C API. I know, I have seen the 
code. Other examples (in a slightly different variant) are part of the 
Ericsson demo.
What's perhaps more important is that none of those 20+ lines mention 
anything about codecs, bit rates, congestion control or any of the 
numerous other issues we've been hashing out.

With the API we support, simple things MUST be simple. Complex things 
must be possible.