Re: Feedback / status

On Fri, Dec 6, 2013 at 8:35 AM, Roman Shpount <rshpount@turbobridge.com>wrote:

> Few questions/comments:
>
> Plumbing of objects:
>
> a) Would this allow plain RTP and SCTP? If we can wire plain transports,
> can we wire SCTP and RTP directly to ICE?
>

I think the answer to that is "no" for browsers.  DTLS would still be
required.  Mobile apps and other endpoints could, of course, do whatever
they want.


> b) There is a current discussion going on about changing ICE consent with
> DTLS consent. How would this work in ORTC if DTLS is optional?
>

> In general, ability to remove DTLS from the transport path would cause a
> substantial security debate. It might be better to have ICE/DTLS transport
> and provide new replacement transports in the future when they are
> available and deemed secure.
>
>
Again, I think the answer to that is "DTLS is not optional".​​



> Sockets: I am not thrilled with the name (endpoint might be better) but I
> think the concept is sound. I prefer this to fork/clone since it is closer
> to what in happening under the hood and provides the more accurate
> representation of what's going on.
> ​
>
Shims: Having a shim on top of PeerConnection is nice as a proof of concept
> but it always seemed of little value to me. Having a PeerConnection shim on
> top of ORTC always seemed more important since it proved that all the same
> functionality can be provided via ORTC.
>
> P.S. You ended up with two number 3 topics....
>
> _____________
> Roman Shpount
>
>
> On Fri, Dec 6, 2013 at 10:31 AM, Robin Raymond <robin@hookflash.com>wrote:
>
>>
>> We have received some feedback / ideas on the current ORTC API that I
>> wanted to run past this list based upon the last specification published.
>>
>>
>> 1) plumbing of objects
>>
>> One of the main ideas that have been asked is if this API can become more
>> of a wire plumbing API. Meaning instead of hiding the ICE transport or DTLS
>> transport you could plumb them together. This is valuable for some features
>> like having hot swappable backup transports, etc.
>>
>> They are not asking for ability to control packet level things as
>> possible with CU-RTCWeb but more "attach this sender to that object" kind
>> of stuff.
>>
>> The change proposed is instead of having a "RTCConnection", you'd have an
>> ICE transport and a DTLS transport and you associate the two objects
>> together and optionally re-wire the plumbing as you see fit. Likewise you'd
>> have an SCTP object you'd wire to the transport where you could create data
>> channels. The same object separation would apply to RTC sender / receiver
>> doohickies as described below.
>>
>>
>> 2) sender / receiver doohickies alignment
>>
>> Another issue is alignment with the current "sender / receiver
>> Doohickies" in the 1.0. We could easily make RTC sender / receiver objects
>> where you can wire their RTP stream outputs to the DTLS transport used. I'd
>> like to see us move towards a common ground where possible (without
>> triggering a hidden SDP negotiation obviously). One important note is to
>> ensure we never add sender-exclusive controls to the receiver's doohickie
>> thus allow a developer to use their own negotiation patterns (including but
>> not limited to SDP).
>>
>> The change proposed is instead of adding / sending / receiving tracks
>> directly from the "RTC Connection" you would create rtc sender / receiver
>> objects, change any default parameters like SSRC and wire those objects to
>> the DTLS transport.
>>
>>
>> 3) socket objects - needed?
>>
>> There is still some debate if we need an "socket" level object or not
>> that would be fed into the ICE transport object. As defined in ORTC, A
>> "socket" object (perhaps poorly named) is an object that listens on all
>> local socket interfaces for a given port and establishes virtual sockets on
>> remote TURN transports to provide a list of local ICE candidates for the
>> ICE transport.
>>
>> One factor in this debate is that allowing for forking scenarios you
>> either need "socket"-like object to share across ICE transport or you need
>> the ICE transport to have a "clone()" or "fork()" method where a hidden
>> shared "socket" conceptual object is shared. I'm not sure which is more
>> desirable considering the semantics of "clone()" / "fork()" don't really
>> apply exactly 100% perfectly since any remote candidates on a forked ICE
>> transport would not be cloned/forked to the copy as well. This could be
>> argument to maintain the "socket" object, although perhaps making it
>> auto-created for the simple case if the ICE transport is not provided one
>> externally.
>>
>>
>> 3) capabilities / simple negotiation helpers - need some work
>>
>> As generally noted before, we still have to work on the capabilities,
>> constraints and negotiations. Anyone with proposals in this area are
>> welcome but some ideas will be proposed in the next ORTC update.
>>
>>
>> 4) rtc track descriptions with multiple SSRCs
>>
>> There is a desire to allow for various layering, FEC like features by
>> describing each SSRC inside the track descriptions.
>>
>>
>> 5) implications of plumbing on shims
>>
>> When the ORTC API was originally proposed, one of the key tenants was
>> being able to have a dual shim with maximum compatibility possible. There
>> was a desire to have a PeerConnection 1.0 to ORTC shim and an ORTC to
>> PeerConnection 1.0 shim. This would allow ORTC to work on top of a current
>> PeerConnect 1.0 implementation (as best possible simulated) and
>> PeerConnection 1.0 API on work top of ORTC API to provide SDP like
>> negotiation API backwards compatibility with the current 1.0 spec (as much
>> as feasible or standardized).
>>
>> If we allow for plumbing/wiring feature, these 'wiring' features may not
>> be possible it make the ORTC API shim work on top of the PeerConnection 1.0
>> API since these inner features are likely hidden even beyond the SDP
>> manipulations possible.
>>
>> Questions:
>>
>> How important is having an ORTC API where every feature supported must
>> work on 1.0 API?
>>
>> Can we live with a shim where some features are supported but other
>> things are just not possible? (Meaning many use-cases will work but some
>> things like hot-swapping DTLS to a new ICE transport) would not and these
>> would be labelled "known limitations".
>>
>>
>> If anyone has any feedback (or request for clarification) on any of these
>> points, please provide them!
>>
>> Regards,
>> Robin
>>
>>
>>
>