- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 27 May 2014 15:36:09 +0200
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
These are notes collected by the chairs to make sure we remember the main decisions and important issues. They do not replace the minutes. Comments welcome! Tuesday: Doohickeys ---------- * Overall design accepted. Justin to generate pull request. * Decided that the possibility to indicate Stream relations is needed only at “addTrack” time - no way to change with less than a removeTrack followed by a new addTrack * Default should be null - i.e. no stream relationship * It should be possible to supply a list of streams (to indicate that the track is member of more than one stream) * Having the object model with transport info in a direct member of PC seems OK - no need to have a separate level of indirection for components. (This should be reflected in stats too). Error handling -------------- This seems more like a bug list than any missing architecture. * Consensus to add “onerror” for internal errors. * Discussion on if addTrack can fail, and that we would need success/error callbacks Justin argued that createOffer or setLocal is the time it fails Not sure what the conclusion was - but I think it was to not change into callbacks for addTrack/Stream * Opinion that transport failures should attach to the transport object pointed to by RTPSender/Receiver objects. (Me: Do they trickle up into PC?) Schedule -------- Given a number of (somewhat realistic) assumptions, W3C Last Call on the webrtc spec at end of Q3 seems like a reasonable goal. Assurance: Downrefs to I-Ds is not a problem at the time of W3C Last Call. Wednesday: Stats ----- Folks seem OK with the design Some desire to integrate fields with doohickey object model. Some discussion on the snapshot / timestamp issues that make fetching stats groups look attractive. Agreement with having stats be a separate document, as long as there is a normative reference to it from the Webrtc document. Identity and its impact on security ----------------------------------- * Accepted that all tracks coming from a PC with isolation negotiated will have isolation set, no matter what the sender thinks. * Accepted that if both isolates and non-isolates are needed, one can use two PeerConnections. (“complex things should be possible”). * Added an extension API to MediaStreamTrack for isolation change - especially for DASH-sourced streams, isolation can change over time due to operation of Web Origin isolation model. Interoperability issues ----------------------- Some issues already solved (code for FF/Chrome using different stun servers ripped out on the spot) Some discussion of the problems with the Sockets API and the expectation of infinite buffering (on both sender and receiver side). Streams seems to want to be a generic solution (if it becomes a single proposal). No current solution. Conluding remarks ------------------ The question was raised about whether we should focus energy on one document, or work on several documents in parallel. People seem to prefer finalizing gUM first and then focus on WebRTC 1.0, rather than working on both in parallel “better to have one doc ‘ready’ than two unfinished ones”
Received on Tuesday, 27 May 2014 13:36:44 UTC