W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2011

Re: Reference Protocol and Implementation

From: Ramesh Nethi <ramesh.nethi@gmail.com>
Date: Wed, 16 Nov 2011 18:54:05 +0530
Message-ID: <CAK5fhoo22Dat6s4B=fCkK4Xtoxnv9Bp3wM7qmRxCSsYSRzvS0Q@mail.gmail.com>
To: Tim Panton <thp@westhawk.co.uk>
Cc: public-webrtc@w3.org
Hi Tim,

Thanks. I understand the point about the simple use cases.  My intent was
to raise these questions from a "web developer" perspective and not from
"my" perspective.

I agree with your point that in due course of time several open source
libraries would spring up (including some from vendors on this list). But
timing of which cannot be controlled by people on this list or "web
developers".

My specific intent was to see if there is interest (or part of work group
charter) in the work group to  do reference protocol and implementations,
even if it covers only a subset of use cases.  But I hear from the
responses that there is no such plan to do reference implementation.  May
be an opportunity for some enthusiastic folks to start an apache/github
project

regards
Ramesh

On Mon, Nov 14, 2011 at 12:33 AM, Tim Panton <thp@westhawk.co.uk> wrote:

>
> 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 Wednesday, 16 November 2011 13:24:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 16 November 2011 13:24:47 GMT