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

["Ravindran Parthasarathi" <[e-mail]>]

Hadriel,

Sorry for the delay response. I have mentioned the reason for "standard signaling protocol" as a separate draft and the related thread is http://www.ietf.org/mail-archive/web/rtcweb/current/msg01733.html. 

I agree to the fact that SCCP protocol is decided by Cisco folks but it does not mean that every company in the world has to create their own version of SCCP protocol and IETF should not force every company to re-invent the wheel.

The intention of standard signaling protocol is not against those who have the interest in creating their own proprietary signaling protocol. The main purpose is for the welfare of those whose focus is not signaling but interested in Real-time communication. JavaScript library by third party is worst case in case there is no native standard signaling protocol exists for RTCWeb.

Let us discuss how much services has to be provided by standard signaling protocol.

Thanks
Partha

>-----Original Message-----
>From: Hadriel Kaplan [mailto:[e-mail]]
>Sent: Friday, September 16, 2011 7:55 AM
>To: Ravindran Parthasarathi
>Cc: Saúl Ibarra Corretgé; <[e-mail]>
>Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About
>defining a signaling protocol for WebRTC (or not)]
>
>
>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