Re: <device> proposal (for video conferencing, etc)

On Thu, Dec 17, 2009 at 9:58 PM, Nick Lothian
<nlothian@educationau.edu.au>wrote:

> > >
> > > Do you consider the client-to-client protocol to be in scope at the
> > > moment, or is that far-future work?
> >
> > I don't know. If we do introduce a client-to-client protocol, I'd
> > imagine
> > we'd want to reuse an existing one, so that we don't have to resolve
> > all
> > the NAT traversal issues. (Simplicity wouldn't be as high a priority in
> > this case as in the client-server case, since we'd expect far fewer
> > independent implementations, so there'd be less to gain by developing a
> > whole new protocol than there was with, e.g., Web Sockets.) I'm not
> > familiar with existing protocols for this, though.
> >
>
>
> SIP's probably the "standard" protocol for this.
>

Couldn't the Webapp simply replace the rendezvous functionality of SIP? A
mechanism along the lines of RTMFP seems valuable though note the JS
callback would need to know the media address/port information to relay to
the other end. But of course things are now getting complex. The Webapp
would need to handle NAT traversal issues, codec negotiation, potentially
transcoding, reliability reports, etc.

>
> Jingle (http://en.wikipedia.org/wiki/Jingle_(protocol)<http://en.wikipedia.org/wiki/Jingle_%28protocol%29>) is also interesting
>
> Flash v10 implements RTMFP (
> http://en.wikipedia.org/wiki/Real_Time_Media_Flow_Protocol), but this
> seems to be video specific (and if HTML was to support something it should
> allow anything to be transferred)
>

Nick
>
>
> IMPORTANT: This e-mail, including any attachments, may contain private or
> confidential information. If you think you may not be the intended
> recipient, or if you have received this e-mail in error, please contact the
> sender immediately and delete all copies of this e-mail. If you are not the
> intended recipient, you must not reproduce any part of this e-mail or
> disclose its contents to any other party. This email represents the views of
> the individual sender, which do not necessarily reflect those of
> Education.au except where the sender expressly states otherwise. It is your
> responsibility to scan this email and any files transmitted with it for
> viruses or any other defects. education.au limited will not be liable for
> any loss, damage or consequence caused directly or indirectly by this email.
>
>