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

[Iñaki Baz Castillo <[e-mail]>]

2011/9/23 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.

I strongly agree.

Just take into account that the second client could reject the call
("I'm bussy"), so there would not be SDP answer. Of course carrying
that information (the call rejection) is responsability of the
signaling protocol (which also carries the SDP bodies, as it occurs in
SIP and XMPP/Jingle).


> Connection is setup!. No SIP is used.

But it could be (I mean encapsulating SIP over HTTP or WebSocket)  :)
So freedom for all.


> Application like this can be developed
> by a fifth grader as a homework project and installed on any shared hosting
> provider.

And the audio/video sessions go through the web server so the web
application logic can decide wheter to terminate an existing
audio/video session (in case an user has been banned from a room-chat,
for example).


> If you have websockets or some other javascript eventing library
> you can make this a lot more interactive.

WebSocket is for sure the way to go.



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

Yes. In case the browser must speak native SIP or XMPP that will be
the end of this history (because a SIP proxy/registrar or XMPP server
would be required for ***each*** website).


> will have to learn a whole bunch about new signaling protocols until
> you figure out why things do not work.

The only server side requirement would be providing a STUN/TURN server
(and TURN authentication accounts).

-- 
Iñaki Baz Castillo
<[e-mail]>