- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Fri, 05 Jul 2013 17:50:14 -0400
- 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.
Gili
Received on Friday, 5 July 2013 21:51:32 UTC