Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

[Peter Thatcher <[e-mail]>]

On Mon, Jun 17, 2013 at 2:56 PM, Martin Thomson <[e-mail]>wrote:

> On 17 June 2013 12:26, Peter Thatcher <[e-mail]> wrote:
> > Yes, I was expecting you to be more supportive.  I'm surprised out how
> your
> > want "all or nothing".  I'm afraid if our options for a clean API are
> all or
> > nothing, we'll just end up with nothing.  I'd prefer to try incremental
> > improvements to word toward (eventually) a clean API.
>
> Yes, I apologize if the language seemed strong, but I stand by those words.
>
> The problem that I see with this, and it is a problem with any
> incremental approach, is that it produces two very different
> interaction models for things that are approximately the same
> fundamental operation.
>
> That is, when I add the first video track to a session I perform one
> set of actions.  Then, when I add subsequent tracks, it's different.
>
>
I don't thing we have to have two different sets of actions.  If a JS app
chooses, it could use createLocalStream and createRemoteStream for all of
its streams, and only use SDP for setting up the transport.  For example, I
could choose to write JS that would setup one transport with one call to
createOffer/setLocalDescription/setRemoteDescription (ignore trickle ICE
and ICE restarts for them moment) and bundle all media over it.  That means
the SDP is really just used as a way to tell the browser what ice ufrag,
ice pwd, and DTLS fingerprint to use.  It would look something like this
(forgive me if I got the SDP slightly wrong;  it's easy to get wrong):

v=0
o=- 697639972863421376 2 IN IP4 127.0.0.1
s=-
t=0 0
m=application 1 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=mid:transport

a=ice-ufrag:tEP42he9r6LycvmM
a=ice-pwd:cKJLuvHy9pas9rdezUZB9xet
a=fingerprint:sha-256
EC:E0:95:43:B7:01:49:8B:BC:21:CC:41:7F:10:FD:92:28:B8:F8:41:07:70:77:7D:7C:47:92:30:79:C4:95:9C


Ignoring ICE candidates and restarts, that's all the SDP what would be
needed for the whole PeerConnection (one for the local and one for the
remote).  The first set of streams has the same actions as the 100th set of
streams, if the JS chooses.

10 lines of SDP just to setup a transport isn't quite such an abomination,
is it?


This also has all the purported drawbacks of comment 22 with respect
> to usability, whatever they are.  There must have been some because I
> got a lot of heat about that when we discussed it.
>
> > Do you think it is impossible to work toward a clean API in an
> incremental
> > approach?  If you think it's possible, I'd like to hear your thoughts on
> > how.
>
> The fundamental problem in WebRTC is the Offer/Answer semantics in the
> API.  That's hard to remove now.  I can't see an incremental change
> that would remove that, and that's every bit as much of a problem as
> having to deal with SDP.  That's how we got to comment 22.
>

There are two places we currently have offer/answer: 1.  To setup the
transports.  2.  To define the streams.  And once upon a time, there was
going to be 3.  To define the data channels.  We were able to prevent #3
and just have data channel be defined in terms of createDataChannel, and
not in terms of SDP.  That was good, was it not?  What I'm proposing is
that we do something similar for audio and video streams (#2).  That way,
all that you need to use SDP for would be #1 (to setup the transports).
 And someday, we might be able to improve that as well (perhaps a future
.createTransport method).



>
> I know that you wanted to do some sort of object representation of
> SDP.  That can be done incrementally by adding to
> RTCSessionDescription, or by replacing it entirely, but it doesn't
> really go to the core of the problem.  If you were willing to tolerate
> the fact that there would be two code paths, two control surfaces that
> effectively did the same things.
>



>
> > By the way, these API additions would greatly minimize the amount of SDP
> > editing necessary for JS clients that don't use SDP for signalling.  And
> > later incremental improvements could reduce it further.  Also, it's no
> > longer necessary to do offer/answer for adding tracks.  It's only the
> intial
> > PeerConnection setup that needs to do Offer/Answer.  So, it doesn't
> inherit
> > all the problems quite as much as you described.  It may be slightly
> > abominable, but I certainly consider it less abominable than the SDP
> editing
> > necessary without it.
>
> If I am forced to do SDP, I'd rather not have something else as well
> unless that something else is getting me something concrete.  What you
> are proposing does too little to advance a cleaner API model to
> justify the extra overhead that it introduces.  It doesn't tackle the
> hard problems.
>

You're not forced to do SDP, except for the transports.  For defining the
streams, you can avoid SDP altogether.  As a WebRTC JS app developer, I
know I would find working with this API much better than working with SDP
munging.


>
> I appreciate the philosophy behind no-plan, which is not a non-plan in
> any sense.  It addresses a concern that we (unfortunately) didn't
> really touch on in the MMUSIC call this morning.  However, the
> requirements of the-not-no-plan could be far more elegantly addressed
> within the constraints of the current API without adding all those
> extra description bits.
>

I'm a bit confused.  Do you consider changes to SDP more elegant than
dictionaries like MediaStreamTrackDescription?  I would find that somewhat
ironic.  Or are you suggesting there's a way I can simplify all the
"description bits".  If there's a specific way I can simply it to make it
better, I'd lover to hear it.


And, thanks for your feedback.  I hope my response about not requiring SDP
for the first streams helps clarify.


>
> --Martin
>