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

[Matthew Kaufman <[e-mail]>]

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