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

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

+1

On Sep 16, 2011, at 4:24 AM, Hadriel Kaplan wrote:

> 
> There is no need for a "default signaling protocol", because the "signaling" is between the browser's Javascript and its web server.  And as for the signaling protocol the web server has to support in order to speak to other servers or non-RTCweb endpoints, even if we specified to use SIP we'd just be summarily ignored by those who don't want to, because they actually don't *need* to.  It doesn't hurt interoperability of rtcweb if they don't implement SIP - it just means they can't talk to other SIP devices/servers.  But it's not like we need an RFC to say "if you don't implement X then you can't talk to people who do X".
> 
> Think of this RTCWEB concept as Skinny/SCCP.  The Web Server is Call Manager, and the browser is the Skinny phone, but in this case instead of needing a 7960 phone, the Skinny protocol was written in javascript and uses a browser's user interface for its GUI and the built-in RTP library for media. (in fact one could probably write a javascript to do just that, if Call Manager handled SCCP over websocket)  
> 
> Clearly the IETF does not need to define for Cisco a standardized replacement for the SCCP protocol for this to work, because one isn't needed since the client javascript and server are built by the same developers and they know how their proprietary signaling works.  So how about for the signaling Call Manager would use to other VoIP devices, like gateways or VoIP service providers?  Does the IETF need to tell Cisco what peer-to-peer protocol(s) to implement on Call Manager?  No, and we never have.  Cisco's product managers decide that.  They decide if Call Manager needs to be able to communicate a standard protocol at all, such as SIP or H.323, and which one/any of those.  They decide based on their use-cases/need.
> 
> Some rtcweb developers may not do any standard signaling protocol, ever.  For example many Instant Messaging providers still have closed environments to this day. (e.g., AIM, YIM, MSN, etc.)  Some may choose to only use H.323, or XMPP, or IAX, or even BICC.  Some may choose to only support SIP with 3GPP extensions.  Obviously most of us think/hope people do SIP, but really the market makes those types of decisions, not the IETF.  Just like the IETF standardized MGCP but didn't specify what the MGCP Call Agent had to support to speak to other Call Agents.  SIP was given as an example in MGCP, but not mandated.
> 
> The only thing we need to do for rtcweb is make sure the RTP library built into the browser supports media in such a way that it can communicate with other RTP peers at a media plane, regardless of what signaling protocol those peers might be using, preferably without going through media gateways.  And obviously since SIP is a very common protocol and defined by the IETF we need to make sure it's possible to use SIP on the rtcweb server, but we can't *mandate* that it be used or supported, and if we did it wouldn't change anything. 
> 
> -hadriel
> 
> 
> On Sep 15, 2011, at 7:56 PM, Ravindran Parthasarathi wrote:
> 
>> 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
> 

--
Saúl Ibarra Corretgé
AG Projects