Re: Feedback / status

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

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