Randell Jesup wrote:
3rd tranche: (June 29)
SCTP/DataChannel (netwerk)
transport service (ICE/TURN and p2p transport from EKR)
This is going to need an NSS update, so someone will have to coordinate
that.
---------------
Reviews needed:
We will be doing normal line-by-line reviewing of code we wrote
and modifications to the imported code.
Some of these modifications are significant (e.g., the work Cisco is
doing on SIPCC). What is the plan for that? I tend to think this should
be treated as any other new code, and reviewed properly.
Security reviews: To be negotiated with Security team; done in phases
and leveraging Google's work.
Most likely soft spots will be DOM and signaling. Maybe DataChannel.
I'd say definitely DataChannel. I don't think Google has done much work
for us to leverage on that (we're leading here).
We need to tie into Google's security team
We'll need protocol fuzzing
Avoid too much overlap with Google's testing
dveditz indicates they have a contractor in Germany? who has
experience with fuzzing
He's likely referring to Cristoph Diehl (cdiehl), who's helped us in the
past with Vorbis/Theora/VP8/Opus fuzzing (and probably other things I
wasn't involved with).
VP8 and OPUS packetization (may not be much there)
Any code that isn't tested is broken :). The danger with these
particular pieces is that they are the only widely-used code for these
formats in RTP in existence, so they've pretty much only been tested
against themselves (the Opus piece in particular doesn't even exist
yet). I've already found (reported and had fixed) matched
payloading/depayloading bugs in their VP8 stack.
Flipping pref for getUserMedia():
Review getUserMedia()
Reviewers: DOM Team member (khuey?), sicking?
Review capture-path of media/webrtc/trunk/src
This is high-level review of the imported code before turning it on
Reviewers: jesup, derf, ekr, ?
Review device access code
audio and video, all main platforms
This is high-level review of the imported code before turning it on
Reviewer: TBD
Review rendering paths for preview
Reviewers: TBD (fabrice?)
We're also going to need some UX review for the browser-chrome portions,
yes?
Later:
Review protocol paths at a high level (not sure this makes much sense):
AEC (and CNG, etc)
Reviewers: jean-marc, derf, jesup
You're also going to want kinetik in here. There may be actual work to
do on this front (i.e., getting things integrated closer to our actual
speaker output than the webrtc stack can see by itself). I'm not sure
how much of that we can push off until "later".
This is sipcc - ~200K lines, and a fair amount of modifications
Also, a fair bit of code was added to sipcc after it was
open-sourced and before it was imported from ikran. That
code should get higher scrutiny.
Agreed, we just need to figure out where to do it.
Updates: We'll take updates from 'stable' branches of Chromium's webrtc
pulls, by pulling the same changesets. We should watch for changes
applied after they're moved to Chrome, and individually review those.
This leaves us dependent on Chrome for getting updates, which means
we'll always be one step behind. That's probably fine in the short term,
since we're starting out behind, but it doesn't sound like a good
long-term plan.
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
