W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2014

Chairs' notes, May 20-21 WG meeting

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 27 May 2014 15:36:09 +0200
Message-ID: <538494C9.3070203@alvestrand.no>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:40 UTC