Another proposal: splitting RTCConnection into IceTransport and DtlsTransport.

Some of the discussions in the recent W3C WebRTC WG have centered around
the idea of having "dtls doohickeys", which would exposes DTLS-specific
information.  I think this would be a good direction for the ORTC API to
take, and I think it would improve upon the ORTC API greatly to go one step
further: to add an "ice doohi
​ckey​
" as well that exposes ICE-specific information. You can think of this as
splitting the ORTC "RTCConnection" into two
​classes: IceTransport and DtlsTransport
, and refining their methods and attributes.


With
​this split
, the API could be much more flexible.  For example, a JS developer could
replace the ICE portion below the DTLS portion seamlessly, allowing for
more control over the ICE behavior.  Additionally, mobile and server-based
applications may use something other than DTLS on top of ICE, or may choose
not to encrypt at all (DTLS would remain mandatory for browsers, but not
necessarily for native apps using the same API).


I propose an API something like the following.  Since "doohi
​ckey
" isn't a good name, let's go with the names "IceTransport" and
"DtlsTransport".


[Constructor(optional RTCIceTransport)]
interface RTCDtlsTransport {
 readonly attribute RTCIceTransport       transport;
 readonly attribute RTCDtlsTransportState state;

 // Just like RTCDtlsConnectionInfo (has certificate fingerprint)
 void start(RTCDtlsParameters remoteParameters);
 void stop();

 // NOTE: We can't have a readonly attribute because apparently
 // In WebIDL, "readonly" doesn't make the returned object
 // readonly, just the refere
​n​
ce.
 RTCDtlsParameters
​getL
ocalParameters();
 RTCDtlsParameters?
​get​
R
​
​​
​​
​​
emoteParameters();

 attribute EventHandler? onstatechange;
}


// Just like current RTCConnectionOptions
[Constructor(RTCIceRole role, RTCIceOptions)]
interface RTCIceTransport {
 // Just like current RTCConnectionRole
 readonly attribute RTCIceRole           role;
 // Just like current RTCConnectionState
 readonly attribute RTCIceTransportState state;

 void gather();
 // Just like current RTCIceConnectionInfo
 void start(optional RTCIceParameters remoteParameters);
 // Start/stop if like current connect/close.
 void stop();


 // NOTE: We can't have a readonly attribute because apparently
 // In WebIDL, "readonly" doesn't make the returned object
 // readonly, just the referece.
 RTCIceParameters
​getL
ocalParameters();
 RTCIceParameters
​getR
emoteParameters();
 void setRemoteParameters(RTCIceParameters remoteParameters);

 readonly attribute sequence<RTCIceCandidate>  localCandidates;
 readonly attribute sequence<RTCIceCandidate>  remoteCandidates;

 // Just like current RTCIceCandidateInfo
 void addRemoteCandidate(RTCIceCandidate candidate);

 attribute EventHandler? onlocalcandidate;  // RTCIceCandidateEvent
 attribute EventHandler? onstatechange;
}


Here is an example of how it could be used:

// Assume we already have a way to signal. This is an example
// of  how to offer ICE and DTLS parameters and ICE candidates and
// get back ICE and DTLS parameters and ICE candidates, and start
// both ICE and DTLS.

function initiate(signaller) {
 var iceOptions = ...;
 var ice = new RTCIceTransport(RTCIceRole.controlling, iceOptions);
 var dtls = new RTCDtlsTransport(ice);
 // ... get tracks and RTP objects from other example

 signaller.sendInitiate({
   "ice": ice.
​getL
ocalParameters(),
   "dtls": dtls.
​getL
ocalParameters(),
   // ... include RTP info from other example
 }, function(remote) {
   ice.setRemoteParameters(remote.ice);
   dtls.start(remote.dtls);
   // ... start RTP senders and receivers from other example
 });

 ice.oncandidate = function(candidate) {
   signaller.sendLocalCandidate(candidate);
 }

 signaller.onRemoteCandidate = function(candidate) {
   ice.addRemoteCandidate(candidate);
 }

 ice.start();
}


// Assume we already have a way to signal and remote info signalled
// to us. This is an example of how answer with ICE and DTLS
// parameters and ICE candidates and start both ICE and DTLS.

function accept(signaller, remote) {
 var iceOptions = ...;
 var ice = new RTCIceTransport(iceOptions);
 var dtls = new RTCDtlsTransport(ice);
 // ... get tracks and RTP objects from other example
 ice.oncandidate = function(candidate) {
   signaller.sendLocalCandidate(candidate);
 }

 signaller.onRemoteCandidate = function(candidate) {
   ice.addRemoteCandidate(candidate);
 }

 signaller.sendAccept({
   "ice": ice.
​getL
ocalParameters(),
   "dtls": ice.
​getL
ocalParameters()
   // ... include RTP info from other example
 });

 ice.start(remote.ice);
 dtls.start(remote.dtls);

 // ... start RTP senders and receivers from other example
}

Please let me know if you think this is a good foundation for ICE and DTLS.
 I'm sure we can delve into other topics around ICE and DTLS (restarts,
media forking, rtcp non-mux, idp, etc) once we have a good foundation.