Security considerations:
See Section 7 "Security Considerations" of RFC 4298.
Intended usage:
COMMON. It is expected that many VoIP applications, especially
Voice over Cable applications, will use this type.
Person & email address to contact for further information:
Juin-Hwey (Raymond) Chen
rchen@broadcom.com
Author/Change controller:
Author: Juin-Hwey (Raymond) Chen, rchen@broadcom.com
Change Controller: IETF Audio/Video Transport Working Group
delegated from the IESG
6. Mapping to SDP Parameters
The information carried in the MIME media type specification has a
specific mapping to fields in the Session Description Protocol (SDP)
[4], which is commonly used to describe RTP sessions. When SDP is
used to specify sessions employing the BroadVoice16 or BroadVoice32
codec, the mapping is as follows:
- The MIME type ("audio") goes in SDP "m=" as the media name.
- The MIME subtype (payload format name) goes in SDP "a=rtpmap"
as the encoding name. The RTP clock rate in "a=rtpmap" MUST be
8000 for BV16 and 16000 for BV32.
- The parameters "ptime" and "maxptime" go in the SDP "a=ptime"
and "a=maxptime" attributes, respectively.
An example of the media representation in SDP for describing BV16
might be:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 BV16/8000
An example of the media representation in SDP for describing BV32
might be:
m=audio 49122 RTP/AVP 99
a=rtpmap:99 BV32/16000
6.1. Offer-Answer Model Considerations
No special considerations are needed for using the SDP Offer/Answer
model [5] with the BV16 and BV32 RTP payload formats.
7. Security Considerations
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, [6]).
This implies that confidentiality of the media streams is achieved by
encryption.
A potential denial-of-service threat exists for data encoding using
compression techniques that have non-uniform receiver-end
computational load. The attacker can inject pathological datagrams
into the stream that are complex to decode and cause the receiver to
become overloaded. However, the encodings covered in this document
do not exhibit any significant non-uniformity.
8. Congestion Control
The general congestion control considerations for transporting RTP
data apply to BV16 and BV32 audio over RTP as well (see RTP [1]) and
any applicable RTP profile like AVP [6]. BV16 and BV32 do not have
any built-in mechanism for reducing the bandwidth. Packing more
frames in each RTP payload can reduce the number of packets sent, and
hence the overhead from IP/UDP/RTP headers, at the expense of
increased delay and reduced error robustness against packet losses.
9. Acknowledgements
The authors would like to thank Magnus Westerlund, Colin Perkins,
Allison Mankin, and Jean-Francois Mule for their review of this
document.
10. References
10.1. Normative References
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Cable Television Laboratories, Inc., BroadVoice(TM)16 Speech
Codec Specification, Revision 1.2, October 30, 2003.
[4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[6] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[7] 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.
10.2. Informative References
[8] Cable Television Laboratories, Inc., PacketCable(TM) 1.5
Audio/Video Codecs Specification, PKT-SP-CODEC1.5-I01-050128,
January 28, 2005.
http://www.cablelabs.com/specifications/archives/
Authors’ Addresses
Juin-Hwey (Raymond) Chen
Broadcom Corporation
Room A3020
16215 Alton Parkway
Irvine, CA 92618
USA
Phone: +1 949 926 6288
EMail: rchen@broadcom.com
Winnie Lee
Broadcom Corporation
Room A2012E
200-13711 International Place
Richmond, British Columbia V6V 2Z8
Canada
Phone: +1 604 233 8605
EMail: wlee@broadcom.com
Jes Thyssen
Broadcom Corporation
Room A3018
16215 Alton Parkway
Irvine, CA 92618
USA
Phone: +1 949 926 5768
EMail: jthyssen@broadcom.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.