IETF Logo Mail Archive

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

Jim McEachern <jim.mceachern@genband.com> Tue, 04 October 2011 15:56 UTC

Return-Path: <jim.mceachern@genband.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 7B16321F8CEE for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 08:56:29 -0700 (PDT)
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 wBRWMj5VdQ4c for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 08:56:28 -0700 (PDT)
Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 1D91B21F8CE3 for <rtcweb@ietf.org>; Tue, 4 Oct 2011 08:56:27 -0700 (PDT)
Received: from mail.genband.com ([63.149.188.88]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Tue, 04 Oct 2011 08:59:33 PDT
Received: from owa.genband.com ([172.16.21.98]) by mail.genband.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Oct 2011 10:59:15 -0500
Received: from GBPLMAIL03.genband.com ([fe80::81ee:2d58:ca01:fb9a]) by gbex02.genband.com ([fe80::f0b6:4f10:74b0:f8b%15]) with mapi id 14.01.0289.001; Tue, 4 Oct 2011 10:59:15 -0500
From: Jim McEachern <jim.mceachern@genband.com>
To: Randell Jesup <randell-ietf@jesup.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]
Thread-Index: AQHMgqSHFvdI2T8mjE663dxgldXgIJVsU7ag
Date: Tue, 04 Oct 2011 15:59:14 +0000
Message-ID: <8584590C8D7DD141AA96D01920FC6C698C8A84ED@gbplmail03.genband.com>
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>
In-Reply-To: <4E8B1B86.2080805@jesup.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [99.242.72.70]
Content-Type: multipart/mixed; boundary="_002_8584590C8D7DD141AA96D01920FC6C698C8A84EDgbplmail03genba_"
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Oct 2011 15:59:15.0789 (UTC) FILETIME=[91242FD0:01CC82AE]
X-TM-AS-Product-Ver: SMEX-8.0.0.4160-6.500.1024-18426.000
X-TM-AS-Result: No--15.265600-5.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
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 15:56:29 -0000

On Tue, Oct 4, 2011 at 10:43 AM, Randell Jesup <randell-ietf@jesup.org> wrote:

> I have a different argument: I want it to be *easy* for a website
> author/app developer to add audio or video for their users.   The
> developers aren't experts on glare, forking, the intricacies of getting offer-
> answer (or whatever) right, ad nauseum.  If you ask them to
> *design* their own protocol, they'll make a ton of 'rookie' mistakes.
> And for added fun, they'll likely never correct them and in many cases never
> understand why the bug is occasionally reported by their users.
> 
> A random example is forking - forking will happen (forward call to all the
> devices the person logged in under) , and handling forking well requires
> some thought and experience.
> 

The problem with this argument is that it involves complex functionality that would not be covered by basic SIP in the browser. 
Are you proposing that the full SIP stack, with support for forking, early media, etc. be built into all browsers?  If yes, then we are already at the bottom of the "slippery slope" that people fear. 
 If no, then the app developer will still need to deal with this complexity.

Am I missing something?

Jim

v2.23.0 | Report a Bug | By Email