Subject: [AVT] AVT Charter update

From: Magnus Westerlund <[email-masked]>
Date: Tue, 02 Sep 2003 14:33:09 +0200

Hi,

In Vienna we chairs presented a proposal for a new charter for the WG. 
We have now made some smaller updates:
- One editorial change removing the word RFC from the bullet regarding 
RTP payload format being advanced to draft standard.
- Added milestones for iLBC and RTP framing over TCP and TLS.

The WG is given one more week (until the 9th of September) for review, 
we will then submit it for approval by the Area Director. Please send 
any comments to the list or the chairs.

Best Regards

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

The Audio/Video Transport Working Group was formed to specify a
protocol for real-time transmission of audio and video over unicast
and multicast UDP/IP. This is the Real-time Transport Protocol, RTP,
together with its associated profiles and payload formats. The 
current aims of the working group are:     
                                          
 - to advance the main RTP specification and RTP Profile 
   for Audio and Video Conferences with Minimal Control 
   for publication as full Internet Standards

 - to review and revise existing payload formats to advance those
   which are useful to Draft Standard, and to declare others
   as Historic. Milestones will be established as a champion for 
   each payload format is identified.
 
 - to develop payload formats for new media codecs, and to
   document best-current practices in payload format design. 
   The group continues to be precluded from work on codecs 
   themselves because of overlap with the other standards 
   bodies, and because the IETF does not have the ability 
   to effectively review new codecs. An exception was made 
   for the freeware iLBC codec on a highly experimental basis, 
   but acceptance of new codec work is unexpected and subject 
   to rechartering.

 - to complete the forward error correction work in the ULP and
   UXP payload formats

 - to extend RTP to work with Source-Specific Multicast sessions
   with unicast feedback

 - to provide a framing mechanism for RTP over TCP and TLS

 - to review the applicability of Compressed RTP operation on
   MPLS networks, developing extensions as necessary

 - to develop a new RTP profile as the combination of the SRTP
   profile and the Extended RTP Profile for RTCP-based Feedback
   (RTP/SAVPF)

The group will also coordinate with the DCCP working group to
ensure that RTP can be efficiently transported over DCCP.

The longer term goals of the working group are to advance the 
SRTP Profile, the Extended RTP Profile for RTCP-based Feedback,
the Compressed RTP framework, and the RTP MIB to Draft Standard. 

The group has no plans to develop new RTP profiles beyond those
listed above, but will consider rechartering to produce profile
level extensions if appropriate.            
       
Milestones:

Oct 2003  Review DCCP including prototypes and API; feedback to DCCP WG
Nov 2003  Initial draft requirements for ECRTP over MPLS; discuss with MPLS WG
Dec 2003  Submit UXP Payload Format for Proposed Standard              
Dec 2003  Submit ULP Payload Format for Proposed Standard 
Dec 2003  Submit RTCP/SSM draft for Proposed Standard
Dec 2003  Submit iLBC codec specification for Experimental
Dec 2003  Submit iLBC payload format for Proposed Standard
Jan 2004  Advance RTP specification and A/V profile to Full Standard
Mar 2004  Submit Framing of RTP for TCP and TLS for Proposed Standard
Mar 2004  Identify payload formats to classify as Historic
Mar 2004  Finish requirements for ECRTP over MPLS; recharter for subsequent work
Jul 2004  Submit RTP/SAVPF profile for Proposed Standard
Jul 2004  Begin update of SRTP profile for Draft Standard RFC
Jul 2004  Begin update of RTP/AVPF profile for Draft Standard RFC
Aug 2004  Consider update of RTP MIB
Nov 2004  Collect SRTP implementation reports
Nov 2004  Collect RTP/AVPF implementation reports
Mar 2005  Submit SRTP for Draft Standard
Mar 2005  Submit RTP/AVPF for Draft Standard

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Tue, 02 Sep 2003 10:17:10 -0400

At 02:33 PM 9/2/2003 +0200, Magnus Westerlund wrote:
>Hi,
>
>In Vienna we chairs presented a proposal for a new charter for the WG. We 
>have now made some smaller updates:
>- One editorial change removing the word RFC from the bullet regarding RTP 
>payload format being advanced to draft standard.
>The WG is given one more week (until the 9th of September) for review, we 
>will then submit it for approval by the Area Director. Please send any 
>comments to the list or the chairs.

Magnus/Colin,

In regard to new "codecs".

I understand the iLBC exception, as AVT has been working this issue with 
iLBC for quite a while.

My question regards the RGL freeware codec (see www.vovida.org or 
draft-ramalho-rgl-desc-01.txt).

As the AVT chairs know, RGL is really a LOSSLESS COMPRESSION technique (which I
now wished that I named "RGL compression" instead of "RGL codec"). RGL 
performs NO
SIGNAL PROCESSING on the underlying G.711 PCM frame provided as input to it.

Therefore the rationale provided in the proposed AVT Charter for not 
codifying "new codecs"
does not apply:

"The group continues to be precluded from work on codecs themselves because 
of overlap with
the other standards bodies, and because the IETF does not have the ability 
to effectively
review new codecs."

As AVT specifies other compression techniques (e.g., Compressed RTP 
framework), the
necessary expertise to review RGL clearly exists in AVT.

Questions:
Could RGL be explicitly included? Should I re-name RGL to "RGL compression"?
Could the Charter specifically include compression techniques on codec output
frames themselves (as RGL does for G.711)?

[As you know, other lossy codecs will normally attempt to remove payload 
redundancy
and render the resulting lossy codec output relatively random ... so this 
issue is moot
for iLBC, BV8, G.729, etc.]

Lastly, I note that it is a reasonable expectation that other "lossless 
payload compression"
techniques may use similar techniques. For example:

1 - streaming of real-time MRI images - where the medical professionals 
want "lossless"
frames or "no" image frames (you don't want to diagnose off of a lossy 
compression
created artifact), or

2 - satellite imaging from outer space probes where you desire lossless 
compression
(one of Professor Rice's - of Rice coding fame - initial applications).

[One could argue traditional IETF reliable transports for 1, but not for 2].

We don't need the ITU-T/ETSI/etc. organization's expertise for these 
"lossless payload
compression" applications either.

Best Regards,

Michael Ramalho

>The Audio/Video Transport Working Group was formed to specify a protocol 
>for real-time transmission of audio and video over unicast and multicast 
>UDP/IP. This is the Real-time Transport Protocol, RTP, together with its 
>associated profiles and payload formats. The current aims of the working 
>group are:                                               - to advance the 
>main RTP specification and RTP Profile    for Audio and Video Conferences 
>with Minimal Control    for publication as full Internet Standards - to 
>review and revise existing payload formats to advance those    which are 
>useful to Draft Standard, and to declare others    as Historic. Milestones 
>will be established as a champion for    each payload format is 
>identified. - to develop payload formats for new media codecs, and 
>to    document best-current practices in payload format design.    The 
>group continues to be precluded from work on codecs    themselves because 
>of overlap with the other standards    bodies, and because the IETF does 
>not have the ability    to effectively review new codecs. An exception was 
>made    for the freeware iLBC codec on a highly experimental basis,    but 
>acceptance of new codec work is unexpected and subject    to rechartering. 
>- to complete the forward error correction work in the ULP and    UXP 
>payload formats - to extend RTP to work with Source-Specific Multicast 
>sessions    with unicast feedback - to provide a framing mechanism for RTP 
>over TCP and TLS - to review the applicability of Compressed RTP operation 
>on    MPLS networks, developing extensions as necessary - to develop a new 
>RTP profile as the combination of the SRTP    profile and the Extended RTP 
>Profile for RTCP-based Feedback    (RTP/SAVPF) The group will also 
>coordinate with the DCCP working group to ensure that RTP can be 
>efficiently transported over DCCP. The longer term goals of the working 
>group are to advance the SRTP Profile, the Extended RTP Profile for 
>RTCP-based Feedback, the Compressed RTP framework, and the RTP MIB to 
>Draft Standard. The group has no plans to develop new RTP profiles beyond 
>those listed above, but will consider rechartering to produce profile 
>level extensions if appropriate.                   Milestones: Oct 
>2003  Review DCCP including prototypes and API; feedback to DCCP WG Nov 
>2003  Initial draft requirements for ECRTP over MPLS; discuss with MPLS WG 
>Dec 2003  Submit UXP Payload Format for Proposed Standard              Dec 
>2003  Submit ULP Payload Format for Proposed Standard Dec 2003  Submit 
>RTCP/SSM draft for Proposed Standard Dec 2003  Submit iLBC codec 
>specification for Experimental Dec 2003  Submit iLBC payload format for 
>Proposed Standard Jan 2004  Advance RTP specification and A/V profile to 
>Full Standard Mar 2004  Submit Framing of RTP for TCP and TLS for Proposed 
>Standard Mar 2004  Identify payload formats to classify as Historic Mar 
>2004  Finish requirements for ECRTP over MPLS; recharter for subsequent 
>work Jul 2004  Submit RTP/SAVPF profile for Proposed Standard Jul 
>2004  Begin update of SRTP profile for Draft Standard RFC Jul 2004  Begin 
>update of RTP/AVPF profile for Draft Standard RFC Aug 2004  Consider 
>update of RTP MIB Nov 2004  Collect SRTP implementation reports Nov 
>2004  Collect RTP/AVPF implementation reports Mar 2005  Submit SRTP for 
>Draft Standard Mar 2005  Submit RTP/AVPF for Draft Standard

Michael A. Ramalho, Ph.D.
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.941.708.4650
Cell: +1.941.544.2844

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 2 Sep 2003 17:29:55 +0100

Michael,

On Tuesday, Sep 2, 2003, at 15:17 Europe/London, Michael A. Ramalho 
wrote:
...
> codifying "new codecs" does not apply:
>
> "The group continues to be precluded from work on codecs themselves 
> because of overlap with the other standards bodies, and because the 
> IETF does not have the ability to effectively review new codecs."
>

It is appropriate for AVT to work on the payload format for RGL, and to 
provide advice on aspects of the codec design which might impact 
performance with RTP and UDP/IP. The compression algorithm is outside 
our scope, and we will not accept that work.

Other organisations have experience in audio/visual compression 
algorithms, and we feel it more appropriate that codec work occur 
there. If, however, you consider it important that the IETF has a codec 
design activity, you should consider raising the issue with the 
Applications Area Directors, as a potential new working group.

> [As you know, other lossy codecs will normally attempt to remove 
> payload redundancy
> and render the resulting lossy codec output relatively random ... so 
> this issue is moot for iLBC, BV8, G.729, etc.]
>
> Lastly, I note that it is a reasonable expectation that other 
> "lossless payload compression" techniques may use similar techniques. 
> For example:
>
> 1 - streaming of real-time MRI images - where the medical 
> professionals want "lossless" frames or "no" image frames (you don't 
> want to diagnose off of a lossy compression created artifact), or
>
> 2 - satellite imaging from outer space probes where you desire 
> lossless compression

In both these examples, I would regard the compression as being outside 
the scope of AVT. Again, we would be happy to provide advice on the 
properties of the compression and on appropriate strategies for mapping 
such data onto RTP, but we would leave the definition of the 
compression to the domain experts.

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