>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.
Correct. The relevant code has already landed in NSS CVS. I assume ekr & bsmith will coordinate on 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. Agreed, and I said something similar below. Core sipcc code not touched by the ikran work or recent updates can have lower scrutiny. This will be a big review task, though, so extra eyes who are used to parsers and negotiation would be helpful! >> 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). Agreed. >> 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). dveditz? That sounds right. Can we get him? >> 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. Ok, thanks. >> 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? Yes. I'm not covering chrome here. >> 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". Right. There is a bug on this to kinetik; I have no idea when he might have time to address it. In particular we'd like to move the AEC closer to the audio drivers. >> 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. Understood. We'll also be making changes and increasingly feeding them back to webrtc.org and thereby to Chromium. We have the ability to update off webrtc.org anytime we want; as we move forward we may use that. But it does come with extra costs in reviews, testing and security checks, so we'll need to keep that in mind. We can also get more visibility into their plans for stable pulls, etc and try to sync them to our needs. Thanks for the comments! -- Randell Jesup, Mozilla Corp remove ".news" for personal email _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
