API points for ICE/DTLS warmup

In the IETF rtcweb WG today, we realized that we need API points for
helping ICE/DTLS warmup, which is to get the ICE/DTLS parts of
PeerConnection working and connected before sending or receiving any media,
but then being able to send media immediately after deciding too (not
waiting for a signalling round trip).

The API points we need are to allow the JS to say to the PeerConnection:

1. "setup ICE and DTLS for media, and be ready to send and receive media,
but don't send or receive media yet"

2. "send media now"

3. "receive media now"

4. "tell the remote side to send me media"


For #1 and #2 here are the best options that have been proposed so far:


A.  Add a dummy track and later call replaceTrack on the sender later;

var sender = PeerConnection.addTrack(new MediaStreamTrack("audio"));
// wait
sender.replaceTrack(track);

B.  Create an RtpSender without a track and clal replaceTrack on the sender
later.

var sender = PeerConnection.createRtpSender("audio");
// wait
sender.replaceTrack(track);



For #3, these are the options I know of:

C.  Set a new RtpReceiver.active:

var receiver = ...;  // Comes out of PeerConnection.onaddtrack
receiver.active = false;
// wait
receiver.active = true;

D.  Just don't hook up the track to an <audio>, so you don't play it out.

var receiver = ...;  // Comes out of PeerConnection.onaddtrack
// wait
attachToAudioTag(receiver.track);



For #4, these are options I know of:

E.  Setting RtpReceiver.active triggers PeerConnection.onnegotiateneeded,
and changes SDP from "a=sendonly" to "a=sendrecv".

F.  Nothing.  We don't actually need an API point.  It's up to the
application to signal to the remote side "Please send me media now".  We
don't need to use SDP to do that, and the PeerConnection state machine
doesn't need to be involved.

Technically, this means the remote side would deactivate/activate on its
RtpSender object.  But we don't need to add another API point to do that.



I think:

B > A, because an RtpSender without a track seems cleaner than a dummy
track. But I could live with A.

D > C, because we don't have to add anything.  I think we shouldn't add
RtpReceiver.active.

F > E, because we don't have to add anything.  I think that even if we add
RtpReceiver.active, it should not cause an SDP renegotiation, just like
RtpSender.setParameters doesn't.


Commence discussion :).