From: The IESG To: IETF-Announce Message-Id: Date: Mon, 30 May 2005 19:12:04 -0400 Subject: Protocol Action: 'RTP Payload Format for BroadVoice Speech Codecs' to Proposed Standard The IESG has approved the following document: - 'RTP Payload Format for BroadVoice Speech Codecs ' as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary: This specification describes an RTP payload format for the BroadVoice (TM) speech codec. It is a very straight-forward payload format, with one or more frames of coded speech data being placed into each RTP packet with no additional framing. Definitions to allow the use of this format with SDP and MIME are provided. Working Group Summary: The working group supported advancing this specification. The IETF has received a request from Cablelabs to publish this specification quickly. Protocol Quality: The BroadVoice(TM) codec is likely to see widespread use in certain communities. The design of the codec is a very good fit with the RTP framework, and hence this protocol is simple and of high quality. MIME media types review received no comments. Notes to the RFC Editor Abstract OLD: This document describes the RTP payload format for the BroadVoice(TM) narrowband and wideband speech codecs developed by Broadcom Corporation. NEW: This document describes the RTP payload format for the BroadVoice(TM) narrowband and wideband speech codecs. The narrowband codec, called BroadVoice16, or BV16, has been selected by CableLabs as a mandatory codec in PacketCable 1.5 and has a CableLabs specification. Section 2, first paragraph OLD: BroadVoice is a speech codec family developed by Broadcom for VoIP (Voice over Internet Protocol) applications, including Voice over Cable, Voice over DSL, and IP phone applications. NEW: BroadVoice is a speech codec family developed for VoIP (Voice over Internet Protocol) applications, including Voice over Cable, Voice over DSL, and IP phone applications. Section 2, second paragraph: OLD: More specifically, the BV16 codec was selected as one of the mandatory audio codecs in PacketCable (TM) 1.5 Audio/Video Codecs Specification [4]. NEW: More specifically, the BV16 codec was selected as one of the mandatory audio codecs in PacketCable (TM) 1.5 Audio/Video Codecs Specification [4] and has been implemented by multiple vendors. The wideband version (BV32) has been developed by Broadcom but has not yet appeared in a public specification; since it is technically very similar to BV16, its payload format is also defined in this document. Section 3.1, Figure 1: Please remove blank line under L0, L1 etc. row in the figure. Section 5.1, "maxptime" bullet OLD: maxptime: See RFC 2327 [5] for its definition. The maxptime SHOULD be a multiple of the duration of a single codec data frame (5 ms). NEW: maxptime: See RFC 3267 [8] for its definition. The maxptime SHOULD be a multiple of the duration of a single codec data frame (5 ms). Section 10.1: One new normative reference: NEW: [8] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002. Section 7: First paragraph OLD: RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [1] and any appropriate profile (for example, [7]). This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations. NEW: RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [1] and any appropriate profile (for example, [7]). This implies that confidentiality of the media streams is achieved by encryption. Removal of the last sentence! Section: 9 OLD: The authors would like to thank Magnus Westerlung, Colin Perkins, Allison Mankin, and Jean-Francois Mule for their review of this document. NEW The authors would like to thank Magnus Westerlund, Colin Perkins, ^ Allison Mankin, and Jean-Francois Mule for their review of this document.