Re: Another proposal: splitting RTCConnection into IceTransport and DtlsTransport.

Was hoping you would tackle this. Great design and thanks again for the
contribution!

/Erik

*Erik Lagerway <http://ca.linkedin.com/in/lagerway> |
*Hookflash<http://hookflash.com/>* |
1 (855) Hookflash ext. 2 | Twitter
<http://twitter.com/elagerway> | WebRTC.is Blog <http://webrtc.is/> *


On Thu, Jan 9, 2014 at 10:53 AM, Peter Thatcher <pthatcher@google.com>wrote:

> 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.
>