Internet Engineering Task Force (IETF) S. Proust, Ed.
Request for Comments: 7875 Orange
Category: Informational May 2016
ISSN: 2070-1721
Internet Engineering Task Force (IETF) S. Proust, Ed.
Request for Comments: 7875 Orange
Category: Informational May 2016
ISSN: 2070-1721
Additional WebRTC Audio Codecs for Interoperability
用于互操作性的附加WebRTC音频编解码器
Abstract
摘要
To ensure a baseline of interoperability between WebRTC endpoints, a minimum set of required codecs is specified. However, to maximize the possibility of establishing the session without the need for audio transcoding, it is also recommended to include in the offer other suitable audio codecs that are available to the browser.
为了确保WebRTC端点之间的互操作性基线，指定了所需的最小编解码器集。然而，为了最大限度地提高在不需要音频转码的情况下建立会话的可能性，还建议在产品中包括可供浏览器使用的其他合适的音频编解码器。
This document provides some guidelines on the suitable codecs to be considered for WebRTC endpoints to address the use cases most relevant to interoperability.
本文档提供了一些关于WebRTC端点要考虑的合适编解码器的指南，以解决与互操作性最相关的用例。
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 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）的产品。互联网工程指导小组（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/rfc7875.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7875.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 3
3. Rationale for Additional WebRTC Codecs . . . . . . . . . . . 4
4. Additional Suitable Codecs for WebRTC . . . . . . . . . . . . 5
4.1. AMR-WB . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. AMR-WB General Description . . . . . . . . . . . . . 5
4.1.2. WebRTC-Relevant Use Case for AMR-WB . . . . . . . . . 5
4.1.3. Guidelines for AMR-WB Usage and Implementation with
WebRTC . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. AMR . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. AMR General Description . . . . . . . . . . . . . . . 6
4.2.2. WebRTC-Relevant Use Case for AMR . . . . . . . . . . 7
4.2.3. Guidelines for AMR Usage and Implementation with
WebRTC . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.1. G.722 General Description . . . . . . . . . . . . . . 7
4.3.2. WebRTC-Relevant Use Case for G.722 . . . . . . . . . 8
4.3.3. Guidelines for G.722 Usage and Implementation with
WebRTC . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 3
3. Rationale for Additional WebRTC Codecs . . . . . . . . . . . 4
4. Additional Suitable Codecs for WebRTC . . . . . . . . . . . . 5
4.1. AMR-WB . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. AMR-WB General Description . . . . . . . . . . . . . 5
4.1.2. WebRTC-Relevant Use Case for AMR-WB . . . . . . . . . 5
4.1.3. Guidelines for AMR-WB Usage and Implementation with
WebRTC . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. AMR . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. AMR General Description . . . . . . . . . . . . . . . 6
4.2.2. WebRTC-Relevant Use Case for AMR . . . . . . . . . . 7
4.2.3. Guidelines for AMR Usage and Implementation with
WebRTC . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. G.722 . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.1. G.722 General Description . . . . . . . . . . . . . . 7
4.3.2. WebRTC-Relevant Use Case for G.722 . . . . . . . . . 8
4.3.3. Guidelines for G.722 Usage and Implementation with
WebRTC . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
As indicated in [OVERVIEW], it has been anticipated that WebRTC will not remain an isolated island and that some WebRTC endpoints will need to communicate with devices used in other existing networks with the help of a gateway. Therefore, in order to maximize the possibility of establishing the session without the need for audio transcoding, it is recommended in [RFC7874] to include in the offer other suitable audio codecs beyond those that are mandatory to implement. This document provides some guidelines on the suitable codecs to be considered for WebRTC endpoints to address the use cases most relevant to interoperability.
如[概述]中所述，预计WebRTC将不再是一个孤岛，一些WebRTC端点将需要借助网关与其他现有网络中使用的设备进行通信。因此，为了最大限度地提高在不需要音频转码的情况下建立会话的可能性，[RFC7874]中建议在报价中包括其他合适的音频编解码器，而不是强制实施的音频编解码器。本文档提供了一些关于WebRTC端点要考虑的合适编解码器的指南，以解决与互操作性最相关的用例。
The codecs considered in this document are recommended to be supported and included in the offer, only for WebRTC endpoints for which interoperability with other non-WebRTC endpoints and non-WebRTC-based services is relevant as described in Sections 4.1.2, 4.2.2, and 4.3.2. Other use cases may justify offering other additional codecs to avoid transcoding.
建议支持本文档中考虑的编解码器并将其包含在报价中，仅适用于与其他非WebRTC端点和基于非WebRTC的服务的互操作性相关的WebRTC端点，如第4.1.2、4.2.2和4.3.2节所述。其他用例可能需要提供其他额外的编解码器以避免转码。
o Legacy networks: In this document, legacy networks encompass the conversational networks that are already deployed like the PSTN, the PLMN, the IP/IMS networks offering VoIP services, including 3GPP "4G" Evolved Packet System [TS23.002] supporting voice over LTE (VoLTE) radio access [IR.92].
o 传统网络：在本文件中，传统网络包括已经部署的对话网络，如PSTN、PLMN、提供VoIP服务的IP/IMS网络，包括支持LTE（VoLTE）无线接入的3GPP“4G”演进分组系统[TS23.002]。
o WebRTC endpoint: A WebRTC endpoint can be a WebRTC browser or a WebRTC non-browser (also called "WebRTC device" or "WebRTC native application") as defined in [OVERVIEW].
o WebRTC端点：WebRTC端点可以是[OVERVIEW]中定义的WebRTC浏览器或WebRTC非浏览器（也称为“WebRTC设备”或“WebRTC本机应用程序”）。
o AMR: Adaptive Multi-Rate
o 自适应多速率
o AMR-WB: Adaptive Multi-Rate Wideband
o AMR-WB：自适应多速率宽带
o CAT-iq: Cordless Advanced Technology - internet and quality
o CAT iq：无线先进技术-互联网和质量
o DECT: Digital Enhanced Cordless Telecommunications
o 数字增强无绳通信
o IMS: IP Multimedia Subsystems
o IP多媒体子系统
o LTE: Long Term Evolution (3GPP "4G" wireless data transmission standard)
o LTE：长期演进（3GPP“4G”无线数据传输标准）
o MOS: Mean Opinion Score, defined in ITU-T Recommendation P.800 [P.800]
o MOS：ITU-T建议P.800[P.800]中定义的平均意见分数
o PSTN: Public Switched Telephone Network
o 公共交换电话网
o PLMN: Public Land Mobile Network
o 公共陆地移动网络
o VoLTE: Voice over LTE
o VoLTE:LTE语音
The mandatory implementation of Opus [RFC6716] in WebRTC endpoints can guarantee codec interoperability (without transcoding) at state-of-the-art voice quality (better than narrow-band "PSTN" quality) between WebRTC endpoints. The WebRTC technology is also expected to be used to communicate with other types of endpoints using other technologies. It can be used for instance as an access technology to VoLTE services (Voice over LTE as specified in [IR.92]) or to interoperate with fixed or mobile Circuit-Switched or VoIP services like mobile Circuit-Switched voice over 3GPP 2G/3G mobile networks [TS23.002] or DECT-based VoIP telephony [EN300175-1]. Consequently, a significant number of calls are likely to occur between terminals supporting WebRTC endpoints and other terminals like mobile handsets, fixed VoIP terminals, and DECT terminals that do not support WebRTC endpoints nor implement Opus. As a consequence, these calls are likely to be either of low narrow-band PSTN quality using G.711 [G.711] at both ends or affected by transcoding operations. The drawback of such transcoding operations are listed below:
在WebRTC端点中强制实施Opus[RFC6716]可以保证WebRTC端点之间以最先进的语音质量（优于窄带“PSTN”质量）实现编解码器互操作性（无需转码）。预计WebRTC技术还将用于使用其他技术与其他类型的端点进行通信。例如，它可以用作VoLTE服务（如[IR.92]中规定的LTE语音）的接入技术，或与固定或移动电路交换或VoIP服务交互操作，如通过3GPP 2G/3G移动网络的移动电路交换语音[TS23.002]或基于DECT的VoIP电话[EN300175-1]。因此，支持WebRTC端点的终端和其他终端（如手机、固定VoIP终端和不支持WebRTC端点也不实现OPU的DECT终端）之间可能会发生大量呼叫。因此，这些呼叫可能是在两端使用G.711[G.711]的低窄带PSTN质量呼叫，或者受到转码操作的影响。这种转码操作的缺点如下所示：
o Degraded user experience with respect to voice quality: voice quality is significantly degraded by transcoding. For instance, the degradation is around 0.2 to 0.3 MOS for most of the transcoding use cases with AMR-WB codec (Section 4.1) at 12.65 kbit/s and in the same range for other wideband transcoding cases. It should be stressed that if G.711 is used as a fallback codec for interoperation, wideband voice quality will be lost. Such bandwidth reduction effect down to narrow band clearly degrades the user-perceived quality of service leading to shorter and less frequent calls. Such a switch to G.711 is a choice for customers. If transcoding is performed between Opus and any other wideband codec, wideband communication could be maintained but with degraded quality (MOSs of transcoding between AMR-WB at 12.65 kbit/s and Opus at 16 kbit/s in both directions are significantly lower than those of AMR-WB at 12.65 kbit/s or Opus at 16 kbit/s). Furthermore, in degraded conditions, the addition of defects, like (a) audio artifacts due to packet losses and (b) audio effects due to the cascading of different packet loss recovery algorithms, may result in a quality below the acceptable limit for the customers.
o 语音质量方面的用户体验降低：转码会显著降低语音质量。例如，对于大多数采用AMR-WB编解码器（第4.1节）的转码用例，性能下降约为0.2到0.3个MOS，速度为12.65 kbit/s，对于其他宽带转码用例，性能下降范围相同。应该强调的是，如果G.711用作互操作的后备编解码器，宽带语音质量将丢失。这种带宽缩减效应会导致窄带明显降低用户感知的服务质量，从而缩短通话时间，减少通话频率。这样切换到G.711是客户的选择。如果在OPU和任何其他宽带编解码器之间执行转码，则可以保持宽带通信，但质量会降低（AMR-WB在12.65 kbit/s和OPU在两个方向上以16 kbit/s转码的MOSs明显低于AMR-WB在12.65 kbit/s或OPU在16 kbit/s的MOSs）。此外，在降级条件下，添加缺陷，例如（a）由于分组丢失而产生的音频伪影和（b）由于不同分组丢失恢复算法的级联而产生的音频效果，可能导致质量低于客户可接受的限制。
o Degraded user experience with respect to conversational interactivity: the degradation of conversational interactivity is due to the increase of end-to-end latency for both directions that is introduced by the transcoding operations. Transcoding requires full de-packetization for decoding of the media stream (including mechanisms of de-jitter buffering and packet loss recovery) then re-encoding, re-packetization, and resending. The delays produced by all these operations are additive and may increase the end-to-end delay up to 1 second, much beyond the acceptable limit.
o 会话交互性方面的用户体验降低：会话交互性的降低是由于转码操作引入的两个方向的端到端延迟增加所致。转码需要对媒体流进行完全去分组解码（包括去抖动缓冲和数据包丢失恢复机制），然后重新编码、重新分组和重新发送。所有这些操作产生的延迟都是相加的，可能会将端到端延迟增加到1秒，远远超出可接受的限制。
o Additional cost in networks: transcoding places important additional cost on network gateways mainly related to codec implementation, codecs licenses, deployment, testing and validation cost. It must be noted that transcoding of wideband to wideband would require more CPU processing and be more costly than transcoding between narrowband codecs.
o 网络中的额外成本：转码给网络网关带来了重要的额外成本，主要与编解码器实现、编解码器许可证、部署、测试和验证成本有关。必须注意，宽带到宽带的转码将需要更多的CPU处理，并且比窄带编解码器之间的转码成本更高。
The following are considered relevant codecs with respect to the general purpose described in Section 3. This list reflects the current status of foreseen use cases for WebRTC. It is not limitative; it is open to inclusion of other codecs for which relevant use cases can be identified. It's recommended to include codecs (in addition to Opus and G.711) according to the foreseen interoperability cases to be addressed.
以下被视为与第3节中所述的一般用途相关的编解码器。此列表反映了WebRTC可预见用例的当前状态。它不是限制性的；它可以包含其他可以识别相关用例的编解码器。根据预期的互操作性情况，建议包括编解码器（除了Opus和G.711）。
The Adaptive Multi-Rate WideBand (AMR-WB) is a 3GPP-defined speech codec that is mandatory to implement in any 3GPP terminal that supports wideband speech communication. It is being used in circuit-switched mobile telephony services and new multimedia telephony services over IP/IMS. It is specially used for voice over LTE as specified by GSMA in [IR.92]. More detailed information on AMR-WB can be found in [IR.36]. References for AMR-WB-related specifications including the detailed codec description and source code are in [TS26.171], [TS26.173], [TS26.190], and [TS26.204].
自适应多速率宽带（AMR-WB）是3GPP定义的语音编解码器，必须在支持宽带语音通信的任何3GPP终端中实现。它正用于电路交换移动电话服务和IP/IMS上的新多媒体电话服务。它专门用于GSMA在[IR.92]中规定的LTE语音。有关AMR-WB的更多详细信息，请参见[IR.36]。[TS26.171]、[TS26.173]、[TS26.190]和[TS26.204]中提供了AMR WB相关规范的参考资料，包括详细的编解码器描述和源代码。
The market of personal voice communication is driven by mobile terminals. AMR-WB is now very widely implemented in devices and networks offering "HD voice", where "HD" stands for "High Definition". Consequently, a high number of calls are likely to occur between WebRTC endpoints and mobile 3GPP terminals offering
个人语音通信市场由移动终端驱动。AMR-WB现在广泛应用于提供“高清语音”的设备和网络中，“高清”代表“高清”。因此，WebRTC端点和移动3GPP终端之间可能发生大量呼叫
AMR-WB. Thus, the use of AMR-WB by WebRTC endpoints would allow transcoding-free interoperation with all mobile 3GPP wideband terminals. Besides, WebRTC endpoints running on mobile terminals (smartphones) may reuse the AMR-WB codec already implemented on those devices.
AMR-WB。因此，WebRTC端点使用AMR-WB将允许与所有移动3GPP宽带终端进行无代码转换的互操作。此外，在移动终端（智能手机）上运行的WebRTC端点可以重用已经在这些设备上实现的AMR-WB编解码器。
The payload format to be used for AMR-WB is described in [RFC4867] with a bandwidth-efficient format and one speech frame encapsulated in each RTP packet. Further guidelines for implementing and using AMR-WB and ensuring interoperability with 3GPP mobile services can be found in [TS26.114]. In order to ensure interoperability with 4G/ VoLTE as specified by GSMA, the more specific IMS profile for voice derived from [TS26.114] should be considered in [IR.92]. In order to maximize the possibility of successful call establishment for WebRTC endpoints offering AMR-WB, it is important that the WebRTC endpoints:
[RFC4867]中描述了用于AMR-WB的有效载荷格式，该格式采用带宽效率高的格式，每个RTP数据包中封装一个语音帧。有关实施和使用AMR-WB以及确保与3GPP移动服务互操作性的更多指南，请参见[TS26.114]。为了确保GSMA规定的与4G/VoLTE的互操作性，[IR.92]中应考虑从[TS26.114]派生的语音的更具体的IMS配置文件。为了最大限度地提高提供AMR-WB的WebRTC端点成功建立呼叫的可能性，WebRTC端点必须：
o Offer AMR in addition to AMR-WB, with AMR-WB listed first (AMR-WB being a wideband codec) as the preferred payload type with respect to other narrow-band codecs (AMR, G.711, etc.) and with a bandwidth-efficient payload format preferred.
o 除了AMR-WB之外，还提供AMR，AMR-WB列在第一位（AMR-WB是一种宽带编解码器），作为相对于其他窄带编解码器（AMR、G.711等）的首选有效负载类型，并且首选带宽高效的有效负载格式。
o Be capable of operating AMR-WB with any subset of the nine codec modes and source-controlled rate operation.
o 能够使用九种编解码器模式的任何子集操作AMR-WB和源代码控制速率操作。
o Offer at least one AMR-WB configuration with parameter settings as defined in Table 6.1 of [TS26.114]. In order to maximize interoperability and quality, this offer does not restrict the codec modes offered. Restrictions on the use of codec modes may be included in the answer.
o 至少提供一个AMR-WB配置，参数设置如[TS26.114]表6.1所述。为了最大限度地提高互操作性和质量，此服务不限制提供的编解码器模式。答案中可能包括对使用编解码器模式的限制。
Adaptive Multi-Rate (AMR) is a 3GPP-defined speech codec that is mandatory to implement in any 3GPP terminal that supports voice communication. This includes both mobile phone calls using GSM and 3G cellular systems as well as multimedia telephony services over IP/ IMS and 4G/VoLTE, such as the GSMA voice IMS profile for VoLTE in [IR.92]. References for AMR-related specifications including detailed codec description and source code are [TS26.071], [TS26.073], [TS26.090], and [TS26.104].
自适应多速率（AMR）是3GPP定义的语音编解码器，必须在任何支持语音通信的3GPP终端中实现。这包括使用GSM和3G蜂窝系统的移动电话呼叫以及通过IP/IMS和4G/VoLTE的多媒体电话服务，如VoLTE in的GSMA语音IMS配置文件[IR.92]。AMR相关规范（包括详细的编解码器说明和源代码）的参考文献有[TS26.071]、[TS26.073]、[TS26.090]和[TS26.104]。
A user of a WebRTC endpoint on a device integrating an AMR module wants to communicate with another user that can only be reached on a mobile device that only supports AMR. Although more and more terminal devices are now "HD voice" and support AMR-WB; there are still a high number of legacy terminals supporting only AMR (terminals with no wideband / HD voice capabilities) that are still in use. The use of AMR by WebRTC endpoints would consequently allow transcoding free interoperation with all mobile 3GPP terminals. Besides, WebRTC endpoints running on mobile terminals (smartphones) may reuse the AMR codec already implemented on these devices.
集成AMR模块的设备上WebRTC端点的用户希望与仅支持AMR的移动设备上的其他用户通信。虽然现在越来越多的终端设备是“高清语音”并支持AMR-WB；仍有大量仅支持AMR（没有宽带/HD语音功能的终端）的传统终端仍在使用中。因此，WebRTC端点使用AMR将允许与所有移动3GPP终端进行无代码转换的互操作。此外，在移动终端（智能手机）上运行的WebRTC端点可以重用已经在这些设备上实现的AMR编解码器。
The payload format to be used for AMR is described in [RFC4867] with bandwidth efficient format and one speech frame encapsulated in each RTP packet. Further guidelines for implementing and using AMR with purpose to ensure interoperability with 3GPP mobile services can be found in [TS26.114]. In order to ensure interoperability with 4G/ VoLTE as specified by GSMA, the more specific IMS profile for voice derived from [TS26.114] should be considered in [IR.92]. In order to maximize the possibility of successful call establishment for WebRTC endpoints offering AMR, it is important that the WebRTC endpoints:
[RFC4867]中描述了用于AMR的有效载荷格式，该格式具有带宽效率，每个RTP数据包中封装一个语音帧。有关实施和使用AMR以确保与3GPP移动服务互操作性的更多指南，请参见[TS26.114]。为了确保GSMA规定的与4G/VoLTE的互操作性，[IR.92]中应考虑从[TS26.114]派生的语音的更具体的IMS配置文件。为了最大限度地提高提供AMR的WebRTC端点成功建立呼叫的可能性，WebRTC端点必须：
o Be capable of operating AMR with any subset of the eight codec modes and source-controlled rate operation.
o 能够使用八种编解码器模式和源代码控制速率操作的任何子集操作AMR。
o Offer at least one configuration with parameter settings as defined in Tables 6.1 and 6.2 of [TS26.114]. In order to maximize the interoperability and quality, this offer shall not restrict AMR codec modes offered. Restrictions on the use of codec modes may be included in the answer.
o 至少提供一种配置，其参数设置如[TS26.114]表6.1和6.2所述。为了最大限度地提高互操作性和质量，本报价不应限制提供的AMR编解码器模式。答案中可能包括对使用编解码器模式的限制。
G.722 [G.722] is an ITU-T-defined wideband speech codec. G.722 was approved by the ITU-T in 1988. It is a royalty-free codec that is common in a wide range of terminals and endpoints supporting wideband speech and requiring low complexity. The complexity of G.722 is estimated to 10 MIPS [EN300175-8], which is 2.5 to 3 times lower than AMR-WB. In particular, G.722 has been chosen by ETSI DECT as the mandatory wideband codec for New Generation DECT in order to greatly increase the voice quality by extending the bandwidth from narrow band to wideband. G.722 is the wideband codec required for terminals that are certified as CAT-iq DECT, and version 2.0 of the CAT-iq
G.722[G.722]是ITU-T定义的宽带语音编解码器。G.722于1988年由ITU-T批准。它是一种免版税的编解码器，在支持宽带语音和要求低复杂度的各种终端和端点中很常见。G.722的复杂度估计为10 MIPS[EN300175-8]，比AMR-WB低2.5到3倍。特别是，ETSI DECT选择G.722作为新一代DECT的强制性宽带编解码器，以便通过将带宽从窄带扩展到宽带来大幅提高语音质量。G.722是认证为CAT iq DECT和CAT iq版本2.0的终端所需的宽带编解码器
specifications have been approved by GSMA as the minimum requirements for the "HD voice" logo usage on "fixed" devices, i.e., broadband connections using the G.722 codec.
GSMA已批准将规范作为“固定”设备（即使用G.722编解码器的宽带连接）上使用“高清语音”徽标的最低要求。
G.722 is the wideband codec required for DECT CAT-iq terminals. DECT cordless phones are still widely used to offer short-range wireless connection to PSTN or VoIP services. G.722 has also been specified by ETSI in [TS181005] as the mandatory wideband codec for IMS multimedia telephony communication service and supplementary services using fixed broadband access. The support of G.722 would consequently allow transcoding-free IP interoperation between WebRTC endpoints and fixed VoIP terminals including DECT CAT-iq terminals supporting G.722. Besides, WebRTC endpoints running on fixed terminals that implement G.722 may reuse the G.722 codec already implemented on these devices.
G.722是DECT CAT iq终端所需的宽带编解码器。DECT无绳电话仍然广泛用于提供PSTN或VoIP服务的短程无线连接。ETSI在[TS181005]中将G.722指定为IMS多媒体电话通信服务和使用固定宽带接入的补充服务的强制性宽带编解码器。因此，G.722的支持将允许WebRTC端点和固定VoIP终端（包括支持G.722的DECT CAT iq终端）之间的免费转码IP互操作。此外，在实现G.722的固定终端上运行的WebRTC端点可以重用已经在这些设备上实现的G.722编解码器。
The payload format to be used for G.722 is defined in [RFC3551] with each octet of the stream of octets produced by the codec to be octet-aligned in an RTP packet. The sampling frequency for the G.722 codec is 16 kHz, but the RTP clock rate is set to 8000 Hz in SDP to stay backward compatible with an erroneous definition in the original version of the RTP audio/video profile. Further guidelines for implementing and using G.722 to ensure interoperability with multimedia telephony services over IMS can be found in Section 7 of [TS26.114]. Additional information about the G.722 implementation in DECT can be found in [EN300175-8], and the full codec description and C source code are in [G.722].
用于G.722的有效载荷格式在[RFC3551]中定义，编解码器产生的八位字节流的每个八位字节在RTP数据包中对齐。G.722编解码器的采样频率为16 kHz，但RTP时钟频率在SDP中设置为8000 Hz，以与原始版本的RTP音频/视频配置文件中的错误定义保持向后兼容。有关实施和使用G.722以确保通过IMS与多媒体电话服务互操作性的更多指南，请参见[TS26.114]第7节。有关DECT中G.722实现的更多信息，请参见[EN300175-8]，完整的编解码器描述和C源代码请参见[G.722]。
Relevant security considerations can be found in [RFC7874], "WebRTC Audio Codec and Processing Requirements". Implementers making use of the additional codecs considered in this document are advised to also refer more specifically to the "Security Considerations" sections of [RFC4867] (for AMR and AMR-WB) and [RFC3551] (for the RTP audio/video profile).
相关安全注意事项可在[RFC7874]，“WebRTC音频编解码器和处理要求”中找到。建议使用本文件中考虑的其他编解码器的实施者也更具体地参考[RFC4867]（适用于AMR和AMR-WB）和[RFC3551]（适用于RTP音频/视频配置文件）中的“安全注意事项”部分。
[G.722] ITU-T, "7 kHz audio-coding within 64 kbit/s", ITU-T Recommendation G.722, September 2012, <http://www.itu.int/rec/T-REC-G.722-201209-I/en>.
[G.722]ITU-T，“64 kbit/s内的7 kHz音频编码”，ITU-T建议G.722，2012年9月<http://www.itu.int/rec/T-REC-G.722-201209-I/en>.
[IR.92] GSMA, "IMS Profile for Voice and SMS", IR.92, Version 9.0, April 2015, <http://www.gsma.com/newsroom/all-documents/ ir-92-ims-profile-for-voice-and-sms/>.
[IR.92]GSMA，“语音和短信的IMS配置文件”，IR.92，版本9.0，2015年4月<http://www.gsma.com/newsroom/all-documents/ ir-92-ims-profile-for-voice-and-sms/>。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <http://www.rfc-editor.org/info/rfc3551>.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，DOI 10.17487/RFC3551，2003年7月<http://www.rfc-editor.org/info/rfc3551>.
[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867, April 2007, <http://www.rfc-editor.org/info/rfc4867>.
[RFC4867]Sjoberg，J.，Westerlund，M.，Lakaniemi，A.，和Q.Xie，“自适应多速率（AMR）和自适应多速率宽带（AMR-WB）音频编解码器的RTP有效载荷格式和文件存储格式”，RFC 4867，DOI 10.17487/RFC4867，2007年4月<http://www.rfc-editor.org/info/rfc4867>.
[RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, <http://www.rfc-editor.org/info/rfc7874>.
[RFC7874]Valin，JM。和C.Bran，“WebRTC音频编解码器和处理要求”，RFC 7874，DOI 10.17487/RFC7874，2016年5月<http://www.rfc-editor.org/info/rfc7874>.
[TS26.071] 3GPP, "Mandatory Speech Codec speech processing functions; AMR Speech CODEC; General description", 3GPP TS 26.171 v13.0.0, December 2015, <http://www.3gpp.org/DynaReport/26071.htm>.
[TS26.071]3GPP，“强制性语音编解码器语音处理功能；AMR语音编解码器；一般说明”，3GPP TS 26.171 v13.0.012015年12月<http://www.3gpp.org/DynaReport/26071.htm>.
[TS26.073] 3GPP, "ANSI C code for the Adaptive Multi Rate (AMR) speech codec", 3GPP TS 26.073 v13.0.0, December 2015, <http://www.3gpp.org/DynaReport/26073.htm>.
[TS26.073]3GPP，“用于自适应多速率（AMR）语音编解码器的ANSI C代码”，3GPP TS 26.073 v13.0.012015年12月<http://www.3gpp.org/DynaReport/26073.htm>.
[TS26.090] 3GPP, "Mandatory Speech Codec speech processing functions; Adaptive Multi-Rate (AMR) speech codec; Transcoding functions.", 3GPP TS 26.090 v13.0.0, December 2015, <http://www.3gpp.org/DynaReport/26090.htm>.
[TS26.090]3GPP，“强制性语音编解码器语音处理功能；自适应多速率（AMR）语音编解码器；转码功能”，3GPP TS 26.090 v13.0.012015年12月<http://www.3gpp.org/DynaReport/26090.htm>.
[TS26.104] 3GPP, "ANSI C code for the floating-point Adaptive Multi Rate (AMR) speech codec.", 3GPP TS 26.104 v13.0.0, December 2015, <http://www.3gpp.org/DynaReport/26090.htm>.
[TS26.104]3GPP，“浮点自适应多速率（AMR）语音编解码器的ANSI C代码”，3GPP TS 26.104 v13.0.012015年12月<http://www.3gpp.org/DynaReport/26090.htm>.
[TS26.114] 3GPP, "IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction", 3GPP TS 26.114 v13.3.0, March 2016, <http://www.3gpp.org/DynaReport/26114.htm>.
[TS26.114]3GPP，“IP多媒体子系统（IMS）；多媒体电话；媒体处理和交互”，3GPP TS 26.114 v13.3.012016年3月<http://www.3gpp.org/DynaReport/26114.htm>.
[TS26.171] 3GPP, "Speech codec speech processing functions; Adaptive Multi-Rate - Wideband (AMR-WB) speech codec; General description.", 3GPP TS 26.171 v13.0.0, December 2015, <http://www.3gpp.org/DynaReport/26171.htm>.
[TS26.171]3GPP，“语音编解码器语音处理功能；自适应多速率宽带（AMR-WB）语音编解码器；一般说明”，3GPP TS 26.171 v13.0.012015年12月<http://www.3gpp.org/DynaReport/26171.htm>.
[TS26.173] 3GPP, "ANSI-C code for the Adaptive Multi-Rate - Wideband (AMR-WB) speech codec", 3GPP TS 26.173 v13.1.0, March 2016, <http://www.3gpp.org/DynaReport/26173.htm>.
[TS26.173]3GPP，“用于自适应多速率宽带（AMR-WB）语音编解码器的ANSI-C代码”，3GPP TS 26.173 v13.1.012016年3月<http://www.3gpp.org/DynaReport/26173.htm>.
[TS26.190] 3GPP, "Speech codec speech processing functions; Adaptive Multi-Rate - Wideband (AMR-WB) speech codec; Transcoding functions", 3GPP TS 26.190 v13.0.0, December 2015, <http://www.3gpp.org/DynaReport/26190.htm>.
[TS26.190]3GPP，“语音编解码器语音处理功能；自适应多速率宽带（AMR-WB）语音编解码器；转码功能”，3GPP TS 26.190 v13.0.012015年12月<http://www.3gpp.org/DynaReport/26190.htm>.
[TS26.204] 3GPP, "Speech codec speech processing functions; Adaptive Multi-Rate - Wideband (AMR-WB) speech codec; ANSI-C code.", 3GPP TS 26.204 v13.1.0, March 2016, <http://www.3gpp.org/DynaReport/26204.htm>.
[TS26.204]3GPP，“语音编解码器语音处理功能；自适应多速率宽带（AMR-WB）语音编解码器；ANSI-C代码”，3GPP TS 26.204 v13.1.0，2016年3月<http://www.3gpp.org/DynaReport/26204.htm>.
[EN300175-1] ETSI, "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI); Part 1: Overview", ETSI EN 300 175-1, v2.6.1, 2015, <http://www.etsi.org/deliver/etsi_en/300100_300199/ 30017501/02.06.01_60/en_30017501v020601p.pdf>.
[EN300175-1]ETSI，“数字增强无绳通信（DECT）；公共接口（CI）；第1部分：概述”，ETSI EN 300 175-1，v2.6.112015<http://www.etsi.org/deliver/etsi_en/300100_300199/ 30017501/02.06.01_60/en_30017501v020601p.pdf>。
[EN300175-8] ETSI, "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI); Part 8: Speech and audio coding and transmission.", ETSI EN 300 175-8, v2.6.1, 2015, <http://www.etsi.org/deliver/etsi_en/300100_300199/ 30017508/02.06.01_60/en_30017508v020601p.pdf>.
[EN300175-8]ETSI，“数字增强无绳通信（DECT）；公共接口（CI）；第8部分：语音和音频编码与传输”，ETSI EN 300 175-8，v2.6.112015<http://www.etsi.org/deliver/etsi_en/300100_300199/ 30017508/02.06.01_60/en_30017508v020601p.pdf>。
[G.711] ITU-T, "Pulse code modulation (PCM) of voice frequencies", ITU-T Recommendation G.711, November 1988, <http://www.itu.int/rec/T-REC-G.711-198811-I/en>.
[G.711]ITU-T，“语音频率的脉冲编码调制（PCM）”，ITU-T建议G.711，1988年11月<http://www.itu.int/rec/T-REC-G.711-198811-I/en>.
[IR.36] GSMA, "Adaptive Multirate Wide Band", IR.36, Version 3.0, September 2014, <http://www.gsma.com/newsroom/all-documents/ official-document-ir-36-adaptive-multirate-wide-band>.
[IR.36]GSMA，“自适应多速率宽带”，IR.36，版本3.0，2014年9月<http://www.gsma.com/newsroom/all-documents/ official-document-ir-36-adaptive-multirate-wide-band>。
[OVERVIEW] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", Work in Progress, draft-ietf-rtcweb-overview-15, January 2016.
[概述]Alvestrand，H.，“概述：基于浏览器的应用程序的实时协议”，正在进行的工作，草稿-ietf-rtcweb-OVERVIEW-15，2016年1月。
[P.800] ITU-T, "Methods for subjective determination of transmission quality", ITU-T Recommendation P.800, August 1996, <https://www.itu.int/rec/T-REC-P.800-199608-I/en>.
[P.800]ITU-T，“主观确定传输质量的方法”，ITU-T建议P.800，1996年8月<https://www.itu.int/rec/T-REC-P.800-199608-I/en>.
[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012, <http://www.rfc-editor.org/info/rfc6716>.
[RFC6716]Valin，JM.，Vos，K.，和T.Terriberry，“作品音频编解码器的定义”，RFC 6716，DOI 10.17487/RFC6716，2012年9月<http://www.rfc-editor.org/info/rfc6716>.
[TS181005] ETSI, "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Service and Capability Requirements V3.3.1 (2009-12)", ETSI TS 181005, 2009, <http://www.etsi.org/deliver/etsi_ts/181000_181099/ 181005/03.03.01_60/ts_181005v030301p.pdf>.
[TS181005]ETSI，“用于高级网络的电信和互联网融合服务和协议（TISPAN）；服务和能力要求V3.3.1（2009-12）”，ETSI TS 181005，2009<http://www.etsi.org/deliver/etsi_ts/181000_181099/ 181005/03.03.01_60/ts_181005v030301p.pdf>。
[TS23.002] 3GPP, "Network architecture", 3GPP TS23.002 v13.5.0, March 2016, <http://www.3gpp.org/dynareport/23002.htm>.
[TS23.002]3GPP，“网络架构”，3GPP TS23.002 v13.5.012016年3月<http://www.3gpp.org/dynareport/23002.htm>.
Acknowledgements
致谢
We would like to thank Magnus Westerlund, Barry Dingle, and Sanjay Mishra who carefully reviewed the document and helped to improve it.
我们要感谢Magnus Westerlund、Barry Dingle和Sanjay Mishra仔细审查了该文件并帮助改进了该文件。
Contributors
贡献者
The following individuals contributed significantly to this document:
以下个人对本文件作出了重大贡献：
o Stephane Proust, Orange, stephane.proust@orange.com
o 斯蒂芬·普鲁斯特，橙色，斯蒂芬。proust@orange.com
o Espen Berger, Cisco, espeberg@cisco.com
o 埃斯彭·伯杰，思科，espeberg@cisco.com
o Bernhard Feiten, Deutsche Telekom, Bernhard.Feiten@telekom.de
o 伯恩哈德·费滕，德国电信，伯恩哈德。Feiten@telekom.de
o Bo Burman, Ericsson, bo.burman@ericsson.com
o 博·伯曼，爱立信，博。burman@ericsson.com
o Kalyani Bogineni, Verizon Wireless, Kalyani.Bogineni@VerizonWireless.com
o 卡利亚尼·博吉尼尼，Verizon无线，卡利亚尼。Bogineni@VerizonWireless.com
o Mia Lei, Huawei, lei.miao@huawei.com
o 米娅·雷，华为，雷。miao@huawei.com
o Enrico Marocco, Telecom Italia, enrico.marocco@telecomitalia.it
o Enrico Marocco，意大利电信，Enrico。marocco@telecomitalia.it
though only the editor is listed on the front page.
尽管头版上只列出了编辑。
Author's Address
作者地址
Stephane Proust (editor) Orange 2, avenue Pierre Marzin Lannion 22307 France
斯蒂芬·普鲁斯特（编辑）法国皮埃尔·马津·拉尼翁大街橙色2号，邮编22307
Email: stephane.proust@orange.com
Email: stephane.proust@orange.com