On 6 Jul 2013 08:07, "Eric Rescorla" <ekr@rtfm.com> wrote:
>
> On Fri, Jul 5, 2013 at 2:59 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>>
>> On 05/07/2013 5:55 PM, Eric Rescorla wrote:
>>>
>>>
>>> On Fri, Jul 5, 2013 at 2:16 PM, piranna@gmail.com <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?
>>>
>>>
>>> No, it would not be easier. More importantly, it wouldn't be compatible
>>> with existing devices, wihich is an important requirement.
>>
>>
>> Let be honest. There are no existing devices that are compatible
with WebRTC, with or without SDP.
>
>
> On what basis do you say that? What feature do you believe is not
compatible with
> any existing devices?
>
>> At the very least, all these products needs to be modified to understand
WebRTC-specific key/value pairs.
>
>
> Even if this were true, there is a huge difference between requiring
modest SDP translation
> and requiring gatewaying of every packet.
We're only talking about gatewaying SDP and not the media transport itself.
We effectively have two signaling needs in WebRTC: signaling to get through
to the partner we are talking to, and signaling to determine what media
will be sent over srtp. We decided not to prescribe the first but we're
prescribing the second. But because existing SDP is so limited, we are
extending it and thus breaking compatibility with existing devices, which
was why we chose to prescribe it in the first place.
Should the SDP on the wire be limited to support what legacy devices
support?
Then we could add an independent API to tell the browser what data to put
into the srtp stream when it's talking to non-legacy devices. This would be
just an API that is used between the JS dev and the browser to determine
the capabilities of the device and manipulate what goes into the srtp
stream.
Just a thought...
Silvia.