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

[Peter Thatcher <[e-mail]>]

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
>
>