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

[Randell Jesup <[e-mail]>]

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
[e-mail]