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

It is acceptable to me that some features of ORTC API won't be available when shimming over WebRTC 1.0.  

Obviously, one way to reduce the scope of the issue is to introduce concepts such as RtpSender/RtpReceiver and  IceTransport/DtlsTransport concepts into WebRTC 1.0.   

But that is a decision for the W3C WEBRTC WG. 


On Jan 10, 2014 6:40 AM, "Robin Raymond" <robin@hookflash.com<mailto: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


[cid:part1.07010103.06080100@hookflash.com]
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.