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

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