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