RE: [AVT] Protocol Action: 'RTP Payload Format for BroadVoice Speech Codecs' to Proposed Standard

["Raymond (Juin-Hwey) Chen" <[e-mail]>]

The source codes for the BroadVoice speech codecs are available for
licensing.

Raymond

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Mike
Sent: Tuesday, June 07, 2005 5:59 AM
To: [e-mail]
Subject: Re: [AVT] Protocol Action: 'RTP Payload Format for BroadVoice Speech
Codecs' to Proposed Standard

Is source code for the BroadVoice Speech codec readily available?

Thank you.

----- Original Message ----- 
From: "The IESG" <[e-mail]>
To: "IETF-Announce" <[e-mail]>
Cc: "avt chair" <[e-mail]>; "avt chair" 
<[e-mail]>; "Internet Architecture Board" <[e-mail]>; "avt 
mailing list" <[e-mail]>; "RFC Editor" <[e-mail]>
Sent: Monday, May 30, 2005 7:12 PM
Subject: [AVT] 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 '
>   <draft-ietf-avt-rtp-bv-04.txt> 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.
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt
> 

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt



_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt