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

[Roman Shpount <[e-mail]>]

Partha,

It is not possible to implement browser to browser calls unless both
browsers are on public IPs or on the same network. As far as signaling is
concerned, it is always going to be browser to server to browser call. Since
there is always a server on the signaling path and since implementing a
signaling gateway from long poll HTTP or websocket signaling interface to
SIP (as shown by a number of projects mentioned in this thread) is straight
forward enough to implement, there is no desire to create a standard
signaling protocol to be used in the browser. There is no benefit for the
application developer in following this standard, since it provides neither
more functionality no better performance then a custom protocol implemented
in JavaScript. Interop and fragmentation arguments do not apply to this
either, since it is the same as complaining that HotMail and GMail use
different protocols when implementing web mail. It does not affect anything
since this stays within the same application and is no more then an
implementation detail.
_____________
Roman Shpount


On Thu, Sep 15, 2011 at 7:56 PM, Ravindran Parthasarathi <
[e-mail]> wrote:

> Hi Saul,
>
> I really didn't get your argument fully because in case there is no default
> signaling protocol, it is unavoidable to have island of devices without
> gateways but you argue other way around.
>
> I specifically asked for the scope of your opinion on RTCWeb work is
> between browser-to-browser or browser-to-other end-point to know whether
> parallel universe has to be build or not. In case there is no default
> signaling protocol, it is impossible to communicate between
> browser-to-endpoint without gateways. Let us assume that the intention of
> RTCWeb is to create island of browser devices even then the native signaling
> protocol for RTCWeb has advantage over Jquery library and plugin is not the
> solution.
>
> Having said that, I agree that it is possible to implement RTP or STUN or
> SIP stack or codec using Javascript or plugins but interop and better
> performance is not guaranteed.
>
> Thanks
> Partha
>
> >-----Original Message-----
> >From: Saúl Ibarra Corretgé [mailto:[e-mail]]
> >Sent: Thursday, September 15, 2011 1:23 PM
> >To: Ravindran Parthasarathi
> >Cc: Iñaki Baz Castillo; [e-mail]
> >Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or
> >not)
> >
> >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
> >
> >
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>