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

[Peter Thatcher <[e-mail]>]

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