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

Randell Jesup <randell-ietf@jesup.org> Wed, 05 October 2011 04:07 UTC

Return-Path: <randell-ietf@jesup.org>
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 6B66321F86AA for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 21:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.572
X-Spam-Level:
X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599]
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 FLlwxx67D28R for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 21:07:10 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id C51B821F869E for <rtcweb@ietf.org>; Tue, 4 Oct 2011 21:07:10 -0700 (PDT)
Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1RBIoD-0002mp-5S for rtcweb@ietf.org; Tue, 04 Oct 2011 23:10:17 -0500
Message-ID: <4E8BD7B8.3080408@jesup.org>
Date: Wed, 05 Oct 2011 00:06:16 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
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>, <2E239D6FCD033C4BAF15F386A979BF510F137B@sonusinmail02.sonusnet.com>, <226C9800-9791-465A-B519-40935E2D135F@phonefromhere.com>, <4E8B1B86.2080805@jesup.org> <BLU152-W476B3866CE31803056E3C93FB0@phx.gbl>
In-Reply-To: <BLU152-W476B3866CE31803056E3C93FB0@phx.gbl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] 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, 05 Oct 2011 04:07:11 -0000

On 10/4/2011 2:19 PM, Bernard Aboba wrote:
> [BA] I think this is the main point. If we finish RTCWEB 1.0
> expeditiously, this will in all likelihood
> spawn a number of browser-independent signaling libraries, as well as
> developing a wealth of experience
> with the limitations of RFCWEB 1.0, to inform future efforts.
>
> The alternative is to "load up the camel" until it collapses under the
> weight of (largely irrelevant) use
> cases. Since the realtime web has been around for over a decade, we have
> a pretty good idea of what
> native realtime capabilities would be used for -- and PSTN connectivity
> has never been high on the list.

Well, I'd say that's mildly debatable - VoIP companies chew a lot of 
bandwidth on the net, and it's almost all going to the PSTN - though 
it's not in browsers generally.  Skype completes a lot of on-net calls - 
but they make a lot of money (almost all?) from PSTN calls.

That said, I don't consider the Skypes of the world a problem here - 
they can and will roll their own.  Same for PBX vendors I suppose, 
though they'll try to leverage more existing examples.

I think there will be a lot of small-to-medium users adding chat, 
building games, etc, who care little or not at all about the PSTN. 
Those are the ones who I worry about; they wouldn't realize there are 
issues with glare (totally ignoring PSTN) or that forking can be 
complex.  They want a simple, one-stop-shopping solution for adding 
voice/video/data to their sites and games, etc.

Yes, people will build JS apps to provide that.  I'm worried about the 
quality of those apps, and that the likely model will be the author 
downloads a random version when they develop their service, and they 
never update it.  This is a real problem; it is a real problem today 
with other JS modules.

Does this mean we *have* to bake in some sort of signalling?  No, it 
doesn't.  It is an _argument_ for providing some type of signalling as a 
baseline default; or if not, then for starting a project to provide that.

Note that I said "baseline".  I did *not* say "can handle all the 
intricacies of the PSTN well".  It could be something far simpler than
SIP or XMPP, etc, or it could be a very dumbed-down version of one. 
These small users (as noted) need something to provide the basics, and 
to handle certain complexities that simply arise from normal usage 
patterns and features (like forking).  Being able to access the PSTN at 
all using this would be a plus - but it would not be critical in my mind.

And, as I mentioned, it could be external JS - but then it has be more 
solid to start with.  For these simple uses - say chat with other users 
on someones special-interest website, 2 and multiplayer gaming, etc - we 
should try to pull together the minimum things any app/service developer 
would need to be prepared for.  I think any service that allows someone 
to log in from multiple devices has to handle forking in some manner. 
Glare is always possible.  What else?  I'd like to see simple 
conferencing.  Perhaps the minimum is simple enough that it makes more 
sense to develop a new, very simple signalling JS module, and use it in 
examples. This would limit the downside from not updating.

The advantage of basing it on something known is that the basics of all 
these protocols are well-understood.

I'll paraphrase Harald (and many others in other contexts): make simple 
things simple, make complex things possible.

>  > Yes, this is critical. We need to finish it. I'd rather have it
>  > finished and a strong project to build a "standard" external JS library
>  > under way than to have the whole thing wait. But if I had my druthers
>  > (what the bleep are those, anyways?) I'd have an optional signaling
>  > protocol available.

-- 
Randell Jesup
randell-ietf@jesup.org