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

[Hadriel Kaplan <[e-mail]>]

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)

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.

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)

-hadriel