Re: [rtcweb] (resend) RE: Draft agenda for RTCWeb session 2 at IETF85

[Ron <[e-mail]>]

Hi Bernard,

On Mon, Oct 22, 2012 at 07:33:29PM -0700, Bernard Aboba wrote:
> Ron said: 
> > If the cost of simply tracking all those users didn't bankrupt me all
> > by itself, then the licence fees certainly would try to finish the job.
> 
> [BA]  Pardon me if I'm obtuse, but I'd like to better understand the
> situation that is resulting in your being concerned about having to pay
> license fees and track users. 
> 
> Are you developing HTML5 applications?  f so, are you envisaging that as an
> HTML5 developer writing a WebRTC application for a browser that supports
> H.264 you would need to pay licensing fees? 
> 
> Are you working for a browser vendor?  If so, are you envisaging that you
> would need to pay licensing fees based on the number of users of your
> browser? 
> 
> Are you a developer of applications looking to interoperate with WebRTC?  If
> so, are you calling APIs that enable you to use the H.264 implementation in
> the OS platform, or accessing the hardware encode/decode functionality
> (available on most SoC platforms)?  If so, do you believe that you need to
> pay license fees? 
> 
> Or do you primarily develop on platforms without H.264 support in the OS, and
> on hardware with no H.264 encode/decode support?  

Yes, I see the distinction that you're aiming to point out there,
but I hadn't got the impression that anybody here actually was
confused by the difference between:

 "If a licenced implementation of H.264 is available, you can use it."

and 

 "RTCWeb can only be used on platforms with a licenced H.264 codec."


The former does not require H.264 to be MTI.  Like any other codec
it can always be negotiated when support for it exists at both ends.

The latter is a consequence of making H.264 MTI and would make this
standard useless to anyone who did not buy a licence to it themselves
or were not happy to restrict their userbase to platforms that had
purchased one for them in advance, whether they wanted it or not.

That doesn't seem like a good starting point for a standard that
likes to describe SIP as "legacy technology", and aims to become a
(if not The) ubiquitous communication technology for the future.


I don't see what is confusing about the idea that the baseline spec
should be RF, and open to as wide a field of users and developers
as possible -- with the ability to negotiate the optional use of
other (possibly royalty encumbered) technologies where some more
constrained demand or deployment or rationale for those also exists.

This would be consistent with the criteria applied for selection
of the MTI audio codec.



To return just briefly to the question of "risk" that was raised,
one other advantage to making VP8 the choice of MTI codec which
occurs to me is that since the known VP8 IPR comes with protective
conditions for its users in the form of the "poison pill" clauses
of its RF licence - then by making it MTI here, we'd also confer
that protection more broadly to RTCWeb users, since anyone suing
them for using VP8 would then also lose their own "licence" to
implement the RTCWeb standard too.

If RTCWeb is as successful at unifying communications as we all
hope it will be, that would certainly be a strong disincentive
to hostile action for anyone likely to actually hold patents on
any relevant communication technology.  That sounds like a much
stronger form of protection to me than "MPEG-LA can licence you
lots of, but not all of, the patents for H.264".  Doesn't it?


 Acutely,
 Ron