Feedback / status

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

Received on Friday, 6 December 2013 15:31:49 UTC