Subject: [AVT] CN reference from RTP A/V profile

From: Stephen Casner <[email-masked]>
Date: Tue, 18 Sep 2001 13:23:47 -0700 (PDT)

In several RTP profile draft revisions, static payload type 13 has
been listed as "reserved" because we thought the CN payload format
specification (which follows the ITU comfort noise specification)
would not be completed before we published the updated RTP spec and
profile.  However, the schedule for the RTP spec and profile documents
has slipped considerably, so CN is ready at the same time.  Hence, it
seems silly to have static payload type 13 marked "reserved" rather
than "CN" and to say "Payload type 13 is reserved for a comfort noise
payload format to be specified in a separate RFC" rather than
referencing the RFC, i.e., making the CN draft be part of the package
of drafts processed together.

Comments?  Would this introduce a problem for the interoperability
requirements?  Are there interoperable implementations using static
payload type 13 for comfort noise (either the short version with just
noise level as originallly specified, or the extended version with
spectral coefficients as in draft-ietf-avt-rtp-cn-xx)?

							-- Steve

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

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 19 Sep 2001 11:25:45 -0400

Given that we are deprecating use of static payload types in general
(right?) it seems strange to assign one when we have the opportunity to
avoid doing so.

Perhaps we could just make 13 "reserved - not to be assigned"?

Dave.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stephen Casner
> Sent: Tuesday, September 18, 2001 4:24 PM
> To: AVT WG
> Subject: [AVT] CN reference from RTP A/V profile
> 
> 
> In several RTP profile draft revisions, static payload type 
> 13 has been listed as "reserved" because we thought the CN 
> payload format specification (which follows the ITU comfort 
> noise specification) would not be completed before we 
> published the updated RTP spec and profile.  However, the 
> schedule for the RTP spec and profile documents has slipped 
> considerably, so CN is ready at the same time.  Hence, it 
> seems silly to have static payload type 13 marked "reserved" 
> rather than "CN" and to say "Payload type 13 is reserved for 
> a comfort noise payload format to be specified in a separate 
> RFC" rather than referencing the RFC, i.e., making the CN 
> draft be part of the package of drafts processed together.
> 
> Comments?  Would this introduce a problem for the 
> interoperability requirements?  Are there interoperable 
> implementations using static payload type 13 for comfort 
> noise (either the short version with just noise level as 
> originallly specified, or the extended version with spectral 
> coefficients as in draft-ietf-avt-rtp-cn-xx)?
> 
> 							-- Steve
> 
>

---

From: Stephen Casner <[email-masked]>
Date: Wed, 19 Sep 2001 15:25:42 -0700 (PDT)

Dave,

> (right?) it seems strange to assign one when we have the opportunity to

Yes, we are deprecating the use of static payload types in general.
However, we made this assignment of payload type 13 for CN in earlier
versions of draft-ietf-avt-profile-new, and I believe there are
implementations that are using it (perhaps even some at Cisco).
Therefore, it is one of the assignments accepted before the
deprecation began.
							-- Steve