Looking at the latest draft, section 4.11.6 contains a proposal for the 
<device> element as discussed quite extensively on the W3C DAP list. In 
addition there is a Stream API and a sub-section on peer-to-peer connections.

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?

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.

--Nicklas Sandgren


Reply via email to