Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

[Peter Thatcher <[e-mail]>]

On Wed, Jun 19, 2013 at 11:01 AM, Matthew Kaufman (SKYPE) <
[e-mail]> wrote:

>  Fighting the offer/answer machinery in the browser is always possible,
> but never easier.
>
>  I want an API that let's me tell the browser what to do, not engage in
> an argument with it until it is beaten into submission. I think an API that
> let's me tell the browser what to do will then also be much easier to
> extend to give me *more* control.
>
>
My recent "NoPlan JS API" give you precisely that, at least for media
streams (not for transports).  But it's an incremental improvement, which
you have categorically rejected.


>  As an example, putting A and V over the same transport... Could be one
> more JS API, instead of a discussion at MMUSIC about how to encode that in
> our must-use SDP, followed by JS code I need to write to argue with the
> browser when it offers that but I want to turn it off, or vice versa.
>

Again, my "NoPlan JS API" give you exactly that, at least in theory.  No
one has implemented it yet :).


>
> Matthew Kaufman
>
> (Sent from my iPhone)
>
> On Jun 19, 2013, at 9:50 AM, "Peter Thatcher" <[e-mail]>
> wrote:
>
>   I asked "is there something that can't be done without sufficient SDP
> munging"?  You answered "I have something that can be done with sufficient
> SDP munging".   OK.  But do you have something that *can't* be done with
> SDP munging?
>
>  If there's nothing that can't be done with SDP munging, then this whole
> thread boils down to "give us an API that has the same amount of control as
> the current one, but without requiring SDP munging to do advanced things".
>  And if that's is what is desired, then at least it can be clear and
> concise.
>
>
>
>
> On Wed, Jun 19, 2013 at 9:36 AM, Matthew Kaufman <[e-mail]>wrote:
>
>>  I provided a use case that, unless one wants to write a bunch of
>> SDP-munging JS state machine cannot be done.
>>
>>  The problem is that such use cases are either 1) ignored or 2)
>> dismissed because of course if one writes said JS, they are possible with
>> the current API
>>
>> Matthew Kaufman
>>
>> (Sent from my iPhone)
>>
>> On Jun 19, 2013, at 9:28 AM, Peter Thatcher <[e-mail]> wrote:
>>
>>    I might be wrong, but I tried reading and understanding your whole
>> email, and it seems to come down to "I don't want to use SDP or a different
>> (JSON) form of SDP".  That's a fine thing to request, but why don't you
>> just say that?  It would save everyone a lot of reading and confusion to be
>> more concise.
>>
>>   Or, if you have specific things you'd like to do but can't, what are
>> they?  I think that would help me, and others, understand more easily.  Use
>> cases would be helpful.
>>
>>  On Wed, Jun 19, 2013 at 6:58 AM, Robin Raymond <[e-mail]>wrote:
>>
>>>
>>> The trouble is not that we can choose to send whatever we want over the
>>> wire. I know we can. If the WebRTC API is left with SDP as it stands, I'll
>>> dissect the SDP from the browser, reinterpret and reconstruct on the SDP on
>>> the remote side. That is NOT the issue.
>>>
>>> The summary of what I want/believe:
>>> 1) I want as close to raw access to RTP/ICE streams, media, sources,
>>> outputs, codecs as viable. Obviously doing the actual transmission,
>>> encoding/decoding from JS is not feasible (yet), nor is secure [ICE
>>> must occur for mutual agreement to exchange data between peers], but having
>>> controls for how these components are wired together is extremely feasible
>>> from JS and would allow immensely powerful apps to be produced from JS.
>>>
>>
>>  What would you like to do that you can't do via SDP right now?  You
>> said this isn't just about working through SDP.  But I don't see anything
>> concrete you can't do right now with sufficient SDP
>> parsing/building/munging/hackery.
>>
>>
>>
>>> 2) I don't want my primary interface to control media/RTP engines to be
>>> via obtaining or providing SDPs to the browser (or any alternative
>>> serialized format); especially given that SDP requires a round trip
>>> offer/answer to the remote party to affect change (e.g. it's entirely
>>> possible to do that stateless and one-sided). The SPD interface API is a
>>> monolithic do-everything serialized format to control an engine but
>>> extremely badly/poorly/short sighted (regardless if it is SDP or whatever
>>> instead), and it's wholly unneeded.
>>>
>>
>>  Short summary: "I don't want to use SDP".  Right?
>>
>>  3) I don't want a replacement for SDP with another more "pretty" format
>>> like JSON.
>>>
>>
>>  Short summary: "I don't want to use SDP or a different syntax for SDP".
>>  Right?
>>
>>  4) I want no specified requirement from the browser to have any
>>> particular form of media negotiation API requirement what-so-ever
>>> (regardless if I can opt to substitute with my own format on the wire or
>>> not)
>>>
>>
>>  Short summary: "I don't want to use SDP or a different syntax for SDP".
>>  Right?
>>
>>
>>> 5) Using SDP with offer/answer build into the browser binary is a
>>> horribly BAD technical choice (even for SIP folks) and must be stopped,
>>> see: http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html
>>>
>>
>>  Short summary: "I don't want to use SDP".  Right?
>>
>>
>>>
>>>
>>> I too want to understand the rational for keeping something as bad as
>>> SDP with offer/answer as the primary mechanism for controlling the media
>>> components and interaction to those component and more importantly, I'd too
>>> would like to open debate to agreeing or not to provide a lower layer API
>>> rather than a media negotiation API as a complete substitute alternative to
>>> SDP with offer/answer.
>>>
>>> If we can agree that it's far superior to have a lower level media/RTC
>>> component API rather than a media negotiation API, then we can propose what
>>> that API could look like (and there are people who have already have
>>> starting proposals). I'd throw my hat in the ring to propose such and API
>>> if necessary as I've written such engines from scratch before. But I don't
>>> want to waste time proposing ore reviewing such an API which will be
>>> summarily dismissed because people are so stuck on requiring a media
>>> negotiation API built into the browser binary, and specifically SDP with
>>> offer/answer in this case.
>>>
>>
>>
>> The WG may dislike and reject your proposal, but there's a bit of truth
>> to the old mathematically incorrect sports adage "you miss 100% of the
>> shots you don't take".
>>
>>
>>  Anyone who argues that they need/want that simple SDP media negotiation
>>> API must understand that a lower level API would allow a wrapper API to
>>> produce the same WebRTC API the have today but be built entirely from
>>> JavaScript
>>>
>>
>>  That depends on how low-level you go.  If you go too low-level, it
>> becomes infeasible to do things correctly and performantly in JavaScript.
>>
>>
>>>  upon a lower level API. Thus they can have their "just add-milk"
>>> baking API. But those of us who need control of the raw ingredients beyond
>>> the "just add milk" can still innovate.
>>>
>>> -Robin
>>>
>>>
>>>   <compose-unknown-contact.jpg>
>>>  Peter Thatcher <[e-mail]>
>>> 19 June, 2013 2:49 AM
>>>    Correct my if I'm wrong, but the API already leaves what goes over
>>> the wire completely up to the JS app.  So we couldn't re-open a debate of
>>> "SDP or not SDP" for the wire format, because there's nothing to debate.
>>>  We already decided it would be left to the JS to decide.  The only thing
>>> left to debate is the API.
>>>
>>>  Or am I wrong?
>>>
>>>
>>>
>>>
>>>   _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>    <compose-unknown-contact.jpg>
>>>  Christer Holmberg <[e-mail]>
>>> 19 June, 2013 2:34 AM
>>>    Hi,
>>>
>>> We need to be very clear what we talk about, or some people are always
>>> going to be confused :)
>>>
>>> So, AFAIK, the discussion is about SDP O/A usage in the API, only in the
>>> API, and nowhere but the API.
>>>
>>> Whatever people us on the wire is outside the scope.
>>>
>>> Right?
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>> Sent from *Windows* using *TouchDown* (www.nitrodesk.com)
>>>
>>> -----Original Message-----
>>> *From:* Peter Thatcher [[e-mail]]
>>> *To:* Martin Thomson [[e-mail]]
>>> *CC:* [e-mail] [[e-mail]]
>>> *Subject:* Re: [rtcweb] Requesting "SDP or not SDP" debate to be
>>> re-opened
>>> Martin, you're right; that was overly harsh of me.  Adam, I apologize.
>>>  I'll be civil in the future.
>>>
>>>
>>>
>>>   _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>    <compose-unknown-contact.jpg>
>>>  Peter Thatcher <[e-mail]>
>>> 19 June, 2013 1:36 AM
>>>    Martin, you're right; that was overly harsh of me.  Adam, I
>>> apologize.  I'll be civil in the future.
>>>
>>>
>>>
>>>   _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>     <compose-unknown-contact.jpg>
>>>  Martin Thomson <[e-mail]>
>>> 18 June, 2013 6:25 PM
>>>     I agree with Peter, except for this bit:
>>>
>>> Adam is much harder to confuse than you think, or than he professes.
>>>
>>> Speaking of burning it all down and starting over. If you want a
>>> house-related analogy, that's not quite correct. It's refusing to
>>> build an extension because the old house, while legally fit for
>>> habitation, is falling down around your ears. Since you only need
>>> foundations, it's not that big a job (though I'll grant you that it's
>>> bigger than many people realize, even with that smaller scope).
>>>  _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>     <compose-unknown-contact.jpg>
>>>  Peter Thatcher <[e-mail]>
>>> 18 June, 2013 6:16 PM
>>>     Adam, I think you're confused.  As Ted pointed out, there are two
>>> different uses of SDP: 1.  as a control surface, 2. as a message format for
>>> signalling.  SDPNG was trying to replace SDP for #2.  While I believe this
>>> thread was started entirely focused on #1.  So you're talking about
>>> different things.
>>>
>>>  So far the only time spent on trying to replace or avoid SDP for #1
>>> has been "comment 22", and to a lesser extent the proposal I just made for
>>> adding 2 methods to PeerConnection (createLocalStream and
>>> createRemoteStream).   I think it's incorrect to conclude that we should
>>> never try to improve #1 just because other in the past failed to replace
>>> #2.  They're very different.
>>>
>>>  I also don't think we should burn down WebRTC and start over, but
>>> despite what some seem to think, we don't have to choose between "burn it
>>> down" and "never improve it".  There are many options other than the two
>>> extremes.
>>>
>>>
>>>
>>>  By the way, a gentle reminder: SDP is not the only way to do #2.  I
>>> work on a rather large system almost entirely build around Jingle, without
>>> a hint of SDP, and it works just fine.  Much better than SDP would have, I
>>> think.  Just because SDPNG didn't work out doesn't mean there will never be
>>> any way other to do signalling than SDP.
>>>
>>>
>>>
>>>
>>>   _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>>
>>     _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>      _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>