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

["Muthu Arul Mozhi Perumal (mperumal)" <[e-mail]>]

|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.

+1. 

We may also want to make sure that it is possible use SDP, but shouldn't
mandate that it be used.

Muthu

|-----Original Message-----
|From: [e-mail] [mailto:[e-mail]] On
Behalf Of Hadriel Kaplan
|Sent: Friday, September 16, 2011 7:55 AM
|To: Ravindran Parthasarathi
|Cc: <[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
|
|_______________________________________________
|rtcweb mailing list
|[e-mail]
|https://www.ietf.org/mailman/listinfo/rtcweb