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

[Robin Raymond <[e-mail]>]

Actually - have quick demos interop with some SIP device doesn't prove 
using SDP is a practical decision. All that proves is that it's good 
enough to whip up a quick demo. That 80-20 rule definitely applies here 
(i.e. 80% is easy and 20% is really hard or impossible).

It would be just as easy to package all that information up into your 
own "SDP" via a wrapper without having to incorporate SDP into the 
browser. There are serious long term consequences to using SDP.

I don't really here a single person saying SDP is good. The argument 
pro-SDP seems to be:
1) Easier for the JS developer
2) Compatibility with existing SIP devices
3) Too late - we've all agreed to do something bad so let's continue to 
do it badly

To my response:
1) Yes, if all you desire is a quick hack demo, sure, it's easier. But 
it's not really any harder if we have objects that allow control over 
all the properties too. Besides, it wouldn't be long before anything 
that was more complicated would be quickly wrapped and that issue 
completely goes away even if it were complicated. Besides, what is 
really needed? A list of codecs and a list of ICE candidates for basic 
interop? Really - is that truly "hard" to get a basic demo working?
2) I call bull. If anything, it makes it even more incompatible, not 
less since now we have each browser introducing it's own SDP with it's 
own version with its own feature sets. With a lower level API, you could 
control exactly what the produces/expects for SDP that you generate from 
JavaScript and you'd have greater compatibility. But the way it is now, 
we are moving towards a "SBCs will fix it" model.
3) That seems like a rather poor argument to me. There is not a single 
company reliant on this technology for it's income stream yet many 
looking forward to its potential. But we can't innovate much because the 
bottle neck is this SDP offer/answer model. This seems very short 
sighted. People dump old technology when the cost of moving forward with 
it is greater than the sum of replacing it. SDP offer/answer's future 
costs will be massive but it's hard to see because nobody is paying for 
it --- yet. Worst, the longer this persists the harder it will be to 
change because now it won't be just that we "agreed" but it will be that 
we "agreed, and now there is so much reliant upon it". There won't be 
any "fixing it later" as it "works for us". Unless people are willing to 
deprecate it now, this beast will be upon the world for the next 
generation of communications.

The arguments against SDP are strong:
1) Do everything monolithic exchange format - it's not an elegant API 
where all the knobs can be tweaked/controlled.
2) Each change requires a round trip to the remote party with a response 
before the next change can happen.
3) Simultaneous changes cause a conflict - according to the standard 
(regardless if it causes a real world errors or not)
4) Compatibility issues between SDPs will require parsing/rewriting of 
the SDPs anyway (it already happens CONSTANTLY in the SIP world already 
via SBCs)
5) Requests to "change" things are not simple API or property changes 
but instead serialized (and to the point above, a round trips for the 
SDP to the remote party too)
6) Unneeded + legacy
7) Breaks, hinders other models that do NOT require offer answer. It's 
clear by Microsoft they don't use offer/answer in Skype and I can say we 
do not use offer/answer in Open Peer and it's so much 
simpler/flexible/better because of it
8) Brittle - Simple changes in the SDP can break devices that are 
reliant on exact formatting
9) Creates silos - if we don't have compatible SDP, we can't communicate 
unless we introduce some arbitrator to fix it
... and I could go on and I've ranted on the subject before on webrtc.is ...

I'm sure anyone could try to argue a point here or there but the overall 
picture is that it's just BAD and really BAD long term. I'm not 
political which is why I don't post much. Frankly, the decision to use 
SDP made me not get involved much. What's the point in layer a bunch 
more features/specifications upon a bad foundation?

Wrapping an API around SDP to hide it still means that SDP offer/answer 
is at it's core and does little to fix the original problems (as they 
say, lipstick on a pig). Most of the problems still exist even if it 
were put inside a nicer API. We will be writing out own "nicer" API that 
dissects the SDP and extracts out of it and generates new ones on the 
remote side regardless if the browser does it for us, but it doesn't 
negate the problems of SDP -- needing true control over the RTC/media 
engines -- especially without offer/answer. If SDP has to be parsed, 
mangled, serialized or sent over the wire from JavaScript to do anything 
beyond the basic calling then it's the wrong choice. Offer/answer round 
tripping is equally bad (if not even worse).

SDP is clearly the WRONG technical choice. It was wrong from the start 
but I think there was a great misunderstanding that it was required or 
SIP wouldn't be compatible with WebRTC. Since the strong majority at the 
table were SIP guys because they are the "established" industry it 
became the 'way to do it' despite how horrible it is for the future. So 
here we are today...

-Robin



> Enrico Marocco <mailto:[e-mail]>
> 18 June, 2013 5:21 AM
>
> I won't comment on whether SDP was the best option to begin with, but
> the fact that every other person on this list has a demo WebRTC app
> that, with little to no manipulation, achieves some kind of *basic*
> interoperability with legacy SIP proves that it was in fact a somewhat
> practical one.
>
> A whole different story is whether we want to tie ourselves to the
> complicacies of multiple SDP renegotiations for any non-obvious use case
> that may or may not exist today in other that slideware form, but that
> certainly still have to show any decent level of interoperability.
>
> Enrico
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> Iñaki Baz Castillo <mailto:[e-mail]>
> 18 June, 2013 4:31 AM
> 2013/6/18 Peter Thatcher<[e-mail]>:
>
>> 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.
>
> And do we really need SDP for that? mandatory?
>
>
>> It would look something like this
>> (forgive me if I got the SDP slightly wrong;  it's easy to get wrong):
>>
>> v=0
>
> Unneeded line v.
>
>
>> o=- 697639972863421376 2 IN IP4 127.0.0.1
>
> Unneeded line o.
>
>
>> s=-
>> t=0 0
>
> Unneeded lines s and t.
>
>
>> m=application 1 DTLS/SCTP 5000
>
> Why is this required at all?
>
>
>> c=IN IP4 0.0.0.0
>
> Anti-useful c line.
>
>
>> a=mid:transport
>
> What else can it be?
>
>
>> 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
>
> Finally we get 3 useful fields (related to ICE and encryption). And
> are we going to mandate SDP O/A for this? really? I really hope NOT.
>
>
>
>
>> 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).
>
> And WHY do we need to *mandate* SDP for that? Why don't we define a
> IceData object, something that can be serialized in JSON to be sent to
> the remote peer in any custom way? Why should we deal with blob
> strings in an old-school format?
>
>
>
>
>> 10 lines of SDP just to setup a transport isn't quite such an abomination,
>> is it?
>
> Yes, because we don't need those 10 lines, but just 3 string values.
>
>
>
>
>
>
>
>
>> 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.
>
> And what is the advantage of mandating usage of SDP for the transport
> (over letting the user communicate it to the browser via API by
> passing some JS object?).
>
>
>
>
> Regards.
>
>
> --
> Iñaki Baz Castillo
> <[e-mail]>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> Peter Thatcher <mailto:[e-mail]>
> 18 June, 2013 1:27 AM
>
>
>
> On Mon, Jun 17, 2013 at 2:56 PM, Martin Thomson 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     On 17 June 2013 12:26, Peter Thatcher <[e-mail]
>     <mailto:[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
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> Martin Thomson <mailto:[e-mail]>
> 17 June, 2013 5:56 PM
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> --Martin
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> Peter Thatcher <mailto:[e-mail]>
> 17 June, 2013 3:26 PM
> 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.
>
> 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.
>
>
> 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.
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb