W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: [SPAM] RE: VS: Teleco Integrators vs Web Developers vs Browser Implementers

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Fri, 05 Jul 2013 17:50:14 -0400
Message-ID: <51D73F96.6090906@bbs.darktech.org>
To: "piranna@gmail.com" <piranna@gmail.com>
CC: Martin Steinmann <martin@ezuce.com>, tim panton <thp@westhawk.co.uk>, Martin Thomson <martin.thomson@gmail.com>, Parthasarathi R <partha@parthasarathi.co.in>, Christer Holmberg <christer.holmberg@ericsson.com>, Iņaki Baz Castillo <ibc@aliax.net>, Robin Raymond <robin@hookflash.com>, Roman Shpount <roman@telurix.com>, Adam Bergkvist <adam.bergkvist@ericsson.com>, Ted Hardie <ted.ietf@gmail.com>, "public-webrtc_w3.org" <public-webrtc@w3.org>, Eric Rescorla <ekr@rtfm.com>
On 05/07/2013 5:16 PM, piranna@gmail.com wrote:
>> The primary application is voice and video at least in my book
> I've always find this the most annoying point of WebRTC. Why so much
> focus on audio & video relegating DataChannels to a second place
> (almost a year to start having a specification and some
> implementations!). Would it be easier and simpler to implement the
> audio & video support directly over the DataChannels, maybe requiring
> them to be not reliable? Also, developing the API from this point of
> view it would be a really simple one. I think that focusing so much on
> audio & video and on media in general it's the reason the API is so
> much oriented to SDP and why people is so reluctant to develop a high
> level API.

     I asked the same question (why isn't video implemented on top of 
DataChannels). If I remember correctly, the answer was interoperability. 
Meaning, anyone with a legacy system already parse SDP (different from 
ours, but still). If we placed audio/video on top of DataChannels, 
they'd have to implement the DataChannel API as well.

     My own opinion is that gateways solve all of this. We should be 
building the best API possible, and delegate to gateways to convert from 
one communication format to another. I understand that gateways have a 
bad reputation, but I believe it's mostly due to the fact that they were 
used for video transcoding in the past (which limited scalability). 
Protocol-adapters are cheap. They can come in the form of a gateway or a 
small library you integrate with. Just publish a public-domain protocol 
adapter as a library, and let people integrate with it. That seems a lot 
less expensive than mutilating the API.

Received on Friday, 5 July 2013 21:51:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:49 UTC