Completely agree with Peter here. SDP-based systems shouldn’t be any more important than H.323 or Jingle based systems, or whatever else might be out there. What I don’t understand is why, with such strong and valid feedback from so many people trying to use the API that exists at present, any WG member or chair would be suggesting to Peter that the resolution of this class of problems must be deferred until “after 1.0”. If the chairs actually said that (and I can’t find it in any searches I’ve done of public lists), then I think we have a problem. If the developers feel like no matter what they say, they can’t make a positive impact on the specification that is produced by the WG, then we *definitely* have a problem. Don’t we? Matthew Kaufman From: Peter Thatcher [mailto:pthatcher@google.com] Sent: Friday, July 19, 2013 6:01 PM To: Cullen Jennings Cc: Martin Thomson; Adam Roach; Iñaki Baz Castillo; Matthew Kaufman (SKYPE); <rtcweb@ietf.org>; public-webrtc@w3.org Subject: Re: On babies and bathwater (was Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface) The logic of how to talk to the video conferencing system doesn't need to be backed into the browser. If the API provides enough control the JS, the web app can contain the logic to talk to the video conferencing system. I know I'm going to start sounding like a broken record, but you brought up video conferencing systems as an example, so I will say it again: there are are video conferencing systems that don't use SDP for signalling. For example, there are video conferencing systems that use Jingle for signalling. Would I expect the logic of how to speak to that video conferencing system to be baked into the browser? No, I think I'd prefer it to be built into a web app built on top of a good API. Why should SDP-based video conferencing systems be treated special?
Received on Saturday, 20 July 2013 03:42:38 UTC