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

I agree with Martin.  It seems it would be kind of silly to limit ORTC to
only allowing things that WebRTC 1.0 can do.  I think an imperfect shim is
better than an artificially limited API.




On Fri, Jan 10, 2014 at 8:19 AM, Martin Thomson <martin.thomson@gmail.com>wrote:

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