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

"Ravindran Parthasarathi" <pravindran@sonusnet.com> Wed, 05 October 2011 17:47 UTC

Return-Path: <pravindran@sonusnet.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 7106411E8081 for <rtcweb@ietfa.amsl.com>; Wed, 5 Oct 2011 10:47:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.493
X-Spam-Level:
X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 LipBA2eSxyx7 for <rtcweb@ietfa.amsl.com>; Wed, 5 Oct 2011 10:47:24 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id D1C0A21F8B37 for <rtcweb@ietf.org>; Wed, 5 Oct 2011 10:47:23 -0700 (PDT)
Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p95Hp2Hn011762; Wed, 5 Oct 2011 13:51:02 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 13:49:36 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 5 Oct 2011 23:19:19 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F14CD@sonusinmail02.sonusnet.com>
In-Reply-To: <8584590C8D7DD141AA96D01920FC6C698C8A84ED@gbplmail03.genband.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE:About defining a signaling protocol for WebRTC (or not)]
Thread-Index: AQHMgqSHFvdI2T8mjE663dxgldXgIJVsU7aggAG03IA=
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> <8584590C8D7DD141AA96D01920FC6C698C8A84ED@gbplmail03.genband.com>
From: "Ravindran Parthasarathi" <pravindran@sonusnet.com>
To: "Jim McEachern" <jim.mceachern@genband.com>, "Randell Jesup" <randell-ietf@jesup.org>, <rtcweb@ietf.org>
X-OriginalArrivalTime: 05 Oct 2011 17:49:36.0515 (UTC) FILETIME=[25D08D30:01CC8387]
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 17:47:24 -0000

Hi Jim,

For the given RTCWeb basic communication, if some other better signaling
protocol exists, we will adopt for it. 

Thanks
Partha

>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
Behalf
>Of Jim McEachern
>Sent: Tuesday, October 04, 2011 9:29 PM
>To: Randell Jesup; rtcweb@ietf.org
>Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE:About
>defining a signaling protocol for WebRTC (or not)]
>
>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