Internet Engineering Task Force (IETF) JM. Valin
Request for Comments: 6569 Mozilla
Category: Informational S. Borilin
ISSN: 2070-1721 SPIRIT DSP
K. Vos
Internet Engineering Task Force (IETF) JM. Valin
Request for Comments: 6569 Mozilla
Category: Informational S. Borilin
ISSN: 2070-1721 SPIRIT DSP
K. Vos
C. Montgomery Xiph.Org Foundation R. Chen Broadcom Corporation March 2012
C. Montgomery Xiph .org基金会陈博通公司2012年3月
Guidelines for Development of an Audio Codec within the IETF
IETF中音频编解码器的开发指南
Abstract
摘要
This document provides general guidelines for work on developing and specifying an interactive audio codec within the IETF. These guidelines cover the development process, evaluation, requirements conformance, and intellectual property issues.
本文档提供了IETF中开发和指定交互式音频编解码器的一般指南。这些指南涵盖了开发过程、评估、需求一致性和知识产权问题。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6569.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6569.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您在以下方面的权利和限制：
to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
请参阅本文件。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Development Process .............................................2
3. Evaluation, Testing, and Characterization .......................5
4. Specifying the Codec ............................................6
5. Intellectual Property ...........................................8
6. Relationship with Other SDOs ...................................10
7. Security Considerations ........................................12
8. Acknowledgments ................................................12
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................12
1. Introduction ....................................................2
2. Development Process .............................................2
3. Evaluation, Testing, and Characterization .......................5
4. Specifying the Codec ............................................6
5. Intellectual Property ...........................................8
6. Relationship with Other SDOs ...................................10
7. Security Considerations ........................................12
8. Acknowledgments ................................................12
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................12
This document describes a process for work in the IETF codec WG on standardization of an audio codec that is optimized for use in interactive Internet applications and that can be widely implemented and easily distributed among application developers, service operators, and end users.
本文档描述了IETF编解码器工作组关于音频编解码器标准化的工作流程，该编解码器针对交互式互联网应用程序进行了优化，可广泛实施，并可在应用程序开发人员、服务运营商和最终用户之间轻松分发。
The process outlined here is intended to make the work on a codec within the IETF transparent, predictable, and well organized, in a way that is consistent with [PROCESS]. Such work might involve development of a completely new codec, adaptation of an existing codec to meet the requirements of the working group, or integration of two or more existing codecs that results in an improved codec combining the best aspects of each. To enable such procedural transparency, the contributor of an existing codec must be willing to cede change control to the IETF and should have sufficient knowledge of the codec to assist in the work of adapting it or applying some of its technology to the development or improvement of other codecs. Furthermore, contributors need to be aware that any codec that results from work within the IETF is likely to be different from any existing codec that was contributed to the Internet Standards Process.
此处概述的过程旨在使IETF内的编解码器工作透明、可预测且组织良好，其方式与[过程]一致。这类工作可能涉及开发全新的编解码器、修改现有编解码器以满足工作组的要求，或者集成两个或多个现有编解码器，从而产生一个结合了每个编解码器的最佳方面的改进编解码器。为了实现这样的程序透明性，现有编解码器的贡献者必须愿意将更改控制权让给IETF，并且应该对编解码器有足够的了解，以帮助调整编解码器或将其某些技术应用于其他编解码器的开发或改进。此外，贡献者需要意识到，IETF内工作产生的任何编解码器可能不同于互联网标准过程中贡献的任何现有编解码器。
Work on developing an interactive audio codec is expected to proceed as follows:
开发交互式音频编解码器的工作预计将按以下方式进行：
1. IETF participants will identify the requirements to be met by an Internet codec in the form of an Internet-Draft.
1. IETF参与者将以互联网草案的形式确定互联网编解码器要满足的要求。
2. Interested parties are encouraged to make contributions proposing existing or new codecs, or elements thereof, to the codec WG as long as these contributions are within the scope of the WG. Ideally, these contributions should be in the form of Internet-Drafts, although other forms of contributions are also possible, as discussed in [PROCESS].
2. 鼓励感兴趣的各方向编解码器工作组提供建议现有或新编解码器或其元素的贡献，只要这些贡献在工作组的范围内。理想情况下，这些贡献应该以互联网草稿的形式出现，尽管也可以有其他形式的贡献，如[过程]中所述。
3. Given the importance of intellectual property rights (IPR) to the activities of the working group, any IPR disclosures must be made in a timely way. Contributors are required, as described in [IPR], to disclose any known IPR, both first and third party. Timely disclosures are particularly important, since those disclosures may be material to the decision process of the working group.
3. 鉴于知识产权对工作组活动的重要性，必须及时披露任何知识产权信息。如[IPR]所述，撰稿人必须披露任何已知的第一方和第三方知识产权。及时披露尤为重要，因为这些披露可能对工作组的决策过程至关重要。
4. As contributions are received and discussed within the working group, the group should gain a clearer understanding of what is achievable within the design space. As a result, the authors of the requirements document should iteratively clarify and improve their document to reflect the emerging working group consensus. This is likely to involve collaboration with IETF working groups in other areas, such as collaboration with working groups in the Transport area to identify important aspects of packet transmission over the Internet and to understand the degree of rate adaptation desirable and with working groups in the RAI area to ensure that information about and negotiation of the codec can be easily represented at the signaling layer. In parallel with this work, interested parties should evaluate the contributions at a higher level to see which requirements might be met by each codec.
4. 随着工作组收到并讨论了意见，工作组应更清楚地了解在设计空间内可以实现什么。因此，需求文档的作者应该反复澄清和改进他们的文档，以反映工作组正在形成的共识。这可能涉及与IETF工作组在其他领域的合作，例如，与传输区域中的工作组协作以识别通过因特网的分组传输的重要方面并理解期望的速率适应程度，并与RAI区域中的工作组协作以确保关于编解码器的信息和协商可以在信令层容易地表示。在进行这项工作的同时，感兴趣的各方应该在更高的层次上评估贡献，以确定每个编解码器可能满足哪些要求。
5. Once a sufficient number of proposals has been received, the interested parties will identify the strengths, weaknesses, and innovative aspects of the contributed codecs. This step will consider not only the codecs as a whole, but also key features of the individual algorithms (predictors, quantizers, transforms, etc.).
5. 一旦收到足够数量的提案，相关方将确定所提供编解码器的优势、劣势和创新方面。这一步不仅要考虑编解码器作为一个整体，但也关键的特点，个别算法（预测，量化器，变换等）。
6. Interested parties are encouraged to collaborate and combine the best ideas from the various codec contributions into a consolidated codec definition, representing the merging of some of the contributions. Through this iterative process, the number
6. 鼓励感兴趣的各方进行合作，将各种编解码器贡献中的最佳想法合并到一个统一的编解码器定义中，这代表了部分贡献的合并。通过这个迭代过程，数字
of proposals will reduce, and consensus will generally form around one of them. At that point, the working group should adopt that document as a working group item, forming a baseline codec.
提案的数量将减少，并且通常会围绕其中一个提案形成共识。届时，工作组应将该文件作为工作组项目予以通过，形成一个基线编解码器。
7. IETF participants should then attempt to iteratively add to or improve each component of the baseline codec reference implementation, where by "component" we mean individual algorithms such as predictors, transforms, quantizers, and entropy coders. The participants should proceed by trying new designs, applying ideas from the contributed codecs, evaluating "proof of concept" ideas, and using their expertise in codec development to improve the baseline codec. Any aspect of the baseline codec might be changed (even the fundamental principles of the codec), or the participants might start over entirely by scrapping the baseline codec and designing a completely new one. The overriding goal shall be to design a codec that will meet the requirements defined in the requirements document [CODEC-REQ]. Given the IETF's open standards process, any interested party will be able to contribute to this work, whether or not they submitted an Internet-Draft for one of the contributed codecs. The codec itself should be normatively specified with code in an Internet-Draft.
7. 然后，IETF参与者应尝试迭代添加或改进基线编解码器参考实现的每个组件，其中“组件”是指单独的算法，如预测器、变换器、量化器和熵编码器。参与者应尝试新的设计，应用贡献的编解码器的想法，评估“概念验证”想法，并使用编解码器开发方面的专业知识改进基线编解码器。基线编解码器的任何方面都可能会改变（甚至是编解码器的基本原理），或者参与者可能会完全从废弃基线编解码器和设计全新的编解码器开始。首要目标应是设计满足需求文件[codec-REQ]中定义要求的编解码器。考虑到IETF的开放标准过程，任何相关方都将能够为这项工作做出贡献，无论他们是否为其中一个贡献的编解码器提交了互联网草案。编解码器本身应该在互联网草案中用代码规范地指定。
8. In parallel with work on the codec reference implementation, developers and other interested parties should perform evaluation of the codec as described under Section 3. IETF participants should define (within the PAYLOAD working group) the codec's payload format for use with the Real-time Transport Protocol [RTP]. Ideally, application developers should test the codec by implementing it in code and deploying it in actual Internet applications. Unfortunately, developers will frequently wait to deploy the codec until it is published as an RFC or until a stable bitstream is guaranteed. As such, this is a nice-to-have and not a requirement for this process. Lab implementations are certainly encouraged.
8. 在编解码器参考实现工作的同时，开发人员和其他相关方应按照第3节所述对编解码器进行评估。IETF参与者应（在有效载荷工作组内）定义编解码器的有效载荷格式，以便与实时传输协议[RTP]一起使用。理想情况下，应用程序开发人员应该通过在代码中实现编解码器并将其部署到实际的Internet应用程序中来测试编解码器。不幸的是，开发人员经常会等到编解码器发布为RFC或保证稳定的比特流后再部署编解码器。因此，这是一个很好的选择，而不是这个过程的要求。当然鼓励实验室实施。
9. The group will produce a testing results document. The document will be a living document that captures testing done before the codec stabilized, after it has stabilized, and after the codec specification is issued as an RFC. The document serves the purpose of helping the group determine whether the codec meets the requirements. Any testing done after the codec RFC is issued helps implementers understand the final performance of the codec. The process of testing is described in Section 3.
9. 该小组将编制一份测试结果文件。该文档将是一个动态文档，捕获编解码器稳定之前、稳定之后以及编解码器规范作为RFC发布之后所做的测试。该文档旨在帮助小组确定编解码器是否满足要求。在编解码器RFC发布后进行的任何测试都有助于实现人员了解编解码器的最终性能。第3节描述了测试过程。
Lab evaluation of the codec being developed should happen throughout the development process because it will help ensure that progress is being made toward fulfillment of the requirements. There are many ways in which continuous evaluation can be performed. For minor, uncontroversial changes to the codec, it should usually be sufficient to use objective measurements (e.g., Perceptual Evaluation of Speech Quality (PESQ) [ITU-T-P.862], Perceptual Evaluation of Audio Quality (PEAQ) [ITU-R-BS.1387-1], and segmental signal-to-noise ratio) validated by informal subjective evaluation. For more complex changes (e.g., when psychoacoustic aspects are involved) or for controversial issues, internal testing should be performed. An example of internal testing would be to have individual participants rate the decoded samples using one of the established testing methodologies, such as MUltiple Stimuli with Hidden Reference and Anchor (MUSHRA) [ITU-R-BS.1534].
对正在开发的编解码器的实验室评估应该在整个开发过程中进行，因为这将有助于确保在满足需求方面取得进展。可以通过多种方式进行持续评估。对于编解码器的微小且无争议的变化，通常应使用经非正式主观评估验证的客观测量（例如，语音质量感知评估（PESQ）[ITU-T-P.862]、音频质量感知评估（PEAQ）[ITU-R-BS.1387-1]和分段信噪比）即可。对于更复杂的变化（例如，当涉及心理声学方面）或有争议的问题，应进行内部测试。内部测试的一个例子是让个体参与者使用一种已建立的测试方法对解码样本进行评级，例如具有隐藏参考和锚定的多刺激（MUSHRA）[ITU-R-BS.1534]。
Throughout the process, it will be important to make use of the Internet community at large for real-world distributed testing. This will enable many different people with different equipment and use cases to test the codec and report any problems they experience. In the same way, third-party developers will be encouraged to integrate the codec into their software (with a warning about the bitstream not being final) and provide feedback on its performance in real-world use cases.
在整个过程中，利用整个互联网社区进行真实世界的分布式测试非常重要。这将使许多使用不同设备和用例的不同人员能够测试编解码器并报告他们遇到的任何问题。同样，将鼓励第三方开发人员将编解码器集成到他们的软件中（并警告比特流不是最终的），并在实际用例中提供关于其性能的反馈。
Characterization of the final codec must be based on the reference implementation only (and not on any "private implementation"). This can be performed by independent testing labs or, if this is not possible, by testing labs of the organizations that contribute to the Internet Standards Process. Packet-loss robustness should be evaluated using actual loss patterns collected from use over the Internet, rather than theoretical models. The goals of the characterization phase are to:
最终编解码器的特性必须仅基于参考实现（而不是任何“私有实现”）。这可以由独立的测试实验室执行，如果不可能，也可以由参与互联网标准过程的组织的测试实验室执行。数据包丢失稳健性应使用从互联网使用中收集的实际丢失模式，而不是理论模型进行评估。表征阶段的目标是：
o ensure that the requirements have been fulfilled
o 确保已满足要求
o guide the IESG in its evaluation of the resulting work
o 指导IESG对结果工作进行评估
o assist application developers in understanding whether the codec is suitable for a particular application
o 帮助应用程序开发人员了解编解码器是否适用于特定应用程序
The exact methodology for the characterization phase can be determined by the working group. Because the IETF does not have testing resources of its own, it has to rely on the resources of its participants. For this reason, even if the group agrees that a particular test is important, if no one volunteers to do it, or if
表征阶段的确切方法可由工作组确定。由于IETF没有自己的测试资源，它必须依赖参与者的资源。因此，即使小组同意某项测试很重要，如果没有人自愿做，或者
volunteers do not complete it in a timely fashion, then that test should be discarded. This ensures that only important tests be done -- in particular, the tests that are important to participants.
志愿者没有及时完成测试，那么就应该放弃该测试。这确保了只进行重要的测试，特别是对参与者来说很重要的测试。
Specifying a codec requires careful consideration regarding what is required versus what is left to the implementation. The following text provides guidelines for consideration by the working group:
指定编解码器需要仔细考虑所需内容与留给实现的内容。以下案文提供了供工作组审议的准则：
1. Any audio codec specified by the codec working group must include source code for a normative software implementation, documented in an Internet-Draft intended for publication as a Standards Track RFC. This implementation will be used to verify conformance of an implementation. Although a text description of the algorithm should be provided, its use should be limited to helping the reader in understanding the source code. Should the description contradict the source code, the latter shall take precedence. For convenience, the source code may be provided in compressed form, with base64 [BASE64] encoding.
1. 编解码器工作组指定的任何音频编解码器必须包含标准软件实现的源代码，并记录在互联网草案中，以作为标准曲目RFC发布。此实现将用于验证实现的一致性。虽然应提供算法的文本描述，但其使用应限于帮助读者理解源代码。如果描述与源代码冲突，应以后者为准。为方便起见，源代码可以以压缩形式提供，采用base64[base64]编码。
2. Because of the size and complexity of most codecs, it is possible that even after publishing the RFC, bugs will be found in the reference implementation, or differences will be found between the implementation and the text description. As usual, an errata list should be maintained for the RFC. Although a public software repository containing the current reference implementation is desirable, the normative implementation would still be the RFC.
2. 由于大多数编解码器的大小和复杂性，即使在发布RFC之后，也有可能在参考实现中发现bug，或者在实现和文本描述之间发现差异。通常，应为RFC维护勘误表。尽管需要一个包含当前参考实现的公共软件存储库，但规范性实现仍然是RFC。
3. It is the intention of the group to allow the greatest possible choice of freedom in implementing the specification. Accordingly, the number of binding RFC 2119 [KEYWORDS] keywords will be the minimum that still allows interoperable implementations. In practice, this generally means that only the decoder needs to be normative, so that the encoder can improve over time. This also enables different trade-offs between quality and complexity.
3. 小组的目的是在实施规范时允许最大可能的自由选择。因此，绑定RFC 2119[关键字]关键字的数量将是允许互操作实现的最小数量。在实践中，这通常意味着只有解码器需要规范，以便编码器可以随着时间的推移而改进。这还可以在质量和复杂性之间进行不同的权衡。
4. To reduce the risk of bias towards certain CPU/DSP (central processing unit / digital signal processor) architectures, ideally the decoder specification should not require "bit-exact" conformance with the reference implementation. In that case, the output of a decoder implementation should only be "close enough" to the output of the reference decoder, and a comparison tool should be provided along with the codec to verify objectively that the output of a decoder is likely to be perceptually indistinguishable from that of the reference decoder. An
4. 为了降低偏向某些CPU/DSP（中央处理单元/数字信号处理器）架构的风险，理想情况下，解码器规范不应要求与参考实现“位精确”一致。在这种情况下，解码器实现的输出应当仅“足够接近”参考解码器的输出，并且应当与编解码器一起提供比较工具，以客观地验证解码器的输出可能在感知上与参考解码器的输出不可区分。一
implementation may still wish to produce an output that is bit-exact with the reference implementation to simplify the testing procedure.
实现可能仍然希望生成与参考实现位精确的输出，以简化测试过程。
5. To ensure freedom of implementation, decoder-side-only error concealment does not need to be specified, although the reference implementation should include the same packet-loss concealment (PLC) algorithm as used in the testing phase. Is it up to the working group to decide whether minimum requirements on PLC quality will be required for compliance with the specification. Obviously, any information signaled in the bitstream intended to aid PLC needs to be specified.
5. 为确保实现的自由度，无需指定仅解码器端错误隐藏，尽管参考实现应包括与测试阶段相同的丢包隐藏（PLC）算法。是否需要由工作组决定PLC质量的最低要求是否符合规范。显然，需要指定位流中用于辅助PLC的任何信息。
6. An encoder implementation should not be required to make use of all the "features" (tools) in the bitstream definition. However, the codec specification may require that an encoder implementation be able to generate any possible bitrate. Unless a particular "profile" is defined in the specification, the decoder must be able to decode all features of the bitstream. The decoder must also be able to handle any combination of bits, even combinations that cannot be generated by the reference encoder. It is recommended that the decoder specification shall define how the decoder should react to "impossible" packets (e.g., reject or consider as valid). However, an encoder must never generate packets that do not conform to the bitstream definition.
6. 编码器实现不需要使用比特流定义中的所有“功能”（工具）。然而，编解码器规范可能要求编码器实现能够生成任何可能的比特率。除非规范中定义了特定的“简档”，否则解码器必须能够解码比特流的所有特征。解码器还必须能够处理任何比特组合，甚至是不能由参考编码器生成的组合。建议解码器规范应定义解码器应如何应对“不可能”分组（例如，拒绝或认为有效）。但是，编码器决不能生成不符合位流定义的数据包。
7. Compressed test vectors should be provided as a means to verify conformance with the decoder specification. These test vectors should be designed to exercise as much of the decoder code as possible.
7. 应提供压缩测试向量，作为验证是否符合解码器规范的手段。这些测试向量应设计为尽可能多地使用解码器代码。
8. While the exact encoder will not be specified, it is recommended to specify objective measurement targets for an encoder, below which use of a particular encoder implementation is not recommended. For example, one such specification could be: "the use of an encoder whose PESQ mean opinion score (MOS) is better than 0.1 below the reference encoder in the following conditions is not recommended".
8. 虽然不会指定确切的编码器，但建议指定编码器的客观测量目标，低于此目标，不建议使用特定的编码器实现。例如，一个这样的规范可以是：“不建议在以下条件下使用PESQ平均意见分数（MOS）比参考编码器低0.1的编码器”。
Producing an unencumbered codec is desirable for the following reasons:
出于以下原因，需要生成无阻碍的编解码器：
o It is the experience of a wide variety of application developers and service providers that encumbrances such as licensing and royalties make it difficult to implement, deploy, and distribute multimedia applications for use by the Internet community.
o 各种各样的应用程序开发人员和服务提供商的经验表明，许可证和特许权使用费等障碍使得实现、部署和分发供互联网社区使用的多媒体应用程序变得困难。
o It is beneficial to have low-cost options whenever possible, because innovation -- the hallmark of the Internet -- is hampered when small development teams cannot deploy an application because of usage-based licensing fees and royalties.
o 只要有可能，低成本的选择是有益的，因为创新——互联网的标志——在小型开发团队由于基于使用的许可费和版税而无法部署应用程序时会受到阻碍。
o Many market segments are moving away from selling hard-coded hardware devices and toward freely distributing end-user software; this is true of numerous large application providers and even telcos themselves.
o 许多细分市场正在从销售硬编码硬件设备转向自由分发最终用户软件；许多大型应用程序提供商甚至电信公司本身都是如此。
o Compatibility with the licensing of typical open source applications implies the need to avoid encumbrances, including even the requirement to obtain a license for implementation, deployment, or use (even if the license does not require the payment of a fee).
o 与典型开源应用程序许可的兼容性意味着需要避免产权负担，甚至包括获得实施、部署或使用许可的要求（即使许可不需要支付费用）。
Therefore, a codec that can be widely implemented and easily distributed among application developers, service operators, and end users is preferred. Many existing codecs that might fulfill some or most of the technical attributes listed above are encumbered in various ways. For example, patent holders might require that those wishing to implement the codec in software, deploy the codec in a service, or distribute the codec in software or hardware need to request a license, enter into a business agreement, pay licensing fees or royalties, or adhere to other special conditions or restrictions. Because such encumbrances have made it difficult to widely implement and easily distribute high-quality codecs across the entire Internet community, the working group prefers unencumbered technologies in a way that is consistent with BCP 78 [IPR] and BCP 79 [TRUST]. In particular, the working group shall heed the preference stated in BCP 79: "In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing." Although this preference cannot guarantee that the working group will produce an unencumbered codec, the working group shall follow and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the
因此，可以广泛实现且易于在应用程序开发人员、服务运营商和最终用户之间分发的编解码器是首选。许多可能满足上述部分或大部分技术属性的现有编解码器以各种方式受到阻碍。例如，专利持有人可能要求那些希望在软件中实现编解码器、在服务中部署编解码器或在软件或硬件中分发编解码器的人需要申请许可证、签订业务协议、支付许可费或版税，或遵守其他特殊条件或限制。由于这些障碍使得难以在整个互联网社区广泛实施和轻松分发高质量编解码器，工作组倾向于采用符合BCP 78[IPR]和BCP 79[TRUST]的无障碍技术。特别是，工作组应注意BCP 79中所述的优先权：“一般而言，IETF工作组更喜欢没有已知知识产权权利主张的技术，或者，对于对其提出权利主张的技术，提供免版税许可。”尽管此优先权不能保证工作组将生产无阻碍的编解码器，工作组应遵循并遵守BCP 79的精神。工作组不能明确排除采用担保技术的可能性；但是,
working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to redistribute and use.
工作组将努力避免需要版税的产权负担技术或其他妨碍此类技术易于重新分配和使用的产权负担。
When considering license terms for technologies with IPR claims against them, some members of the working group have expressed their preference for license terms that:
在考虑针对其提出知识产权索赔的技术的许可条款时，工作组的一些成员表示他们倾向于采用以下许可条款：
o are available to all, worldwide, whether or not they are working group participants
o 可供全世界所有人使用，无论他们是否是工作组参与者
o extend to all essential claims owned or controlled by the licensor
o 扩展至许可方拥有或控制的所有基本索赔
o do not require payment of royalties, fees, or other consideration
o 不要求支付版税、费用或其他对价
o do not require licensees to adhere to restrictions on usage (though, licenses that apply only to implementation of the standard are acceptable)
o 不要求被许可方遵守使用限制（不过，仅适用于标准实施的许可证是可以接受的）
o do not otherwise impede the ability of the codec to be implemented in open-source software projects
o 不要以其他方式妨碍编解码器在开源软件项目中实现的能力
The following guidelines will help to maximize the odds that the codec will be unencumbered:
以下指导原则将有助于最大限度地提高编解码器不受阻碍的可能性：
1. In accordance with BCP 79 [IPR], contributed codecs should preferably use technologies with no known IPR claims or technologies with an offer of royalty-free licensing.
1. 根据BCP 79[IPR]，贡献的编解码器最好使用没有已知IPR声明的技术或提供免版税许可的技术。
2. As described in BCP 79, the working group should use technologies that are perceived by the participants to be safer with regard to IPR issues.
2. 如BCP 79所述，工作组应使用参与者认为在知识产权问题上更安全的技术。
3. Contributors must disclose IPR as specified in BCP 79.
3. 投稿人必须按照BCP 79的规定披露知识产权。
4. In cases where no royalty-free license can be obtained regarding a patent, BCP 79 suggests that the working group consider alternative algorithms or methods, even if they result in lower quality, higher complexity, or otherwise less desirable characteristics.
4. 在没有获得专利权的许可证的情况下，BCP 79建议工作组考虑替代的算法或方法，即使它们导致更低的质量、更高的复杂性或其他不太理想的特性。
5. In accordance with BCP 78 [TRUST], the source code for the reference implementation must be made available under a BSD-style license (or whatever license is defined as acceptable by the IETF Trust when the Internet-Draft defining the reference implementation is published).
5. 根据BCP 78[TRUST]，参考实施的源代码必须在BSD风格的许可证下可用（或在发布定义参考实施的互联网草案时，IETF信任证定义为可接受的任何许可证）。
Many IPR licenses specify that a license is granted only for technologies that are adopted by the IETF as a standard. While reasonable, this has the unintended side effect of discouraging implementation prior to RFC status. Real-world implementation is beneficial for evaluation of the codec. As such, entities making IPR license statements are encouraged to use wording that permits early implementation and deployment.
许多知识产权许可证规定，仅对IETF作为标准采用的技术授予许可证。虽然这是合理的，但它会产生意想不到的副作用，即在RFC状态之前阻止实施。真实世界的实现有利于对编解码器进行评估。因此，鼓励做出知识产权许可声明的实体使用允许早期实施和部署的措辞。
IETF participants should be aware that, given the way patents work in most countries, the resulting codec can never be guaranteed to be free of patent claims because some patents may not be known to the contributors, some patent applications may not be disclosed at the time the codec is developed, and only courts of law can determine the validity and breadth of patent claims. However, these observations are no different within the Internet Standards Process than they are for standardization of codecs within other Standards Development Organizations (SDOs) (or development of codecs outside the context of any SDO); furthermore, they are no different for codecs than for other technologies worked on within the IETF. In all these cases, the best approach is to minimize the risk of unknowingly incurring encumbrance on existing patents. Despite these precautions, participants need to understand that, practically speaking, it is nearly impossible to _guarantee_ that implementers will not incur encumbrance on existing patents.
IETF参与者应意识到，鉴于大多数国家的专利工作方式，所产生的编解码器永远不能保证没有专利要求，因为有些专利可能不为贡献者所知，有些专利申请可能在编解码器开发时未披露，只有法院才能确定专利权要求的有效性和广度。然而，这些观察结果在互联网标准过程中与在其他标准开发组织（SDO）内的编解码器标准化（或在任何SDO的上下文之外的编解码器开发）没有什么不同；此外，编解码器与IETF中的其他技术没有什么不同。在所有这些情况下，最好的办法是尽量减少在不知情的情况下对现有专利产生产权负担的风险。尽管采取了这些预防措施，但参与者需要了解，实际上，几乎不可能保证实施者不会对现有专利造成负担。
It is understood that other SDOs are also involved in the codec development and standardization, including but not necessarily limited to:
据了解，其他SDO也参与编解码器开发和标准化，包括但不限于：
o The Telecommunication Standardization Sector (ITU-T) of the International Telecommunication Union (ITU), in particular Study Group 16
o 国际电信联盟（ITU）的电信标准化部门（ITU-T），特别是第16研究组
o The Moving Picture Experts Group (MPEG) of the International Organization for Standardization and International Electrotechnical Commission (ISO/IEC)
o 国际标准化组织和国际电工委员会（ISO/IEC）的运动图像专家组（MPEG）
o The European Telecommunications Standards Institute (ETSI)
o 欧洲电信标准协会（ETSI）
o The 3rd Generation Partnership Project (3GPP)
o 第三代合作伙伴计划（3GPP）
o The 3rd Generation Partnership Project 2 (3GPP2)
o 第三代合作伙伴项目2（3GPP2）
It is important to ensure that such work does not constitute uncoordinated protocol development of the kind described in [UNCOORD] in the following principle:
重要的是确保此类工作不构成[UNCORD]中所述的不协调协议开发，原则如下：
[T]he IAB considers it an essential principle of the protocol development process that only one SDO maintains design authority for a given protocol, with that SDO having ultimate authority over the allocation of protocol parameter code-points and over defining the intended semantics, interpretation, and actions associated with those code-points.
[T] IAB认为，协议开发过程的一个基本原则是，只有一个SDO维护给定协议的设计权限，SDO对协议参数代码点的分配和与这些代码点相关的预期语义、解释和操作具有最终权限。
The work envisioned by this guidelines document is not uncoordinated in the sense described in the foregoing quote, since the intention of this process is that two possible outcomes might occur:
本指南文件设想的工作在上述引文中所述的意义上并非不协调，因为该过程的目的是可能出现两种可能的结果：
1. The IETF adopts an existing audio codec and specifies that it is the "anointed" IETF Internet codec. In such a case, codec ownership lies entirely with the SDO that produced the codec, and not with the IETF.
1. IETF采用现有的音频编解码器，并指定其为“受膏”IETF互联网编解码器。在这种情况下，编解码器的所有权完全属于产生编解码器的SDO，而不是IETF。
2. The IETF produces a new codec. Even if this codec uses concepts, algorithms, or even source code from a codec produced by another SDO, the IETF codec is a specification unto itself and under complete control of the IETF. Any changes or enhancements made by the original SDO to the codecs whose components the IETF used are not applicable to the IETF codec. Such changes would be incorporated as a consequence of a revision or extension of the IETF RFC. In no case should the new codec reuse a name or code point from another SDO.
2. IETF产生了一种新的编解码器。即使该编解码器使用另一SDO产生的编解码器的概念、算法，甚至源代码，IETF编解码器本身也是一种规范，完全受IETF控制。原始SDO对编解码器所做的任何更改或增强，其IETF使用的组件不适用于IETF编解码器。此类变更将作为IETF RFC修订或扩展的结果纳入。在任何情况下，新编解码器都不应重用来自另一个SDO的名称或代码点。
Although there is already sufficient codec expertise available among IETF participants to complete the envisioned work, additional contributions are welcome within the framework of the Internet Standards Process in the following ways:
尽管IETF参与者中已经有足够的编解码器专业知识来完成设想的工作，但欢迎在互联网标准过程框架内通过以下方式做出更多贡献：
o Individuals who are technical contributors to codec work within other SDOs can participate directly in codec work within the IETF.
o 作为其他SDO内编解码器工作的技术贡献者的个人可以直接参与IETF内的编解码器工作。
o Other SDOs can contribute their expertise (e.g., codec characterization and evaluation techniques) and thus facilitate the testing of a codec produced by the IETF.
o 其他SDO可以贡献他们的专业知识（例如，编解码器表征和评估技术），从而促进IETF产生的编解码器的测试。
o Any SDO can provide input to IETF work through liaison statements.
o 任何SDO都可以通过联络声明为IETF工作提供输入。
However, it is important to note that final responsibility for the development process and the resulting codec will remain with the IETF as governed by BCP 9 [PROCESS].
然而，需要注意的是，开发过程和最终编解码器的最终责任将由IETF承担，由BCP 9[过程]管理。
Finally, there is precedent for the contribution of codecs developed elsewhere to the ITU-T (e.g., Adaptive Multi-Rate Wideband (AMR-WB) was standardized originally within 3GPP). This is a model to explore as the IETF coordinates further with the ITU-T in accordance with the collaboration guidelines defined in [COLLAB].
最后，其他地方开发的编解码器对ITU-T的贡献有先例（例如，自适应多速率宽带（AMR-WB）最初是在3GPP中标准化的）。随着IETF根据[COLLAB]中定义的协作指南与ITU-T进一步协调，这是一个需要探索的模型。
The procedural guidelines for codec development do not have security considerations. However, the resulting codec needs to take appropriate security considerations into account, as outlined in [SECGUIDE] and in the security considerations of [CODEC-REQ]. More specifically, the resulting codec must avoid being subject to denial of service [DOS] and buffer overflows, and should take into consideration the impact of variable bitrate (VBR) [SRTP-VBR].
编解码器开发的程序指南没有安全考虑。但是，生成的编解码器需要考虑适当的安全考虑因素，如[SECGUIDE]和[codec-REQ]的安全考虑因素中所述。更具体地说，生成的编解码器必须避免受到拒绝服务[DOS]和缓冲区溢出的影响，并应考虑可变比特率（VBR）[SRTP-VBR]的影响。
We would like to thank all the other people who contributed directly or indirectly to this document, including Jason Fischl, Gregory Maxwell, Alan Duric, Jonathan Christensen, Julian Spittka, Michael Knappe, Timothy B. Terriberry, Christian Hoene, Stephan Wenger, and Henry Sinnreich. We would also like to thank Cullen Jennings and Gregory Lebovitz for their advice. Special thanks to Peter Saint-Andre, who originally co-authored this document.
我们要感谢所有直接或间接为本文件做出贡献的其他人，包括杰森·菲舍尔、格雷戈里·麦克斯韦、艾伦·杜里奇、乔纳森·克里斯滕森、朱利安·斯皮特卡、迈克尔·纳普、蒂莫西·B·特里贝里、克里斯蒂安·霍恩、斯蒂芬·温格和亨利·辛里奇。我们还要感谢Cullen Jennings和Gregory Lebovitz的建议。特别感谢彼得·圣安德烈，他最初是本文件的合著者。
[IPR] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[IPR]Bradner，S.，“IETF技术中的知识产权”，BCP 79，RFC 3979，2005年3月。
[PROCESS] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[过程]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[TRUST] Bradner, S. and J. Contreras, "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, November 2008.
[信托]Bradner，S.和J.Contreras，“向IETF信托提供的权利出资人”，BCP 78，RFC 5378，2008年11月。
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[BASE64]Josefsson，S.，“Base16、Base32和BASE64数据编码”，RFC4648，2006年10月。
[CODEC-REQ] Valin, J. and K. Vos, "Requirements for an Internet Audio Codec", RFC 6366, August 2011.
[CODEC-REQ]Valin，J.和K.Vos，“互联网音频编解码器的要求”，RFC 6366，2011年8月。
[COLLAB] Fishman, G. and S. Bradner, "Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines", RFC 3356, August 2002.
[合作]Fishman，G.和S.Bradner，“互联网工程任务组和国际电信联盟-电信标准化部门合作指南”，RFC 3356，2002年8月。
[DOS] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[DOS]Handley，M.，Rescorla，E.，和IAB，“互联网拒绝服务注意事项”，RFC 4732，2006年12月。
[ITU-R-BS.1387-1] "Method for objective measurements of perceived audio quality", ITU-R Recommendation BS.1387-1, November 2001.
[ITU-R-BS.1387-1]“感知音频质量的客观测量方法”，ITU-R建议BS.1387-1，2001年11月。
[ITU-R-BS.1534] "Method for the subjective assessment of intermediate quality levels of coding systems", ITU-R Recommendation BS.1534, January 2003.
[ITU-R-BS.1534]“编码系统中间质量水平的主观评估方法”，ITU-R建议BS.1534，2003年1月。
[ITU-T-P.862] "Perceptual evaluation of speech quality (PESQ): An objective method for end-to-end speech quality assessment of narrow-band telephone networks and speech codecs", ITU-T Recommendation P.862, October 2007.
[ITU-T-P.862]“语音质量感知评估（PESQ）：窄带电话网络和语音编解码器端到端语音质量评估的客观方法”，ITU-T建议P.862，2007年10月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RTP]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[SECGUIDE] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[SECGUIDE]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[SRTP-VBR] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2012.
[SRTP-VBR]Perkins，C.和JM。Valin，“带安全RTP的可变比特率音频使用指南”，RFC 6562，2012年3月。
[UNCOORD] Bryant, S., Morrow, M., and IAB, "Uncoordinated Protocol Development Considered Harmful", RFC 5704, November 2009.
[Uncord]Bryant，S.，Morrow，M.，和IAB，“不协调的方案制定被认为是有害的”，RFC 57042009年11月。
Authors' Addresses
作者地址
Jean-Marc Valin Mozilla 650 Castro Street Mountain View, CA 94041 USA
Jean-Marc Valin Mozilla美国加利福尼亚州卡斯特罗街山景650号，邮编94041
EMail: jmvalin@jmvalin.ca
EMail: jmvalin@jmvalin.ca
Slava Borilin SPIRIT DSP
斯拉瓦鲍里林烈酒
EMail: borilin@spiritdsp.com
EMail: borilin@spiritdsp.com
Koen Vos
科恩沃斯
EMail: koen.vos@skype.net
EMail: koen.vos@skype.net
Christopher Montgomery Xiph.Org Foundation
Christopher Montgomery Xiph基金会基金会
EMail: xiphmont@xiph.org
EMail: xiphmont@xiph.org
Raymond (Juin-Hwey) Chen Broadcom Corporation
雷蒙德（Juin Hwey）陈博通公司
EMail: rchen@broadcom.com
EMail: rchen@broadcom.com