Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

To be fair, that use case should already had been resolved much more 
easily long time ago:

<video src="rtsp://yourcameraip">

Best regards
Sergio

El 18/06/2013 17:43, Matthew Kaufman (SKYPE) escribió:
> It isn't SDP that's the problem. It is the offer/answer semantics.
>
> Here's a real simple example of the problem: If I have a web browser 
> that can do RTP A/V, I should be able to send a form post or XHR to 
> ask my security camera to start streaming me RTP video to a specific 
> address and port. The browser doesn't need to do ICE connectivity 
> tests, because it is only going to receive video.
>
> I should be able to use a few lines of JavaScript to initialize the 
> UDP/RTP receive port and wire it to a video window, set up the codec 
> mapping, and ask it for its local address and port so I can tell the 
> camera where to send things. But that isn't how it works at all. 
> Instead I need to run, in JavaScript, the entire offer/answer exchange 
> from the security camera's point of view, extract the relevant 
> information from the SDP blob, and then send it off. (Never mind that 
> I also need to have DTLS-SRTP added to my camera, even though I'm 
> sending unencrypted RTP from it all over the rest of my LAN to other 
> receivers that aren't browsers)
>
> Same thing if I have a two-way radio system that can talk RTP and ICE 
> and which has its own proprietary way of setting up connections... 
> again, need to write a whole SDP parser *and* state machine to run the 
> "fake" offer/answer exchange.
>
> Pain. In. The. Ass.
>
> Matthew Kaufman
>
> ------------------------------------------------------------------------
> *From:* rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of 
> Iñaki Baz Castillo [ibc@aliax.net]
> *Sent:* Tuesday, June 18, 2013 7:48 AM
> *To:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] Proposal for a JS API for NoPlan (adding 
> multiple sources without encoding them in SDP)
>
> 2013/6/18 Robin Raymond <robin@hookflash.com <mailto:robin@hookflash.com>>
>
>     SDP is clearly the WRONG technical choice. It was wrong from the
>     start but I think there was a great misunderstanding that it was
>     required or SIP wouldn't be compatible with WebRTC. Since the
>     strong majority at the table were SIP guys because they are the
>     "established" industry it became the 'way to do it' despite how
>     horrible it is for the future. So here we are today...
>
>
>
> Dear WG Chairs,
>
> With all due respect, IMHO there is enough material to reopen the "SDP 
> or not SDP" debate so I would like to request it to the WG.
>
> I would also appreciate that those in favour of mandating SDP as the 
> core communication for WebRTC explain their rationale again (given the 
> number of arguments against SDP and the frustration SDP is causing), 
> and also that they give arguments and responses to all the SDP related 
> issues exposed in this thread, that are nicely summarized in this mail:
>
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html
>
>
> Really thanks a lot.
>
>
> -- 
> Iñaki Baz Castillo
> <ibc@aliax.net <mailto:ibc@aliax.net>>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb