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

[Igor Faynberg <[e-mail]>]

I am 100% with Randell.  (Incidentally, my idea of "minimal SIP" has 
been that the browser keeps the SIP state machine while receiving and 
sending SIP messages, with parsing left to application: the outbound 
parameters are supplied--and the inbound ones interpreted--by the JS 
application. In this way, pretty much all versions of SIP can be 
accomodated, while none of them has to be supported by the browser.)

On a different topic, I am confused by the very name of this thread, as 
well as the "was" thread that it replaced. I thought that RTCWeb was 
about "packaging" the existing protocols, not inventing new ones...

Igor

On 9/19/2011 9:53 AM, Randell Jesup wrote:
> ...
> I lean towards a proposal I made a week or two ago; to allow full 
> access (which allows
> user-written JS signalling libraries) but provide minimal SIP+O/A as 
> an option within
> the browser.  This could be a JS library, but the primary users of 
> this would be the
> "little guys" who just want simple setup of media streams, and they're 
> most likely to
> never update, while browsers are updated frequently.
>
> ...
> That's entirely available to the application; they can use their own 
> if they wish.
> And while I suggest a simple SIP set be included, if we were certain a 
> "standard" JS
> lib were freely available and solid enough, that would make the 
> argument stronger for
> a JS lib.
>
> ....