RFC 7007

Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)

📅 published August 2013, from ietf

okay bestie, this is RFC 7007 🦋 and it's written by T. Terriberry of Mozilla Corporation, published in August 2013. It's a Standards Track doc with ISSN 2070-1721, and it updates RFC 3551 🎀. It doesn't list anything it obsoletes.

The full title is "Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)" ✨

Abstract 🌸

okay so the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) is the base for a bunch of other profiles 👑 like the Secure Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF), and the Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF). this doc updates RFC 3551, which is the RTP/AVP profile (and the profiles built on top of it by extension) 💅 so it matches how audio codecs are actually used now, since RFC 3551 came out.

Status of This Memo 🧚

this is an Internet Standards Track document ✨

it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🫶 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). for more on Internet Standards, see Section 2 of RFC 5741.

for the current status, errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7007 🦋

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. read them carefully, because they explain your rights and restrictions 🙈 any Code Components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes.

Table of Contents 📋

1. Introduction ....................................................2
2. Terminology .....................................................2
3. Updates to RFC 3551 .............................................3
   3.1. Updates to Section 6 of RFC 3551 ...........................3
4. Security Considerations .........................................3
5. Acknowledgments .................................................3
6. References ......................................................4
   6.1. Normative References .......................................4
   6.2. Informative References .....................................4

1. Introduction ✨

okay so [RFC3551] says audio apps running under the RTP/AVP profile SHOULD be able to send and receive PCMU and DVI4 💖 but in practice, lots of RTP deployments don't support DVI4 😭 and there's barely any reason to use it when way more modern codecs exist. this doc updates the recommended audio codec selection for RTP/AVP and removes the SHOULD for DVI4 🔥 by extension, it also updates the profiles that build on RTP/AVP, including RTP/SAVP [RFC3711], RTP/AVPF [RFC4585], and RTP/SAVPF [RFC5124] 🎀

2. Terminology 💅

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in [RFC2119] 🫶

3. Updates to RFC 3551 🍓

this is the bit of [RFC3551] that gets updated, as set out in Section 3.1 👑

Audio applications operating under this profile SHOULD, at a minimum, be able to send and/or receive payload types 0 (PCMU) and 5 (DVI4). This allows interoperability without format negotiation and ensures successful negotiation with a conference control protocol.

3.1. Updates to Section 6 of RFC 3551 🦋

this doc updates the final paragraph of Section 6 of RFC 3551 by swapping "payload types 0 (PCMU) and 5 (DVI4)" for "payload type 0 (PCMU)" 🌸 we also tack a final sentence onto that paragraph saying, "Some environments necessitate support for PCMU". so the paragraph ends up looking like this ✨

Audio applications operating under this profile SHOULD, at a minimum, be able to send and/or receive payload type 0 (PCMU). This allows interoperability without format negotiation and ensures successful negotiation with a conference control protocol. Some environments necessitate support for PCMU.

4. Security Considerations 🔥

this doc doesn't add any new security considerations for [RFC3551] 💀 no new risks here, but the existing ones from RFC 3551 still apply in full, so don't skip them 🙈

5. Acknowledgments 🧚

thanks to Colin Perkins for suggesting this update 💜

6. References 📚

6.1. Normative References 💖

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
           Video Conferences with Minimal Control", STD 65, RFC 3551,
           July 2003.

6.2. Informative References 🌈

[RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
           Norrman, "The Secure Real-time Transport Protocol (SRTP)",
           RFC 3711, March 2004.

[RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
           "Extended RTP Profile for Real-time Transport Control
           Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July
           2006.

[RFC5124]  Ott, J. and E. Carrara, "Extended Secure RTP Profile for
           Real-time Transport Control Protocol (RTCP)-Based Feedback
           (RTP/SAVPF)", RFC 5124, February 2008.

Author's Address 🎀

Timothy B. Terriberry
Mozilla Corporation
650 Castro Street
Mountain View, CA  94041
USA

Phone: +1 650 903-0800
EMail: tterribe@xiph.org
📦 where this page comes from