<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Arial, sans-serif" size="2">
<div>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.</div>
<div> </div>
<div>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?</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>--Nicklas Sandgren</div>
<div> </div>
<div> </div>
</font>
</body>
</html>