Proposal: Add RtpSenderInit parameter to addTrack.

While talking to Stefan about the possibility of per-RtpSender control of
VAD, and thinking about all the recent discussion around MSID, I realized
that there was a common need to add parameters to addTrack.

I propose we add a dictionary parameter "RtpSenderInit", like we have
DataChannelInit that contains parameters for
PeerConnection.createDataChannel without making the parameter list a mess.

IDL that would retain current semantics could look like this:


partial interface PeerConnection {
    RtpSender addTrack(MediaStreamTrack track, RTCRtpSenderInit init);
}

dictionary RTCRtpSenderInit {
  sequence<MediaStream> streams;
}


A more advanced form, if we choose to add more parameters later, could look
like this:

dictionary RTCRtpSenderInit {
  // These are based on our discussion of MSID.
  DOMString label;
  sequence<DOMString> synchronizationGroups;

  // The initial RtpParameters to use, as if you call .setParameters
immediately after
  // calling addTrack.
  RtpParameters parameters;
}

​dictionary RtpParameters {
  // This is based my discussion with Stefan.
  boolean voiceActivityDetection;
}​



Let's continue the discussion around voiceActivityDetection,
synchronizationGroups, and label/ID on separate threads, but for this
thread, I'd like to ask the group:  Does it look like a good idea to follow
the createDataChannel(..., DataChannelInit) pattern by having addTrack(...,
RtpSenderInit)?


I'm in favor of it because:
1.  We'd avoid with a mess of parameters in addTrack over time.
2.  It gives the app to specify initial RtpParameters (such as VAD,
potentially).
3.  It follows the same pattern we already have for createDataChannel,
which has been successful in adding many options without making the
parameter list a mess.
4.  It gives us more flexibility in our work around IDs and labels.

Thanks,
Peter