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

[Robin Raymond <[e-mail]>]

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.
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.
3) I don't want a replacement for SDP with another more "pretty" format 
like JSON.
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)
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

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.

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 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 <mailto:[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 <mailto:[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 <mailto:[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 <mailto:[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 <mailto:[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