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

[Robin Raymond <[e-mail]>]

+1

Exactly. Spot on.

-Robin


> Iñaki Baz Castillo <mailto:[e-mail]>
> 18 June, 2013 6:51 PM
>
>
> Very good point. That exactly what we need: something like a JS
> wrapper of the native internal media API.
>
>
>
> --
> Iñaki Baz Castillo
> <[e-mail]>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> Roman Shpount <mailto:[e-mail]>
> 18 June, 2013 6:40 PM
> One thing I got to mention is that there is already an API used 
> internally in current WebRTC implementations: Voice and Video Engines. 
> Both of those take external network transports (which also have their 
> interfaces defined and abstract ICE/SRTP/DTLS-SRTP) and allow to 
> specify what codecs to be used to receive/end media and how this media 
> is encoded. The APIs provided by these components are fairly typical 
> for the media library APIs that are used to build SIP and other real 
> time communications clients. In fact these very APIs were used by (at 
> least at some point in the past) Skype, Google Talk, Yahoo Messenger 
> and number of other real time clients. I think the best way to build a 
> usable API is to try to wrap this in JavaScript as closely as possible 
> instead of building something extremely complicated on top of them. If 
> we do this, we can create something that will make the job easier for 
> both browser developers (no complex, hard to test, code which 
> implements O/A) and for application developers (clear API level 
> contract with clear mechanisms to control things happening with the 
> media). We already know that these APIs work for what we need. Let's 
> stop trying to hide them behind O/A complexity, and then try to invent 
> multiple creative ways to implement exactly the same functions through 
> all the layers we built on top.
>
> _____________
> Roman Shpount
>
> _______________________________________________
> 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
> Adam Roach <mailto:[e-mail]>
> 18 June, 2013 4:22 PM
>
>
> Many men have died on that hill. I'm still sad about the colossal time 
> and talent sink represented by these 61 pages:
>
> http://tools.ietf.org/id/draft-ietf-mmusic-sdpng-08.txt
>
> I have no reason to think that burning WebRTC down the the ground and 
> starting over would produce a different result. If anything, the 
> issues are more contentious now than they were in 2005.
>
> /a
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb