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

[Saúl Ibarra Corretgé <[e-mail]>]

Hi,

[snip]

> My point is that the default signaling protocol has to be supported in RTCWeb client which should not be downloaded in runtime to make the dialog between two RTCWeb client. I asked for SIP initially as SIP is the de-facto protocol and mostly deployment. I agree with Peter & others that websocket could be another alternative in the web deployment. In case required, I'll come up the write up to show the needs of default signaling protocol for making dialog between browser to browser.
> 

Do you mean there should be a 'default signaling protocol' on every browser? I'm not sure I'd like that. I (personally) see RTCWeb as a framework on top of which we can build RTC applications. The fact that one would use SIP and someone else uses something else is not crucial, IMHO. Now if some new simplified protocol is chosen for browser-to-browser communication we'd have yet another island of devices (browsers in this case) to which we'd need to gateway somehow.

[snip]

>> 
>> WebRTC defines multimedia capabilities for web-browsers and mandates
>> protocols as RTP, STUN, ICE, and understanding of SDP (RFC 4566). The
>> aim of these protocols is to enable multimedia streams between a
>> web-browser and other endpoint (which could also be a web-browser).
>> 
> <partha> I hope that the aim of the protocols is to enable multimedia stream between browser to browser only. In case browser to other end-point is outside the scope of RTCWEb. </partha> 
> 

Well, why build a parallel universe just for the browsers? If RTCWeb would only define the media plane and developers themselves can choose the signaling protocol, the integration with existing communication systems (using SIP or XMPP for example since they are the most used ones) would be pretty straight-forward.

My 2 cents.


Regards,

--
Saúl Ibarra Corretgé
AG Projects