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

I'm perfectly happy with the idea that new features can be added. That is
one of the best reasons to do this sort of work.
On Jan 10, 2014 6:40 AM, "Robin Raymond" <robin@hookflash.com> wrote:

>
> I would love to see a split-up of the "beast" RTCConnection object into
> sub-objects and expose greater state for each object and allow more of a
> pipe-line model where objects can be inter-related as appropriate.
>
> One issue / concern I have is regarding shimming. One of the reasons we
> with with the "beast" RTCConnection object was because it was still
> possible to create a 2.0 to 1.0 shim. If we start creating a real pipeline
> / object model, the pipe line wiring of the objects just won't be possible
> to shim.
>
> After some thought on this subject, my answer is "When shimming 2.0 on 1.0
> API, a basic pipeline shim will work but any fancy pipelining / rewiring of
> the object pipelines just can't work on the shim. If attempted by a
> developer using a 2.0 API shim on a 1.0 browser, an "unsupported" exception
> of some kind will be fired."
>
> I feel like creating a perfect 2.0 on 1.0 shim would be challenging at
> best because I can see features being added that 1.0 simply won't be able
> to support, but this change would definitely introduce some concepts that
> cannot be shimmed on 1.0.
>
> Is it acceptable to everyone that fancy features attempted over a 2.0 on
> 1.0 shim are just "unsupported" and thus you have limited subset of the 2.0
> capabilities on a 1.0 only browser?
>
> (FYI - I'm talking about a developer attempting to use the 2.0 ORTC API
> written as a JS shim on a browser which only supports a 1.0 PeerConnection
> API)
>
> -Robin
>
>
>   Peter Thatcher <pthatcher@google.com>
>  9 January, 2014 1:53 PM
> 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.
>
>