Protocol Action: 'RTP Payload Format for BroadVoice Speech Codecs' to Proposed Standard

[The IESG <iesg-secretary at ietf.org>]

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.


_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce