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

Randell Jesup <randell-ietf@jesup.org> Tue, 20 September 2011 06:40 UTC

Return-Path: <randell-ietf@jesup.org>
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 2EF4811E8073 for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 23:40:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.615
X-Spam-Level:
X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 QXTRZ3odCrYI for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 23:40:24 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id C05DD11E8083 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 23:40:24 -0700 (PDT)
Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1R5u2b-0007ve-5r for rtcweb@ietf.org; Tue, 20 Sep 2011 01:42:49 -0500
Message-ID: <4E78351C.20103@jesup.org>
Date: Tue, 20 Sep 2011 02:39:24 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.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>
In-Reply-To: <C55E752E-18FD-402C-A7DE-1627813B3F6D@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
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, 20 Sep 2011 06:40:26 -0000

On 9/20/2011 1:59 AM, Hadriel Kaplan wrote:
> 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)

It should be easy - either as N-1 2-person calls to the person hosting the game, or
N calls via a central server (equivalent to a mixer), or as a full mesh of direct
calls (3 2-person calls for a 3-person game, 6 for a 4-person game, etc), or even
sparse meshes (makes sense in a game where not all players are 'near' each other).

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

Well, there are a lot more available C/C++ SIP libraries than JS SIP libraries
(I've heard of one non-open-I-assume one under development), to start with.
The same applies to XMPP (one known implementation - may not be free), etc.  Let
alone well-tested and used JS SIP/etc libraries.  Yes, we could develop them.  I
don't see that as being easier than developing the equivalent in C++, assuming
you decided to start both efforts from scratch - and one may well not have to
start from scratch.


-- 
Randell Jesup
randell-ietf@jesup.org