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 07:46 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 D968521F85AA for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 00:46:59 -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 AeqdfsWHqMB5 for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 00:46:59 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 486F621F84DB for <rtcweb@ietf.org>; Tue, 20 Sep 2011 00:46:59 -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 1R5v52-0007JZ-5g for rtcweb@ietf.org; Tue, 20 Sep 2011 02:49:24 -0500
Message-ID: <4E7844B7.8000005@jesup.org>
Date: Tue, 20 Sep 2011 03:45:59 -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><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> <4E78351C.20103@jesup.org> <E4C646E9-44E5-4EBE-9AA1-D97500FAEE66@acmepacket.com>
In-Reply-To: <E4C646E9-44E5-4EBE-9AA1-D97500FAEE66@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 07:47:00 -0000

On 9/20/2011 3:19 AM, Hadriel Kaplan wrote:
> On Sep 20, 2011, at 2:39 AM, Randell Jesup wrote:
>
>> On 9/20/2011 1:59 AM, Hadriel Kaplan wrote:
>>> 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).
> Can't do N-1 2-person calls to the person hosting the game, because rtcweb doesn't support "full" mixing in the browser, only local media mixing. (ie, everyone will hear the person hosting the game, and the person hosting the game will hear everyone else, but the rest won't hear each other)

Ok; I hadn't looked at what controls we're giving the JS app (mostly focusing on IETF
level stuff).  W3C issue.  It would be nice if an app could set up a bridge; I'm
a little surprised it can't.


> Calls via a central media server require a central media server, which kinda defeats the "easy" concept and using our shiny new toy of rtcweb.

I never said all uses are easy.   Simple uses are easy (like 2-person games), complex uses
are possible (and as easy as we can do).  I'd like to avoid a separate mixer, though,
I agree.


> A full mesh is what *should* happen, but SIP/SDP can't do it, afaict.  It would treat them either as independent calls even at a media layer, or as a full-mixer conference focus model.  The closest thing we have would probably be the Join header, but I believe it's semantics is to join as a full mixer conf call.  Isn't this full-mesh media-forking thing actually a new semantic for SIP/SDP?  (it's hard to believe with 100+ drafts/RFCs this scenario hasn't already been addressed in SIP - I must be just having a memory leak)

SIP has been very focused on device<->server interaction, not device<->device.  However:
note that we have an app that knows why it has these calls in place; we're not defining an
abstract, portable protocol use here.

It would be worthwhile to work out the details of these 'mesh' and ad-hoc (bridged) conference models and if they fit into the security model, since they enable (and reduce the cost of) a
number of important uses.


-- 
Randell Jesup
randell-ietf@jesup.org