Media/WebRTC/2012-08-07

From MozillaWiki
< Media‎ | WebRTC
Jump to: navigation, search

8/7/2012, 9:00am Pacific:

1) Follow up on https://bugzilla.mozilla.org/show_bug.cgi?id=738528 and https://bugzilla.mozilla.org/show_bug.cgi?id=773847 (status of getUserMedia testing for Android on Firefox 15, 16, and beyond)

  • (jsmith) In the short-term - let's find an owner to fix bug 773847
  • (jsmith) Status of Android Testing - Don't know too much from my end, although with bug 773847 existing right now, testing would be blocked right now anyways
  • (jsmith) Long term solution - we need a continuous triage strategy and execution consistently. Many bugs are coming in (not just that one above) that may need immediate action or may need to be fixed to ship getUserMedia per each platform (and the full WebRTC stack at large as well, although it's more critical to get a process in place for the immediate functionality available). Let's figure out how to consistently do this.
  • Set up a weekly triage meeting (UPDATE: had a good meeting Wed)

2) Discussion of Microsoft's W3C proposal

  • Lots of discussion
  • Who's driving it at Microsoft? Skype? Is the IE team involved? Will it ship in IE, if so when?
  • Will they implement the standard if it isn't exactly what they want?
  • Will they implement the standard if it has "enough" of what they want?
  • What's their goal with the submission? Is the big issue NAT traversal/ICE?
  • We want to find out more.

3) Where does our implementation stand coming out of IETF?

a) Signaling Update -

  • Bunch of extensions not in yet (BUNDLE, mux, etc)
  • Have basic JSEP working

b) Media Transport Update -

  • SRTP-DTLS working, need fingerprints

c) Data Channels Update -

  • Got basic data channels merged with PeerConnection - some DOM issues to resolve
  • Updated SCTP lib
  • Have test of SCTP over DTLS working

d) DOM Integration Update -

  • PeerConnection object up.

e) Build System Update -

  • Plan to deal with PGO/gkmedia stuff after signaling/C++ unit tests

f) Identity Integration Update -

4) What else remains before we try interop with Chrome?

  • Need to get us working with PeerConnection_client
  • ekr to send writeup
  • (jsmith) Stability of our stuff isolated. We should make sure our stuff itself isolated works reasonably before tackling that. Otherwise, we'll end up in points of confusion of needing to effectively determine if it's a problem in our implementation, Chrome's implementation, or the mixture of both (too much of that creates a lot debugging overhead). In the immediate sense, this means we should try to get mozGetUserMedia implementation stable (even if the UI isn't implemented) to an acceptable level of quality (whatever that may be, so let's set a quality standard for that). In the long term sense, we should determine what our the quality requirements to meet before we tackle interoperability (i.e. acceptance criteria).

5) What else remains to be done for our v1.0 implementation? (This may best be captured in an email and discussed there and then followed up in the meeting next week)

  • Reviews - security and code
  • Need to update landing plan - big item is signaling
  • Try to get some other parts started though earlier (mtransport, datachannels, maybe DOM)

6) Testing (QA) sync up

7) Discuss any current blockers for people or new items that haven't been discussed

  • None mentioned