Subject: Re: [AVT] Action item: CN payload format

From: Stephen Casner <[email-masked]>
Date: Tue, 18 Sep 2001 12:39:10 -0700 (PDT)

I want to close off this action item that I brought up on the list a
few weeks ago.  I believe that fairly wide support would be required
before making a change to the RTP spec and profile to remove the fixed
binding between the RTP clock rate and the payload type.  I did not
see such support, therefore I request that the authors of
draft-ietf-avt-rtp-cn-03.txt produce a -04 revision which restores the
fixed rate of 8000 Hz as it was in the -01 revision:

   A static payload type of 13 is assigned for a sampling rate of
   8,000 Hz; if other sampling rates are needed, they MUST be defined
   through dynamic payload types.

As I explained in my response to Simao, this is really specifying the
RTP timestamp clock rate rather than the sampling rate, although the
sampling rate would normally be the same as the RTP timestamp clock
rate for CN.  As I also suggested, it would be reasonable to add a
comment to the CN draft that the decoder MAY use a sampling rate
different than the RTP timestamp clock rate if desired.  So, this text
could be changed to something like this (incorporating a few other
"improvements" as well):

   A static payload type of 13 is assigned by the RTP A/V profile [12]
   for the CN payload format with an RTP timestamp clock rate of 8,000
   Hz for use with the many codecs such as G.711 having the same rate.
   To use the CN payload format with a different RTP timestamp clock
   rate, for example to match the 16,000 Hz rate of the G.722.1 [11]
   codec, a dynamic payload type MUST be defined to specify the rate.

   For most audio codecs, the sampling rate is the same as the RTP
   timestamp clock rate, therefore comfort noise would typically be
   generated using a sampling rate that is the same as the RTP
   timestamp clock rate (and the codec sampling rate).  However,
   because of the flexibility of comfort noise generation, a decoder
   MAY use a sampling rate different than the RTP timestamp clock rate
   if desired.  This may only be needed when using CN with the G722
   payload format (G.722 codec, not G.722.1) which for historical
   reasons specifies an RTP timestamp clock rate of 8000 whereas the
   sampling rate is really 16000.

And make the following change + addition to the references (the
numbers might change):

   2  H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A
      Transport Protocol for Real-Time Applications", RFC 1889,
      January 1996, updated by draft-ietf-avt-rtp-new (Work in
      Progress).

   12 H. Schulzrinne, S. Casner, "RTP profile for audio and video
      conferences with minimal control", RFC 1890, January 1996, updated
      by draft-ietf-avt-profile-new (Work in Progress).

In addition, the section on MIME registration needs a few changes: the
title should be "IANA Considerations" to follow current conventions;
registering the static payload type; the "rate" parameter is required,
not optional, since CN can be used with any rate (as is the case for
L16, for example); and change references to the document itself to be
RFC XXXX so that the MIME registration can be extracted and stand by
itself.  A revised initial portion of that section follows.

							-- Steve

7. IANA Considerations

   This section defines a new RTP payload name CN and associated MIME
   subtype, CN (audio/CN).  This document also is the reference
   payload format specification for static payload type 13 assigned by
   the RTP A/V profile [12].

7.1 Registration of MIME media type audio/CN

   MIME media type name: audio

   MIME subtype name: CN

   Required parameters: rate
	The RTP timestamp clock rate, which SHOULD be the same as that
	of the audio codec used in conjunction with CN.  This rate is
	usually equal to the sampling rate.  The typical rate is 8000.

   Optional parameters: None

   Encoding considerations:
        This type is only defined for transfer via RTP [RFC YYYY,
        draft-ietf-avt-rtp-new].

   Security considerations:
        See Section 8 "Security Considerations" in RFC XXXX.

   Interoperability considerations: None

   Published specification:
        RFC XXXX and Appendix II of ITU-T Recommendation G.711

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