Subject: [AVT] Action item: CN payload format

From: Stephen Casner <[email-masked]>
Date: Tue, 21 Aug 2001 13:47:08 -0700 (PDT)

In the discussion of document status at the start of the AVT meeting,
I reported on a new revision of draft-ietf-avt-rtp-cn-03.txt.  There
was one small but significant change from the -01 revision that we
discussed previously.  The -01 revision said:

   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.

The -03 revision says:

   A static payload type of 13 is assigned for the comfort noise
   packet.  The sampling rate MUST be the same sampling rate used for
   the audio codec RTP packet that most recently preceded the comfort
   noise RTP packet on the same port.  For example, if the G.711 codec
   is in use, the sampling rate for the CN packet is 8,000 Hz.  If the
   G.722.1[11] codec is in use, the sampling rate for the CN packet is
   16,000 Hz.

The motivation for the change was to be able to use CN for codecs like
G.722.1 without having to define a dynamic payload type.  The
rationale was that CN would not be used by itself, there would always
be another codec from which the RTP clock rate (sampling rate) could
be determined.

However, this change conflicts with the RTP spec and A/V profile which
say that the RTP timestamp clock rate is fixed for a particular
payload type, either through the definition of a static payload type
number or as a parameter in the mapping of a dynamic payload type
number.  These texts may not be as explicit as they should be on this
exact point, but the RTP spec says, in the definition of the RTP
timestamp:

   The clock frequency is dependent on the format of data carried as
   payload and is specified statically in the profile or payload
   format specification that defines the format, or MAY be specified
   dynamically for payload formats defined through non-RTP means.
   [SDP is an example of "non-RTP means".]

The RTP A/V profile specifies for audio encodings:

   When used with a sampling rate other than that for which a static
   payload type is defined, non-RTP means beyond the scope of this memo
   MUST be used to define a dynamic payload type and MUST indicate the
   selected RTP timestamp clock rate, which is usually the same as the
   sampling rate for audio.

So, the question before the group is whether the RTP specification
should be changed to allow the RTP timestamp clock rate associated
with a payload type to vary.  Your feedback is solicited.

   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taking off my chairman's hat, my opinion is that this change should
not be allowed and that the CN draft text should be changed back to
the way it was in the -01 revision, for a couple of reasons:

  - The fixed binding of the RTP timestamp clock rate to the payload
    type is a fairly fundamental notion.  Making a change such as this
    should not be done without a strong motivation.  Here it is just a
    convenience to avoid defining a dynamic payload type.  Since the
    G7221 payload format requires a dynamic payload type anyway,
    this convenience seems minimal.

  - There may be a problem with method proposed in -03:  many audio
    sessions are likely to be silent when they first start (e.g.,
    before the callee says "Hello" on a telephone session).
    Therefore, the first packet might be a CN packet, with no other
    codec packet to precede it and establish the RTP timestamp clock
    rate.

It should be noted that the frequency we are talking about is properly
the RTP timestamp clock rate, not the sampling rate.  The two are
usually equal but not always, e.g., G722 (vs. G7221) and MPA.  The CN
implementation could actually produce its noise output using a
sampling rate different than the RTP timestamp clock rate if desired.
The main requirement for the RTP timestamp clock rate binding is that
the receiver needs to know how to interpret the RTP timestamp.

Comments?
							-- Steve

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

---

From: Simao Campos-Neto <[email-masked]>
Date: Tue, 21 Aug 2001 17:22:58 -0400

Steve,

this issue still confuses me: what is the difference between "sampling
rate" as used in RTP and as understood by the codec? The impression I have
is that the timestamp rate is not important to the speech decoder itself,
which sits above the RTP layer. And the codec should know what is the
sampling rate it should be operating at (even for a system where bandwidth
can change from time to time) either by examination of the packet contents
or some other heuristical property. 

If sampling rate for the RTP layer and sampling rate for the encoder/
decoder can be dissociated, the language in the -01 revision seems good
enough, and would not warrant a change to the RTP spec. Maybe what is
necessary is a clarification on the meaning of sampling rate (or use a
distinct of "sampling rate" and "RTP timestamp clock rate"), if this is the
case, and a note indicating that the silence removal / comfort noise
generation block has to work closely with the speech codec to know which
"speech" sampling rate should be used. 

I would appreciate to be corrected, should I have misundestood the issue.

BR,
Simão.
--
Stephen Casner wrote:
> 
> ... The -01 revision said:
> 
> ...
> with a payload type to vary. ...
> ...

-- 
===========================================================================
Simão Ferraz de Campos Neto, Scientist *All comments are strictly my own*
LMGT/COMSAT                            Tel:    +1-301-428-4516
22300 Comsat Drive                     Fax:    +1-301-428-9287
Clarksburg MD 20871 - USA              E-mail: [email-masked]
===========================================================================
  ******** Practice random kindness and senseless acts of beauty ********
===========================================================================

---

From: Stephen Casner <[email-masked]>
Date: Wed, 22 Aug 2001 00:05:30 -0700 (PDT)

Simao,

> rate" as used in RTP and as understood by the codec?

The answer depends upon which particular encoding is in use.  Strictly
speaking, RTP uses the RTP timestamp clock rate and does not use the
"sampling rate".  I just reviewed the use of the term "sampling rate"
in the A/V profile and most instances appear to be valid, but I see
that the first instance in Section 4.1 says the timestamp clock rate
equals the sampling rate.  That is wrong because they are not always
equal, just usually.  So, I need to fix that text.

> The impression I have

That is true for some codecs, especially frame-based codecs, but not
all codecs.  For example, the L16 encoding can be used with any
sampling rate.  For L16, the RTP timestamp clock rate _is_ equal to
the sampling rate, and the codec needs to know the RTP timestamp clock
rate in order to function.

> enough, and would not warrant a change to the RTP spec.

No, they can't (always) be dissociated, as I just explained.  I
believe the language in the -01 revision is the correct language, but
I'm not sure what you mean by "good enough".  The not-always-equal
association between the timestamp clock rate and the sampling rate
does not mean that static payload type 13 it suitable for use of CN
with any codec.  When using G7221, the samling rate is 16kHz and the
RTP timestamp clock rate is equal to the sampling rate.  The RTP
timestamp clock rate needs to be the same during sound and silence to
keep playout buffer management sane, so a dynamic payload type is
needed to specify CN with a timestamp clock rate of 16kHz.  The codec
could use a different sampling rate when actually reproducing the
noise, but it probably does not want the sampling rate to change
between sound and silence, either.

> Maybe what is

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.  However, I think there are only two instances where
this makes sense: first, with G722 (not G7221), where for historical
reasons the RTP timestamp clock rate is 8000 whereas the sampling rate
is really 16000 (as we resolved after lengthy discussion a year or two
ago); and second, for MPA, where the RTP timestamp clock rate is
always 90000 independent of the sampling rate (but I don't think CN
would be used with MPA).
							-- Steve