Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket

It is worth pointing out that even with a signalling  protocol agnostic webRTC you 
wouldn't _have_ to implement your signalling protocol in javascript.

Browsers support other plugin languages - specifically it would be possible to implement
a classic full UDP SIP stack as a java applet and delegate the media handling to the webRTC layer.

Chrome is moving towards support for native plugins, but it isn't clear that they
would be suitable for this use.

Tim. (speaking for himself)

On 14 Sep 2011, at 11:03, Ravindran Parthasarathi wrote:

> Hi Inaki,
> 
> <snip> 
> 
> The fact that there are other alternatives for signaling in the web does not mean that using SIP is invalid.
> If I want to build a SIP phone in a web, why should I use libjingle rather than SIP protocol? Why should I code a complex server behaving as a gateway between Jingle and SIP protocols?
> 
> Any protocol conversion (i.e. from Jingle to SIP) means loss of features. Our draft proposes the contrary: no protocol conversion (just SIP), and just transport protocol conversion (as already exists in SIP when bridging UDP/TCP/TLS-TCP/SCTP...).
> </snip> 
> 
> I agree with your problem statement. I have raised the same concern in http://www.ietf.org/mail-archive/web/rtcweb/current/msg00845.html. IMO, your solution is a workaround and we will end-up with your solution in case signaling protocol is not standardized as part of RTCWeb.
> 
> Thanks
> Partha
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb