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

[Roman Shpount <[e-mail]>]

With the API we are discussing (ie have methods to generate an offer,
process an answer or answer update to the last generated offer, process the
last offer refusal, process an offer and generate an answer to it) it is
very simple to build a simple point to point RTC call:

First client uses the API to generate an offer.

First client sends this offer (at this point it does not matter if offer is
JSON or SDP encoded, as long as client can get this description and encode
it into something that can be send over http), using http post to a web
server.

Web server stores this offer into some type of storage (local file, in
memory db)

Second client pulls the web server using some sort of timer for an offer
using http GET.

As soon as offer is created and stored, web server reads the offer from the
storage and sends it to the second client.

Second client uses API to process the offer and generate an answer.

Second client sends the answer to the web server using http post.

Web server stores answer in the storage.

After sending the offer first client is pulling web server for the offer
using some sort of timer http get.

As soon as answer is created and stored, web server reads the answer from
the storage and sends it to the first client.

First client gets an answer from the web server, passes it to the API as an
answer to the last offer.

Connection is setup!. No SIP is used. Application like this can be developed
by a fifth grader as a homework project and installed on any shared hosting
provider. If you have websockets or some other javascript eventing library
you can make this a lot more interactive.

If you do SIP on the other hand, you will end up with a the same or more
work as a developer, will have to install a lot more software on the web
server, will have to learn a whole bunch about new signaling protocols until
you figure out why things do not work.
_____________
Roman Shpount


On Thu, Sep 22, 2011 at 8:58 PM, Jozsef Vass <[e-mail]> wrote:

> I am in support of having some basic mechanism in the browser as part of
> rtcweb to enable developers to quickly and easily setup media between
> participants. Furthermore, if an API is too complex or too hard to use,
> people will not use it or misuse it. I can only see a handful of companies
> developing advanced calling feature on top of rtcweb, most people just want
> to have something simple to work without caring too much about the details.
>
> Maybe it would be advantages to specify such a very basic use case, e.g.,
> targeting gaming. It must work behind NATs using peer-to-peer media
> transport (but fallback to media relay may not be required). Since it is
> targeting closed community, there is no need for interoperability, there is
> no need for SIP, Jingle, etc. At the minimum, this would require a simple
> service for ip address lookup and to aid NAT and firewall traversal.
>
> For example, when a user registers with this service, he/she is assigned an
> identifier or blob. In order to communicate with another party, all they
> need to do is to exchange this information (this can be done using
> websocket, etc.) and setup media channel. There should be no need for
> parsing SDP, etc.
>
> Jozsef
>
> -----Original Message-----
> From: Harald Alvestrand [mailto:[e-mail]]
> Sent: Wednesday, September 21, 2011 2:08 AM
> To: [e-mail]
> Subject: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was
> RE: About defining a signaling protocol for WebRTC (or not)])
>
> On 09/20/2011 09:28 AM, Saúl Ibarra Corretgé wrote:
> > On Sep 20, 2011, at 12:59 AM, Roman Shpount wrote:
> >
> >> 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.
> > +1.
> >
> > If we add some signaling protocol to the browser to ease web developers
> then someone might say "why don't we also add X, Y and Z". The browser only
> needs the media plane, the signaling can be elsewhere, and it's far better
> to have it elsewhere.
> >
> > As Roman pointed out, RTC applications are not something that can nor
> should be done in 20 lines of JS. It's just complex. If people want to make
> simple apps they can build a simple JS library using an invented simple
> protocol. But RTCWeb shouldn't encourage this IMHO.
> Let me just say that I totally disagree on this point.
>
> The developers of applications that need audio and video capabilities are
> not RTC developers. Their main focus and main skill set will lie elsewhere.
>
> In a little more than 20 lines of code, it is possible to set up a call
> using a variant form of the existing W3C API. I know, I have seen the code.
> Other examples (in a slightly different variant) are part of the Ericsson
> demo.
> What's perhaps more important is that none of those 20+ lines mention
> anything about codecs, bit rates, congestion control or any of the numerous
> other issues we've been hashing out.
>
> With the API we support, simple things MUST be simple. Complex things must
> be possible.
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>