Subject: CN payload type

From: "James Kroll" <[email-masked]>
Date: Thu, 20 Jan 2000 16:21:20 -0600

Hello:

Can someone please clear up this confusion over the RTP CN payload type?
In the most recent RTP profile document, both 13 and 19 are listed as reserved
payload types.

>From reading the intro, it sounds to me like the PT will ultimately be 13. Is
this correct?

Also, there is reference to a seperate draft which addresses CN frames. What is
that
draft called?

Finally, what work is being done in the ITU related to this issue?

Thanks for any help you can provide.

James Kroll
3Com

---

From: Stephen Casner <[email-masked]>
Date: Thu, 20 Jan 2000 17:08:57 -0800 (Pacific Standard Time)

> In the most recent RTP profile document, both 13 and 19 are listed as reserved

Here is an explanation from the minutes of the AVT meeting at IETF in
November:

  The question of how to deal with proposed enhancements to the comfort noise
  payload format to include spectral shape parameters was raised. This work is
  ongoing in the ITU-T SG16, but will take time to complete - we don't want to
  wait for this, before we advance RTP. There are a number of options:
	  - Leave the current comfort noise payload format as is, and define a
	    new payload format for the extension
	  - Enhance this format, so if it is longer than 1 byte it
	    includes extra spectral information
	  - Remove this payload format from the profile, so as not to hold the
	    profile up, but leave the payload type assigned (with a note being
	    added to the profile that payload type 13 is reserved for a comfort
	    noise payload format which will be specified later).
  The chairs proposed taking this latter option, but this raised a number of
  questions about the status of the revised comfort noise draft (which is in
  use in a number of products) and the ability of the profile to reference
  it. After some discussion, a hybrid of these options was chosen: the
  comfort noise payload format will be extracted from the audio/video profile
  and submitted as a proposed standard RFC, referenced by the profile. Steve
  Casner will do this as part of editing the profile.  The ITU-T will extend
  this, in the same manner as any other payload format is extended, with the
  expectation that it will cycle at proposed standard.
 
> From reading the intro, it sounds to me like the PT will ultimately be 13. Is

Yes.  If you have already implemented CN as it was specified in
previous profile drafts, you can continue to use that CN paylod format
with static payload type 13.

> Also, there is reference to a seperate draft which addresses CN
> frames. What is that draft called?

I have done the extraction from the profile document, as you have
observed, but I have not yet reconstituted that extracted part into
the separate draft.  That will be done ASAP, and will be the same as
what was previously in the profile document.

> Finally, what work is being done in the ITU related to this issue?

The current spec is just a noise energy level.  The additional work is
to add spectral information, as noted in the minutes above.  It will
either be done in a backward-compatible way or as a second comfort
noise payload format.
							-- Steve