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

[Christer Holmberg <[e-mail]>]

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




> ________________________________________
> From: rtcweb [[e-mail]] on behalf of cowwoc 
> [[e-mail]]
> Sent: Monday, 13 January 2014 7:48 PM
> To: DRAGE, Keith (Keith); [e-mail]
> 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:[e-mail]] On Behalf Of cowwoc
> Sent: 10 January 2014 16:39
> To: [e-mail]<mailto:[e-mail]>
> Subject: Re: [rtcweb] Comment on Straw Poll replies
>
> On 10/01/2014 9:54 AM, [e-mail]<mailto:[e-mail]> 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
>