Re: [rtcweb] There are no legacy WebRTC devices (Was: Comment on Straw Poll replies)

On Jan 13, 2014 11:51 PM, "Christer Holmberg" <
christer.holmberg@ericsson.com> wrote:
>
> Hi,
>
> >It doesn't matter that your legacy device can play YouTube (i.e. decode
> >H.264 in a web browser). My point is that unless a legacy device can do
everything I mentioned in the top bullet points then it's not relevant to
the MTI discussion.
>
> I don't agree.
>
> >> Regarding the third bullet, it is true that gateway functionality will
often be needed to handle WebRTC specific features (continous consent etc).
But, such gateway wouldn't have to do video transcoding.
> >
> > I don't understand. I don't think that VP8 (or any other codec) as MTI
implies that you would have to transcode in the gateway.
> >
> > If we're going to talk about gateways, it's important for you to
explain what kind of devices are on either end. Please clarify.
>
> I think Keith gave IMS based networks/devices as an example, so I'll echo
him.
>
> But, of course the networks/devices on the other side could also be
non-IMS SIP networks.
>
> Regards,
>
> Christer
>
>

You gave IMS as an example, but afaik IMS video calling is not widely
deployed. Afaik, it is not deployed at scale in production at all.

In fact, there may be a case that WebRTC voice and video is more widely
deployed than any pure IMS 3gpp deployment.

I lately noticed that Facebook now has voice and video calls without a
plugin (i think..)

So perhaps IMS video is not a good example of an install base since it does
not exist.

CB
>
>
> > ________________________________________
> > From: rtcweb [rtcweb-bounces@ietf.org] on behalf of cowwoc
> > [cowwoc@bbs.darktech.org]
> > Sent: Monday, 13 January 2014 7:48 PM
> > To: DRAGE, Keith (Keith); rtcweb@ietf.org
> > Subject: [rtcweb] There are no legacy WebRTC devices (Was: Comment on
> > Straw Poll replies)
> >
> > Keith,
> >
> > Even if we mandate H.264 and SDP as MTI, how in the world do you expect
RTCWEB to be interoperable with existing video equipment? I just don't get
this argument.
> >
> > As far as I can tell, the market share of devices that:
> >
> >    *   Encode/decode H.264 in hardware *and* expose public APIs for
doing so,
> >    *   Understand SDP,
> >    *   Are WebRTC compliant
> >
> > is exactly zero. There is no way that legacy devices will magically
begin supporting WebRTC. This will require *new* products to get released.
> >
> > Gili
> >
> > On 13/01/2014 9:47 AM, DRAGE, Keith (Keith) wrote:
> > Legacy interoperability is important to some of us.
> >
> > It is not about preserving our existing equipment.
> >
> > It is about the fact the communication involves two or more parties,
and we want to enable video communication between RTCWEB user and the rest
of the entities in the world that are capable of video, without having to
resort to transcoding video on all calls. Yes transcoding is possible, but
it has a cost that someone will have to pay for, and it introduces delay,
which can be catered for, but removes the possibility of someone else in
the call path using that delay portion.
> >
> > Currently there are a considerable number more of those users using
legacy systems than there are using RTCWEB.
> >
> > Keith
> >
> > ________________________________
> > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc
> > Sent: 10 January 2014 16:39
> > To: rtcweb@ietf.org<mailto:rtcweb@ietf.org>
> > Subject: Re: [rtcweb] Comment on Straw Poll replies
> >
> > On 10/01/2014 9:54 AM, stephane.proust@orange.com<mailto:
stephane.proust@orange.com> wrote:
> >
> >
> > Can I ask why you even bother with WebRTC, if you want to restrict
WebRTC to interoperability with old systems only and therefore to old
features only?
> > I'd like to suggest that such replies should be disregarded because
they look backwards and not forwards.
> >
> >
> > I don't think that disregarding replies is a constructive way forward.
> >
> > However if you want to go that way, and if you want to get rid of old
technologies, let's start by disregarding replies from those who could live
with a WebRTC technology that would specify H.261 as only  MTI codec.
> > Given your concerns about "old" systems and "od" features, I'm a little
bit surprised that your are part of them.
> > http://www.ietf.org/mail-archive/web/rtcweb/current/msg10798.html
> > (note that there is G.711 for audio but NOT as ONLY MTI codec)
> >
> >
> > This is a fallacy. No one is arguing that you should be stuck with
using *just* H.261. What we are saying is that: if H.264 or VP8 are
available on both end-points, great. If not, you can either:
> >
> >    *   Use H.261, or
> >    *   Transcode, or
> >    *   Drop Video
> >
> > By eliminating H.261 as MTI, you lose the first option and are forced
to either transcode or drop video. The cost to supporting H.261 is as
simple as compiling https://github.com/Vproject/p64 and popping it on your
device. You don't need hardware support because it's so computationally
cheap.
> >
> > And finally, we're not objecting to the use of H.264, per se, but
rather to the fact that the majority of people who vote for it and against
everything else use "legacy interoperability" as argument.
> >
> > WebRTC is a *new* technology. If all we wanted to do was to support
*existing* devices then we would use *existing* technologies. For that
reason, I don't think maintaining backwards compatibility is important when
breaking it has a noticeable benefit (and in this case, I believe it does).
> >
> > Alternatively, please convince MPEG-LA to make H.264 available
royalty-free.
> >
> > Gili
> >
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb