On Fri, Jul 5, 2013 at 3:36 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:
>
> 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.
>
The message I was responding to said "Would it be easier and simpler to
implement the
audio & video support directly over the DataChannels, maybe requiring them
to be not reliable?"
Data channels do not send data over a protocol which is wire compatible
with RTP,
therefore you would either need to either:
(a) Redefine data channels so they were wire compatible with RTP.
(b) Gateway all the media from data channels (SCTP) to RTP.
-Ekr