Re: Teleco Integrators vs Web Developers vs Browser Implementers

On Fri, Jun 28, 2013 at 3:02 PM, Roman Shpount <roman@telurix.com> wrote:

>  The functionality I need to implement (as a developer or as teleco or as
> implementer) is to capture audio or video and send it to the remote party.
> Or alternatively I want to receive audio or video from remote party and
> play it out locally.
>

For what it's worth, the high level abstraction you put forward is pretty
much what I believe the rtcweb group sees as the problem space:  plumb a
local media source or application data stream so that it is played out/used
locally or sent across a network to a peer, who must then be able to use it
in a way understood by the application.

But, as the case is so often, there are many details, and some have them
have devilled us a long while.   Making sure you are talking to someone who
is willing to listen, for example, involved using the ICE mechanisms to
establish consent freshness.   That may well mean we have to use ICE even
when IPv6 or un-natted candidate addresses are available.   The local media
source's output must be encoded in a way so that it is understood by the
entity playing it out; that either means picking a single method for that
encoding, setting up a negotiation mechanism, or losing some significant
period of time.  That's given rise to long discussions of codec licensing.
Sending out the stream to a remote party necessarily involves putting the
results of the encoding into a series of packets on the wire in a format
that is sufficiently likely to get past NATs and Firewalls (possibly with
the help of ICE) that the application works.  That got us RTP over UDP and
RTCP, which incidentally got us at least a vague promise that we'd be able
to handle the worst effects of congestion (but also caused us to set up a
working group to find something better).  The list of details engendered by
those choices is, in other words,  almost as long and equally equal
devilling.

Another devilment in all of this is that we are not building a system where
we expect independent applications to be the primary users of the protocol
stack; we need to make sure that we are building for a case where a
downloaded application in a browser context does not exceed the limits
placed on it by that context.  It's a fundamental part of the model that
the JavaScript application is not as trusted part of the system as the
browser; it may be malicious and that case must be handled well.

Forgive my going off on what may seem like a tangent here, since none of
the issues I mention relate directly to offer/answer or the use of SDP.
But you appear to be about to propose an alternative API than the one the
group has built up over many months.  If you do so, please make sure that
it doesn't hand wave away the real implications of the system we're
building.   It's very easy in a situation like this to reconstruct a piece
of the system that you don't like to better suit your use cases or tastes,
but there is a very real risk that doing so may miss one of the other
aspects of the system. There have been systems other than SDP/offer-answer
that have used RTP (SAP being an early one), but at some level getting the
API to the browser is only half the battle.  If what it expresses can't be
sensibly sent across the wire by a browser without reinventing that wheel,
we are no better off and potentially a great deal worse off.

Wearing neither hats nor company swag,

Ted