Hi Matthew, all, before drafting all the API possibilities in detail, perhaps we should discuss what should be standardized in terms of signaling mechanisms? As I read your proposal, APIs A, C and D all rely on some sort of connection control signaling happening under the API (i.e being part of the implementation in the browser). B and E in contrast leaves this to the application developer. Any means can be used to exchange the required information, and the standard would be silent on what mean to use. In http://datatracker.ietf.org/doc/draft-alvestrand-dispatch-rtcweb-protocols/?... it is stated that connection control signaling is left to (web app) implementors. My impression was that there is a consensus on not standardizing signaling mechanisms (at least not in the first phase), but to focus on enabling the browser to set up a connection to a peer and to transmit and recieve media streams. (I see a need, for cases where you like to enable interoperable applications, to agree on signaling formats - but this is another thing, it is not part of the browser implementation but rather e.g. a common JS library) Maybe I'm getting something wrong here, please correct me in that case. Also, IMHO, if we are to standardize signaling mechanisms as part of the implementation in the browser, SIP/SDP would be a natural starting point. //Stefan
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Matthew Kaufman Sent: den 8 januari 2011 05:30 To: Harald Alvestrand Cc: RTC-Web@alvestrand.no Subject: Re: [RTW] peer-to-peer connection API thoughts
On 1/7/2011 5:03 AM, Harald Alvestrand wrote:
For very simple applications, this might be a sufficient
API. But even
if the object is magical, I think its API has to be quite a bit richer - in particular, when the state of the connection changes (failover to new connections, data doesn't flow any more, data suddenly flows a great deal faster than before) the changes have to be signalled back (using callbacks?) to the client Javascript so that appropriate user interface events can happen.
When I yank out my network cable, and don't have wireless, I expect an error message saying "connection lost"; I don't expect things to just freeze.
Agreed. I had left out all the status events and adjustment knobs... trying to just get connection establishment happening.
So the extended API for establishing a connection would be something like
var connection = new PeerConnection(destinationSpecifier, changeCallback, deathCallback, ....)
In JavaScript you'd just have the destinationSpecifier and then assign event handlers to the "connection" instance of the PeerConnection object. So:
connection.onDeath = doSomething;
(or in the new way, connection.addEventListener('death', doSomething, false); )
B. A single connection object which does most of the
magic, but with
the low-bandwidth signaling made external though events
In this case, the API is the same as above, but rather than providing in the destiniationSpecifier some sort of server address for the "low bandwidth signaling" the connection object would instead fire events containing (essentially opaque to the channel, but in an agreed format) the data which needed to be transported to the other side. A corresponding API on the far end's "listening" connection object would allow for the data to be injected at the far end. The script implementer would simply need to wire the event up to an existing transport mechanism (HTTP, WebSockets). I'm not familiar enough with this form of API to interpret that - what are these events, where would the events go, and who would handle them? Or are "events" Javascript terminology for what I'm used to calling "callbacks"?
Pretty much, yes. See above.
So you'd have something like:
function sendMessageToOtherEnd(message) { ... use an existing WebSocket to your signaling server to send the message ... }
connection.onMessageToOtherEnd = sendMessageToOtherEnd;
C. A connection object which does most of the magic, but with a parent object that is the connection to the signaling mechanism
This is the approach Flash Player has taken. The NetConnection is opened to the rendezvous-handling server (which can also act as a media relay), NetStreams are then opened either to that relaying server or directly to other peers. These peer-to-peer
NetStreams use
the open NetConnection for the peer setup signaling (determining the far IP addresses, requesting NAT hole-punching, etc.) Interesting - does this mean that one has an overarching object that can relate to multiple streams? Are there multiple streams active at the same time, and if so, what state do they share, and how are they different?
Yes. There's a "NetConnection" which represents the connection to the server, and then zero or more NetStreams, each of which is a unidirectional flow of media. Some of the NetStreams may represent peer-to-peer streams, so either "published locally for consumption by peer" or "played from <remote peer-ID>".
Pointers to specs would be welcome!
http://help.adobe.com/en_US/FlashPlatform/reference/actionscri pt/3/flash/net/NetConnection.html
and
http://help.adobe.com/en_US/FlashPlatform/reference/actionscri pt/3/flash/net/NetStream.html
(The same API is also used by "RTMFP Groups", which is a p2p overlay that includes application-level multicast, so you can also publish/play NetStreams over the multicast overlay.)
No more comments on these - good starting thoughts!
I'm glad to see that we're starting to make progress on multiple fronts here. Shouldn't be long before we can put together some draft specs and start refining the details.
Matthew Kaufman _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web