Overview of plan to land webrtc code from Alder to Mozilla-Central:

3rd tranche: in alder; each can land separately.  Target date: Sept 15.
    libjingle (very small subset - mostly sigslot - see if we can move into 
ipc/chromium).
    These depend on sigslot (libjingle):
      SCTP/DataChannel (netwerk)
      transport service (ICE/TURN and p2p transport from EKR)
    Opus
    libsrtp
    libyuv
    update of webrtc.org code
    more tests

4th tranche: Target date: Sept 30th.
    signaling (sipcc)
       This is large, on the order of 200-250K lines.
    peerconnection DOM work
    update of webrtc.org code
    more tests

---------------
Reviews needed:

We will NOT be line-by-line reviewing imported code.  We will be importing
versions chosen for stable snapshots by Chrome in order to best leverage
Google's testing and security work.  This also will let us watch any
important bugfixes and security fixes to those 'stable' pulls.  Updates on
m-c after landing will be pulled from Chrome stable revs, but with perhaps
a bit more examination of the ongoing changes as the size of the patches
goes down.

Updates to third-party code (libyuv, libsrtp) to be handled
in conjunction with webrtc.org updates

We will be doing normal line-by-line reviewing of code we wrote
and modifications to the imported code.



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.
  We need to tie into Google's security team
  We'll need protocol fuzzing
     Avoid too much overlap with Google's testing
     cdiehl has experience with fuzzing
     Protocols available for fuzzing:
        RTP/RTCP
        SRTP/SRTCP (libsrtp)
        DTLS
        SCTP/DTLS
        ICE
        STUN
        TURN
        VP8 and OPUS packetization (may not be much there)
        NetEQ/etc (fuzz by modifying jitter and loss)
        JSEP/SDP (huge possible space)
  User privacy protection and controlling the attack surface of the
     browser will be important considerations.

Opus support in WebRTC
  Reviewers: jesup, derf

DataChannels
  Note: most of the base library is already reviewed.
  Reviewers: mcmanus/biesi (netwerk/sctp), jst/peterv (DOM)

mtransport:
  Reviewers: mcmanus/biesi/jesup, security

Review libsrtp and libyuv. 
  Note: pure import, no line by line review
  Reviewers: ekr, derf, jesup, graphics team member?

Signaling:  (JSEP/SDP)
  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.
  There is lots of "dead" code on paths only used when SIP is
    enabled, which it is not in the initial landing.  When/if we
    enable SIP, we'd want to give once-over review of those pieces to 
    make sure we haven't violated any invariants of the code with
    our other modifications.
  We may want to spread the review load wider here, and we should 
  try hard to break this into separate reviewable pieces.
  Some parts are already being reviewed by ekr as mods are made,
  and may just need a roll-up review of the final state.

  We also are trying to get an engineer from Cisco's SipCC team to
  review the mods to the code.  (Also, several of the Cisco engineers on the
  WebRTC team have worked with SipCC in the past.)

  Reviewers: jesup, ekr, derf, mcmanus(?), biesi(?), security

PeerConnection DOM
  Reviewers: jst, peterv, khuey?

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.


-- 
Randell Jesup, Mozilla Corp
remove ".news" for personal email

_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to