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

Hi Roman,

I agree with you in case you wish to have all class 5 services in this architecture. In the web game server wherein the basic call has to be established between two parties, this complexity is not required. One of the main aim of the RTCWeb default signaling protocol is to make two party real-time communication easy with less development effort for any web developer.

Thanks

Partha

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: Tuesday, September 20, 2011 4:29 AM
To: Randell Jesup
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

Randell,

What I fail to understand is in what way would adding signaling to the web browser would  make things easy to build? How is what you are proposing better then 2 or 3 well written samples?

On the other hand, if you decide to build such simple signaling interface, depending on what use case you are trying to address you will end up with very different libraries. You have to decide how complex you want to make this library on the server vs the client side. You will need to decide if the purpose of this library is to simplify browser-to-browser or browser-to-PSTN calls. There is going to be a large number of very complex decisions none of which have obvious answers and will greatly affect the overall library design.

Most importantly, I think this is a misconception that you can build something that can be developed in 20 lines or less and be useful. Real-time communication is order of magnitude more complex then most of the web related applications. You need to deal with multiple event sources, deal with event collisions, negotiation failures, call state machines. And this is what required for the basic call setups. Once you start dealing with transfers, conferences, call status monitoring, things become even more complex. It is almost impossible to develop something that is simple to use that serves more then one or two specific use cases. If we try to invent something like this we might never finish.
_____________
Roman Shpount

On Mon, Sep 19, 2011 at 6:36 PM, Randell Jesup <randell-ietf@jesup.org> wrote:

On 9/19/2011 4:33 PM, Saúl Ibarra Corretgé wrote:

	You misunderstood me; I meant "if you use an optional SIP module, you'll
	need to have a SIP proxy on your server".  WebRTC in general presumes some sort
	of server architecture to solve the discovery/invitation problem.  There *are*
	some possible uses of WebRTC that might not use a central server(s).   The simplest
	would be the "phone-tag" server, where you and the person you want to talk to
	exchange IP addresses and external port numbers over the phone, and type them into
	the web app, which then opens a default-configured PeerConnection and re-negotiates
	to the actual configuration.

Still, you need this "phone-tag" server, so who will provide it? I don't see a way for 2 parties to communicate without help from outside the browser, thus, I wouldn't define any sort of protocol, even if we could simplify one.

The purpose of including a protocol (which is optional to use) isn't to allow
direct browser-to-browser discovery or initiation without a server.  In fact,
it doesn't help *or* hurt that use-case.  A primary reason for including a protocol
is to make it easy to build things.  We don't *just* want organizations with the
resources of Google or Skype or Cisco (or Mozilla) to be the ones who can make
use of this new capability; we want all web developers to feel it's within their
grasp.  This could be satisfied in a few ways, as discussed: "baked in" simple
SIP/O+A; a JS lib plus support pieces for SIP/O+A like the state machine baked
in; or a pure JS implementation.  But we are wary of putting it out with merely
the hope that a good-enough JS lib will show up someday (and there are other pros
and cons; no need to repeat them here).

As far as needing external servers: there are some ideas we're floating around
that would allow for server-less or virtually server-less operation of WebRTC
clients including discovery and initiation, from behind NATs.  We haven't
speced it out or even proven it's workable yet, but we're going to look very
closely at some type of proof-by-existence for this idea.

-- 
Randell Jesup
randell-ietf@jesup.org

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb