[whatwg] <device> element, streams and peer-to-peer connections

Anne van Kesteren annevk at opera.com
Fri May 21 01:29:49 PDT 2010

On Fri, 21 May 2010 10:20:00 +0200, Nicklas Sandgren  
<nicklas.sandgren at ericsson.com> wrote:
> As mentioned in the draft, the peer-to-peer API must rely on underlying  
> protocols/mechanisms to establish the connections and to transport the  
> streams. What are the thoughts regarding these protocols, and has there  
> been any discussion around this topic?

Last I checked the hope is that the protocol problem will "go away". So  
far it seems that is unlikely. :-)

> An alternative approach could be to define APIs for managing streams  
> only, and leave session set up as well as additional functionality  
> (file, text, image share) to the application using the means already  
> available such as XMLHttpRequest and WebSocket. The session set up would  
> in this scenario not rely on a third party server, but rather be handled  
> by the server that serves the current web application. This would remove  
> the need for agreeing on formats for client and server configuration  
> strings or protocols to talk to third-party servers.
> You could also debate how often peer-to-peer media streams will actually  
> work. Aren't FWs and NATs going to give problems in many cases? Maybe it  
> would be better to design for a situation where the media always go via  
> a server. Additional benefits are that WS could be used for media  
> transport, and that the media could be transcoded if the codec  
> capabilities of the clients do not match.

I'm not really sure how this is an alternative approach. It would just be  
leaving peer-to-messaging out... Streaming video via WebSocket is  
something we definitely want to enable in due course, irrespective of  
whether peer-to-peer messaging comes to fruition.

Anne van Kesteren

More information about the whatwg mailing list