Subject: RE: [AVT] Retransmission draft

From: José Rey <[email-masked]>
Date: Thu, 4 Dec 2003 14:34:56 +0100

Hi Colin, all,

in the past weeks I had some intensive internal discussions on the matter of
the potential IPRs on the RTP retransmission draft. As a WG participant I
perfectly understand and respect the comments and interests expressed by you
and others of the AVT group. In order to keep the good working spirit in AVT
it is my strong intention to adress these comments in the best possible way
by taking the interests of all parties involved in this work into account.

Matsushita has published an IPR statement that it is prepared to grant a
license on reasonable, nondiscriminatory terms and conditions (in accordance
with paragraph 10.3.3 of the RFC 2026) on any part that is included into
the RTP retransmission standard and that Matsushita possibly holds IPRs on.
Providing a royality-free license to open-source developers will
unfortunately lead to a situation where Matsushita will lose any rights on
their IPRs in most cases. Taking into account the work and effort (we
started with the retransmission draft in AVT more than 2.5 years ago) we
spent into this draft, this is not acceptable for Matsushita.

On the other hand, we believe that the situation for open-source developers
is quite easy to solve by other means. First of all they are not in any way
'forced' to implement RTP retransmission. It is just an optional repair
mechanism for the RTP protocol, as described in RFC2354. In order to solve
the problems that RTP retransmission tries to solve, there are other
solutions available from the AVT group which are not encumbered by IPRs,
e.g. RFC2733 and draft-ietf-avt-ulp-08.txt. This makes the implementation
of the RTP retransmission solution purely optional and easily avoidable to
everyone.

In order to make this situation clear to anybody who reads the RTP
retransmission draft, we suggest to add a paragraph at the very beginning of
the draft. This paragraph will make implementors aware of the situation that
the solution described in this draft is possibly encumbered by IPRs.
Furthermore it will point implementors to non-IPR-encumbered solutions as
above, which may perfectly be used instead of RTP retransmission.

Finally and FYI: 3GPP is aware of the IPR situation of the RTP
retransmission draft and has accepted the solution provided in
draft-ietf-avt-rtp-retransmission-09.txt as working assumption in their
packet based streaming service (PSS). The acceptance is conditional on the
fact that the draft will proceed on standards track and an RFC is available
before the release of the PSS specifications, (expected for March 2004).

Looking forward to your comments,

Jose

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Colin
> Perkins
> Sent: Tuesday, October 21, 2003 6:58 PM
> To: [email-masked]
> Cc: [email-masked]; 'Magnus Westerlund'
> Subject: Re: [AVT] Retransmission draft
>
>
> On Tuesday, Oct 21, 2003, at 12:54 Europe/London, Jose Rey wrote:
> ...
> > In previous emails we have been asked to explain our patent
> > application and
> > we
> > informed AVT that the patent application itself specifies a
transport
> > method
> > using the RTP protocol where two sequence numbers are used: one to
> > specifiy
> > the transmission order (=RTP SN) and the other one defining the
> > reprodution
> > order, which in the draft corresponds with the OSN (original
sequence
> > number). We also stated that it is not possible to implement the
> > protocol
> > without infringing on the patent.
> > So far we have not received any more questions on the patent, but
are
> > happy
> > to provide them in case needed.
> >
> > On the issue of how to proceed with this RTP retransmission draft
some
> > opinions have been provided by Magnus Westerlund, Lars-Erik Jonsson
and
> > John Lazzaro. John Lazzaro (08.09.03) has suggested to publish it as
> > Informational if the patent rights are held while Magnus and
> > Lars-Erik have suggested to proceed with the document as a Proposed
> > Standard (as we understand from the emails on from 22.09.03 and
> > 09.09.03).
> >
> > Taking all the above into account and considering that
> > independent of the patent situation this work is intended to be
> > included in
> > the next release of 3GPP, we would like to ask the group to proceed
> > with the
> > draft on standards track.
> >
> > cheers,
> > Jose
>
> [takes working group chair hat off]
>
> 3GPP is only one forum which uses IETF standards, and one where
dealing
> with IPR issues is commonplace. Having patented standards is more of
an
> issue for open source developers, who are often excluded by the
> licensing terms. Would Matsushita be willing to clarify if the
> "reasonable, nondiscriminatory" terms allow open source
implementations
> to use the retransmission format (this will probably require a
> Royalty-Free license)?
>
> [puts working group chair hat on again]
>
> --
> Colin Perkins
> http://csperkins.org/
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Thu, 4 Dec 2003 14:59:24 +0000

José,

[cc list trimmed]

--> José Rey <[email-masked]> writes:
> in the past weeks I had some intensive internal discussions on the matter
> of the potential IPRs on the RTP retransmission draft. As a WG
> participant I perfectly understand and respect the comments and interests
> expressed by you and others of the AVT group. In order to keep the good
> working spirit in AVT it is my strong intention to adress these comments
> in the best possible way by taking the interests of all parties involved
> in this work into account.
> 
> license on reasonable, nondiscriminatory terms and conditions (in
> accordance with paragraph 10.3.3 of the RFC 2026) on any part that is
> included into the RTP retransmission standard and that Matsushita
> possibly holds IPRs on. Providing a royality-free license to open-source
> developers will unfortunately lead to a situation where Matsushita will
> lose any rights on their IPRs in most cases. Taking into account the work
> and effort (we started with the retransmission draft in AVT more than 2.5
> years ago) we spent into this draft, this is not acceptable for
> Matsushita.
> 
> On the other hand, we believe that the situation for open-source
> developers is quite easy to solve by other means. First of all they are
> not in any way'forced' to implement RTP retransmission. It is just an
> optional repair mechanism for the RTP protocol, as described in RFC2354.
> In order to solve the problems that RTP retransmission tries to solve,
> there are other solutions available from the AVT group which are not
> encumbered by IPRs, e.g. RFC2733 and draft-ietf-avt-ulp-08.txt. This
> makes the implementation of the RTP retransmission solution purely
> optional and easily avoidable to everyone.

Provided it is clear that the mechanism is encumbered, yes.

> retransmission draft, we suggest to add a paragraph at the very beginning
> of the draft. This paragraph will make implementors aware of the
> situation that the solution described in this draft is possibly
> encumbered by IPRs. Furthermore it will point implementors to
> non-IPR-encumbered solutions as above, which may perfectly be used
> instead of RTP retransmission.

Without seeing the wording of this paragraph, I can't give a definitive
answer, but that would largely address my concerns.

-- 
Colin Perkins
http://csperkins.org/

---

From: José Rey <[email-masked]>
Date: Thu, 4 Dec 2003 17:52:25 +0100

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Thursday, December 04, 2003 3:59 PM
> To: [email-masked]
> Cc: [email-masked]

right, how about this:

"This document provides an RTP packet retransmission mechanism for repair of
streaming media.  The purpose of this paragraph is to make the reader aware
that the retransmission mechanism described in this document may be
encumbered by patent applications filed from Matsushita.  For details on the
IPR statement, please visit the IETF IPR web page
http://www.ietf.org/ietf/IPR.

However, packet retransmission is not the only means for streaming clients
and servers to cope with packet losses.  A detailed description of options
for repair of streaming media is given in RFC2354.  Therefore, implementers
of this protocol shall take into account that there are in fact other
mechanisms, such as forward error correction (FEC) or packet interleaving
that represent an alternative to solve the problems packet retransmission
tries to solve.    In particular RFC2733 and RFC2198 present FEC and
redundant packet transmission schemes that might well fit to the needs of
the implementer. "

José

---

From: Colin Perkins <[email-masked]>
Date: Sun, 7 Dec 2003 19:23:06 +0000

> > > retransmission draft, we suggest to add a paragraph at the very
> > > beginning of the draft. This paragraph will make implementors aware
> > > of the situation that the solution described in this draft is
> > > possibly encumbered by IPRs. Furthermore it will point implementors
> > > to non-IPR-encumbered solutions as above, which may perfectly be used
> > Without seeing the wording of this paragraph, I can't give a
> > definitive answer, but that would largely address my concerns.
> 
> right, how about this:
> 
> "This document provides an RTP packet retransmission mechanism for repair
> of streaming media.  The purpose of this paragraph is to make the reader
> aware that the retransmission mechanism described in this document may be
> encumbered by patent applications filed from Matsushita.  For details on
> the IPR statement, please visit the IETF IPR web page
> However, packet retransmission is not the only means for streaming
> clients and servers to cope with packet losses.  A detailed description
> of options for repair of streaming media is given in RFC2354.  Therefore,
> implementers of this protocol shall take into account that there are in
> fact other mechanisms, such as forward error correction (FEC) or packet
> interleaving that represent an alternative to solve the problems packet
> retransmission tries to solve.    In particular RFC2733 and RFC2198
> present FEC and redundant packet transmission schemes that might well fit
> to the needs of the implementer. "

This, at least, would stop accidental infringement which is one of my main
concerns. I would still strongly prefer a royalty-free license, however.

Colin