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

Bernard Aboba <bernard_aboba@hotmail.com> Tue, 04 October 2011 18:16 UTC

Return-Path: <bernard_aboba@hotmail.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 97EEB21F8E6C for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 11:16:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.147
X-Spam-Level:
X-Spam-Status: No, score=-102.147 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 8nJGp-R8kti2 for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 11:16:18 -0700 (PDT)
Received: from blu0-omc4-s29.blu0.hotmail.com (blu0-omc4-s29.blu0.hotmail.com [65.55.111.168]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC1C21F8E5C for <rtcweb@ietf.org>; Tue, 4 Oct 2011 11:16:17 -0700 (PDT)
Received: from BLU152-W4 ([65.55.111.137]) by blu0-omc4-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Oct 2011 11:19:23 -0700
Message-ID: <BLU152-W476B3866CE31803056E3C93FB0@phx.gbl>
Content-Type: multipart/alternative; boundary="_54bf6827-253a-4185-a115-796ae25e567f_"
X-Originating-IP: [98.237.179.165]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <randell-ietf@jesup.org>, <rtcweb@ietf.org>
Date: Tue, 4 Oct 2011 11:19:22 -0700
Importance: Normal
In-Reply-To: <4E8B1B86.2080805@jesup.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>
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Oct 2011 18:19:23.0316 (UTC) FILETIME=[246AFF40:01CC82C2]
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: Tue, 04 Oct 2011 18:16:18 -0000

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


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