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

Roman Shpount <roman@telurix.com> Thu, 22 September 2011 19:04 UTC

Return-Path: <roman@telurix.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 1717A1F0C63 for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 12:04:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.763
X-Spam-Level:
X-Spam-Status: No, score=-2.763 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 yKAMrnrbdxmx for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 12:04:43 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCC11F0C3C for <rtcweb@ietf.org>; Thu, 22 Sep 2011 12:04:43 -0700 (PDT)
Received: by iaby26 with SMTP id y26so3887677iab.31 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 12:07:15 -0700 (PDT)
Received: by 10.43.135.10 with SMTP id ie10mr2866041icc.91.1316718435223; Thu, 22 Sep 2011 12:07:15 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id ee29sm12262977ibb.9.2011.09.22.12.07.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 12:07:14 -0700 (PDT)
Received: by yxt33 with SMTP id 33so2681253yxt.31 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 12:07:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.36.232 with SMTP id t8mr5922353pbj.54.1316718432937; Thu, 22 Sep 2011 12:07:12 -0700 (PDT)
Received: by 10.68.55.39 with HTTP; Thu, 22 Sep 2011 12:07:12 -0700 (PDT)
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0F58@sonusinmail02.sonusnet.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> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <CA+9kkMAwnnKKO5+q6ey4Z0QNxax1QF21vVtw8FNsHy_rmfenjQ@mail.gmail.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <CALiegfkTdCAeEdZbXP1Y9L6i4Anjrgf1CG6ZNj35WGoHL3p_Ew@mail.gmail.com> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <CEA0AC9E-6387-4066-95DC-0D70302E80A7@ag-projects.com> <4E77C3EC.9060801@jesup.org> <CAD5OKxtciYxaVpb7b3G9yMg1A97b9dkjkOpppZcSRzS5SAO3+A@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> <C55E752E-18FD-402C-A7DE-1627813B3F6D@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF510F0F58@sonusinmail02.sonusnet.com>
Date: Thu, 22 Sep 2011 15:07:12 -0400
Message-ID: <CAD5OKxspOVZz1Q7DsEmLppt7AWROodksCG-eFjM+zXGxTwuVtQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Ravindran Parthasarathi <pravindran@sonusnet.com>
Content-Type: multipart/alternative; boundary=bcaec520e81776e6ae04ad8c6677
Cc: Randell Jesup <randell-ietf@jesup.org>, rtcweb@ietf.org
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: Aboutdefining 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: Thu, 22 Sep 2011 19:04:44 -0000

Partha,

I would consider the fact that each server has its own JS library a huge
advantage -- each server needs to interop with its own library. If we want
to add extensions, we can add them in the server and JS, and not worry about
creating a new standard and going through an interop.
_____________
Roman Shpount


On Thu, Sep 22, 2011 at 2:22 PM, Ravindran Parthasarathi <
pravindran@sonusnet.com>; wrote:

> Hadriel,
>
> Please read inline.
>
> Thanks
> Partha
>
> >-----Original Message-----
> >From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]
> >Sent: Tuesday, September 20, 2011 11:29 AM
> >To: Ravindran Parthasarathi
> >Cc: Roman Shpount; Randell Jesup; <rtcweb@ietf.org>;
> >Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE:
> >Aboutdefining a signaling protocol for WebRTC (or not)]
> >
> >
> >On Sep 20, 2011, at 1:27 AM, Ravindran Parthasarathi wrote:
> >
> >> I agree with you in case you wish to have all class 5 services in
> this
> >architecture. In the web game server wherein the basic call has to be
> >established between two parties, this complexity is not required.
> >
> >OK, let's take the game example... only 2-player games would be able to
> >use a simple rtcweb-SIP agent.  Anything more than 2-player would want
> >to use the multi-party "conferencing" model of rtcweb, which can't even
> >be signaled with SIP today as far as I can tell. (not that I've thought
> >about it too much, but I can't see how it would without some changes to
> >SIP)
> >
> <partha> In fact rtcweb client shall acts as conference un-aware client
> in the conference model and game server acts as conference server. I
> have worked in 3-party conference using SIP in the endpoint but I have
> never seen endpoint acts as conference server. So, I may be missing
> something here </partha>
>
> >
> >
> >> One of the main aim of the RTCWeb default signaling protocol is to
> >make two party real-time communication easy with less development
> effort
> >for any web developer.
> >
> >Why doesn't using JS libraries provide that ease of development,
> >assuming there's a good "signaling agent" JS library for whatever
> >communication model the deployer wants/needs?  If there isn't a good JS
> >library, then one would wonder why we think all browsers will have a
> >good built-in signaling agent instead.
> >
> <partha>The disadvantage with JS is that each server has to provide its
> own instance of JS library. It may be possible to have plugin instead of
> JS but it will defeat the purpose of RTCWeb charter. </partha>
>
> >-hadriel
> >
> >
> >
> >
>
>