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

Jim McEachern <> Tue, 04 October 2011 15:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B16321F8CEE for <>; Tue, 4 Oct 2011 08:56:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wBRWMj5VdQ4c for <>; Tue, 4 Oct 2011 08:56:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1D91B21F8CE3 for <>; Tue, 4 Oct 2011 08:56:27 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP; Tue, 04 Oct 2011 08:59:33 PDT
Received: from ([]) by over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Oct 2011 10:59:15 -0500
Received: from ([fe80::81ee:2d58:ca01:fb9a]) by ([fe80::f0b6:4f10:74b0:f8b%15]) with mapi id 14.01.0289.001; Tue, 4 Oct 2011 10:59:15 -0500
From: Jim McEachern <>
To: Randell Jesup <>, "" <>
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: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
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-
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-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Oct 2011 15:56:29 -0000

On Tue, Oct 4, 2011 at 10:43 AM, Randell Jesup <> 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?