Re: [rtcweb] Review request for RTCWeb standard signaling protocol

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

<snip> My argument is that if we want the ultimate goal of simplicity
for end user web developers then we should minimise everything they have
to touch - and that includes removing any requirement for server side
infrastructure beyond the basic bare minimum, which would mean no SIP
proxies, no websocket servers etc etc.

 

But as I said, we don't need to standardise a protocol at all, so we
shouldn't. If we are lucky we'll see a whole spectrum of solutions.

 </snip>

 

Without server interaction, it is not possible for browser to establish
the session with other browser. Unlike other endpoint, browser needs
server to provide routing or  perform the authentication or atleast
configuration information. AFAIK, RTCWeb client to RTCWeb client is not
the motive of the work. If so, SIP is the IETF protocol between RTCWeb
client to RTCWeb client which MUST be recommended because of the UA to
UA communication nature. IOW, RTCWeb server signaling plays the key role
which calls for standardization as browser & RTCWebserver is not
required from the same vendor.

 

Thanks

Partha

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Neil
Stratford
Sent: Friday, October 07, 2011 5:24 PM
To: Ravindran Parthasarathi
Cc: samuel; Tim Panton; [e-mail]
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling
protocol

 

On Fri, Oct 7, 2011 at 12:40 PM, Ravindran Parthasarathi
<[e-mail]> wrote:

	Browser to browser real time communication is no different from
other real-time communication apart from the existing web
infrastructure. In case your argument is to use the existing web
infrastructure like websocket, I agree with you.

 

It is different to traditional RTC - we have a javascript execution
engine intimately tied in to every client. This completely changes the
solution space.

 

	But in case it is not the reason, Could you please list the
reason for new signaling protocol requirement .

 

I already listed them: 

	 

	- No server side infrastructure (SIP proxies etc) to maintain or
configure.

	- No special understanding in the server side web application
beyond discovering peer identities you might want to communicate with.

 

My argument is that if we want the ultimate goal of simplicity for end
user web developers then we should minimise everything they have to
touch - and that includes removing any requirement for server side
infrastructure beyond the basic bare minimum, which would mean no SIP
proxies, no websocket servers etc etc.

 

But as I said, we don't need to standardise a protocol at all, so we
shouldn't. If we are lucky we'll see a whole spectrum of solutions.

 

Neil