Subject: [AVT] Review of CN payload format

From: Stephen Casner <[email-masked]>
Date: Sat, 19 Jan 2002 00:42:55 -0800 (PST)

I have reviewed draft-ietf-avt-rtp-cn-04.txt, "RTP Payload for Comfort
Noise".  Actually, I've reviewed it before and we have discussed it
several times in AVT over an embarrassingly long period of time.  This
draft is nice and simple, and clearly written.  As I've said before,
the main question is whether there will there be any backwards
compatibility problems with early implementations of CN that included
only the amplitude and not spectral information.  However, I think
we've given plenty of opportunity for comment on that, and the IESG
last call will provide a broader opportunity for review on that point.

I have only a WG last call comments I'd like to see before this goes
to IESG last call, some of which are based on changes in procedures
over the time this draft.  I list the changes here, then for the
convenience of the author I attach a diff file with some specific
suggested text changes.

  - First, I take as WG last call comments the messages from Sharma
    Kanchinadham and others on this list asking for some explicit
    mention of the mechanism to negotiate use of CN.  Now, negotiation
    gets too much into the separate domain of SIP or other control
    protocols, but it is common practice to show SDP usage for a
    payload format, and I think that would be helpful here, too.  I
    wrote a section giving static and dynamic payload examples, and
    saying that omission of a payload type for CN on the media
    description line implies that comfort noise will not be used, but
    it does not imply that silence will not be suppressed.  I also
    added some words in the Guidelines for Use section to clarify that
    the payload type is switched between active and inactive voice
    periods.  Check the attachment to see the wording.

  - As I recently learned in handling the "authors' 48 hours" edits
    for RFC 3189 and 3190, the Abstract section is never numbered.
    So, please change Abstract to be unnumbered and renumber the other
    sections.

  - Since this draft is going to go to the IESG and we presume to RFC
    publication thereafter, the "Resolution of Open Issues" paragraph
    should be deleted from the Abstract section.

  - In the description of the RTP timestamp, I think it is better to
    say that the timestamp marks the beginning of the comfort noise
    period, rather than the beginning of the silence period, because
    comfort noise may be repeated.

  - This revision of the draft put back the appropriate specification
    of static payload type 13.  Since that payload type is assigned
    under the RTP A/V profile (RFC 1890 and the draft revision), that
    profile needs to be referenced.  Also, as I clarified in the
    text of the draft profile revision recently, the 8000 Hz is
    properly the RTP timestamp clock rate, not the sampling rate
    (the two are usually but not always equal).

  - The word "minimising" is the only British spelling in an otherwise
    American English document, so it should be consistent.  :)

  - The IESG and RFC Editor like to see an "IANA Considerations"
    section.  For this draft, I suggest just renaming Section 7.  Then
    it would also be good to add some words there about the assignment
    of payload type 13 in IANA's "RTP Parameters" registry.

  - In the MIME registration, the meaning of the optional parameter
    "rate" should be given.  Also, in Encoding Considerations, let's
    just refer to RFC 1889 rather than the draft revision so as not to
    create a publication dependency.

  - The changes suggested above require three additional RFC
    references.
							-- Steve
--- draft-ietf-avt-rtp-cn-04.txt	Sat Dec  8 13:35:50 2001
+++ draft-ietf-avt-rtp-cn-04a.txt	Sat Jan 19 00:15:26 2002
@@ -38,15 +38,6 @@
    itself such as ITU-T Recommendations G.711 [3], G.726 [4], G.727
    [5], G.728 [6], and G.722 [7].
 
-   Resolution of Open Issues
-
-   This revision reverts the definition of the sampling rate back to
-   that in revision -01 of this document.  By making the sampling rate
-   equal to that of the audio codec, it was essentially redefining the
-   meaning of a static payload to say that it could have a variable RTP
-   clock rate.  The sampling rate is now defined to be 8000 Hz, and any
-   other rate requires the use of a dynamic payload type.  See Section
-   5 for details.  No other issues are known or expected.
 
 2. Conventions used in this document
 
@@ -169,9 +160,11 @@
 
    The RTP header for the comfort noise packet SHOULD be constructed as
    if the comfort noise were an independent codec. Thus, the RTP
-   timestamp designates the beginning of the silence period. 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
+   timestamp designates the beginning of the comfort noise period. When this
+   payload format is used under the RTP profile specified in RFC 1890
+   [11], a static payload type of 13 is assigned for RTP timestamp
+   clock rate of 8,000 Hz; if other rates are needed, they MUST be
+   defined through
 
 Zopf                Standards Track - April, 2002                   3
 
@@ -192,11 +185,17 @@
    CNG algorithms.  The job of the VAD is to discriminate between
    active and inactive voice segments in the input signal.  During
    inactive voice segments, the role of the CNG is to sufficiently
-   describe the ambient noise while minimising the transmission rate.
+   describe the ambient noise while minimizing the transmission rate.
    A Silence Insertion Descriptor (SID) frame containing a description
-   of the noise is packed into the CN payload and sent to the receiver.
-   The DTX algorithm determines when a SID frame is transmitted.  The
-   SID frame is sent once at the beginning of a silence period, but the
+   of the noise is packed into the CN payload and sent to the receiver
+   to drive the CNG.
+   The DTX algorithm determines when a SID frame is transmitted.
+   During active voice segments, packets of the voice codec are transmitted
+   and indicated in the RTP header by the static or dynamic payload
+   type for that codec.  At the beginning of an inactive voice segment
+   (silence period), a SID frame packed into a CN packet is
+   transmitted in the same RTP stream and indicated by the CN payload
+   type.  The SID frame 
    update rate is left implementation specific.  For example, the SID
    frame may be sent periodically or only when there is a significant
    change in the background noise characteristics.  The CNG algorithm
@@ -216,10 +215,50 @@
    performance in the design of the VAD/DTX/CNG algorithms are
    described in the Appendix.
 
-7. MIME Media Type Registrations
+6.1 Usage of SDP
+
+   When using the Session Description Protocol (SDP) [12] to specify
+   RTP payload information, the use of comfort noise is indicated by
+   the inclusion of a payload type for CN on the media description
+   line.  When using CN with the RTP/AVP profile [11] and a codec
+   whose RTP timestamp clock rate is 8000 Hz, such as G.711 (PCMU,
+   static payload type 0), the static payload type 13 for CN can be
+   used:
+
+      m=audio 49230 RTP/AVP 0 13
+
+   When using CN with a codec that has a different RTP timestamp clock
+   rate, a dynamic payload type mapping (rtpmap attribute) is
+   required.  This example shows CN used with the G.722.1 codec (see
+   RFC 3047 [13]):
+
+      m=audio 49230 RTP/AVP 101 102
+      a=rtpmap:101 G7221/16000
+      a=fmtp:121 bitrate=24000
+      a=rtpmap:102 CN/16000
+
+   Omission of a payload type for CN on the media description line
+   implies that comfort noise will not be used, but it does not imply
+   that silence will not be suppressed.  Discontinuous transmission
+   (silence suppression) is indicated by an increment in the RTP
+   timestamp without a corresponding increment in the RTP sequence
+   number.
+
+7. IANA Considerations
 
    This section defines a new RTP payload name and associated MIME
-   type, CN (audio/CN).
+   type, CN (audio/CN). The payload format specified in this document
+   is also assigned payload type 13 in the RTP Payload Types table of
+   the RTP Parameters registry maintained by the Internet Assigned
+   Numbers Authority (IANA).
+
+   [Note to IANA and the RFC Editor, to be deleted before publication
+   of this draft as an RFC: The RTP Payload Types table referenced in
+   the previous paragraph is "closed" per the policy change
+   established in draft-ietf-avt-profile-new-12, but that draft also
+   says "Payload type 13 is reserved for a comfort noise payload
+   format to be specified in a separate RFC."  This document is
+   intended to be that separate RFC.]
 
 7.1 Registration of MIME media type audio/CN
 
@@ -229,7 +268,11 @@
 
    Required parameters: None
 
-   Optional parameters: rate
+   Optional parameters:
+   rate: specifies the RTP timestamp clock rate, which is usually (but
+   not always) equal to the sampling rate.  This parameter should have
+   the same value as the codec used in conjunction with comfort noise.
+   The default value is 8000.

 Zopf                Standards Track - April, 2002                   4
@@ -238,8 +281,7 @@

    Encoding considerations:
-   This type is only defined for transfer via RTP [RFC XXXX, draft-
-   ietf-avt-rtp-new].
+   This type is only defined for transfer via RTP [RFC 1889].
 
    Security considerations: see Section 8 "Security Considerations".
 
@@ -318,6 +360,14 @@
       vectors for implementation verification of the algorithm of the
       G.729 silence compression scheme.
 
+   11 Schulzrinne, H., "RTP Profile for Audio and Video Conferences
+      with Minimal Control", RFC 1890, January 1996.
+
+   12 Handley, M. and V. Jacobson, "SDP: Session Description
+      Protocol", RFC 2327, April 1998.
+
+   13 Luthi, P., "RTP Payload Format for ITU-T Recommendation
+      G.722.1", RFC 3047, January 2001.

 9. Author's Address