Re: Reference Protocol and Implementation

On 13 Nov 2011, at 16:53, Ramesh Nethi wrote:

> Hi,
> 
> I have been following the activity on WebRTC last few months and excited to see the progress on the spec development.
> 
> Wearing the hat of a web application developer, I have a question:
> 
> As a web app developer, 
> 
> - I am not an expert on signalling and media protocols
> - As a result, I cannot devise robust and secure protocols for the same.
> - However, I understand the web application development part of it (HTML5/JavaScript/Ajax/WebSockets, Python/PHP/Java/Node.js/Ruby etc)
> - I am excited at the possibility of a cross-browser, plugin-less  RTC capabilities and have bunch of ideas on how I can leverage these capabilities for a new application I am planning on developing
> 
> - Going through some of the emails in this discussion forum and the API spec document, I get the impression that when browsers implement this standard, it is not enough for me to get started with application development. I still need the signalling protocol aspect to be taken care by myself.

It very much depends on what your application needs are. 

The simplest case really shouldn't need any library or anything beyond your normal coding skills.
So if have a group of users who all share the same web portal, you should be able to set up voice and
video calls between them without a major programming effort.

With the currently envisioned 'ROAP' model it would look something like this:

For the Alice calls Bob case, you will need to write some Javascript that uses the API to generate an 'offer',
which is a string, the page sends it (probably over a websocket) to your server, where the Node.js forwards it to 
Bob's browser. Your code in Bob's browser passes the offer string to the API, which returns an 'answer',
which is likewise a string. You return this 'answer' to Alice's browser via the reverse of the path the offer took.

(Think of the 'offer' and 'answer' as the fine print attachments 
to the "Alice would like to call Bob" and "Bob will accept Alice's call"
messages that you'd have to exchange anyway).

Assuming that the browsers are at all compatible the result of this exchange should be a bi-directional voice/and/or
video connection between Bob and Alice. 

Your javascript can tear either end down as needed.

Some NAT situations may prevent Bob and Alice from communicating directly. In which case you may need to run a
service that simply forwards packets between the two parties.

As for libraries, I would expect that by the time the browser code is available for general release, several opensource libraries will have early beta versions that support this and more complex use cases. 
Indeed I imagine quite a few free services you can use for the packet forwarding will also spring up.

Tim.

Received on Sunday, 13 November 2011 20:40:01 UTC