Internet Engineering Task Force (IETF) J. Lennox, Ed.
Request for Comments: 6464 Vidyo
Category: Standards Track E. Ivov
ISSN: 2070-1721 Jitsi
E. Marocco
Telecom Italia
December 2011
Internet Engineering Task Force (IETF) J. Lennox, Ed.
Request for Comments: 6464 Vidyo
Category: Standards Track E. Ivov
ISSN: 2070-1721 Jitsi
E. Marocco
Telecom Italia
December 2011
A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication
用于客户端到混音器音频电平指示的实时传输协议（RTP）报头扩展
Abstract
摘要
This document defines a mechanism by which packets of Real-time Transport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet. In large conferences, this can reduce the load on an audio mixer or other middlebox that wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received.
本文档定义了一种机制，通过该机制，实时传输协议（RTP）音频流的分组可以在RTP报头扩展中指示RTP分组中携带的音频样本的音频级别。在大型会议中，这可以减少音频混音器或其他中间盒上的负载，因为它们只想转发几个最响亮的音频流，而不需要对接收到的每个流进行解码和测量。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc6464.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6464.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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 ....................................................2
2. Terminology .....................................................3
3. Audio Levels ....................................................3
4. Signaling (Setup) Information ...................................5
5. Considerations on Use ...........................................6
6. Security Considerations .........................................6
7. IANA Considerations .............................................7
8. References ......................................................7
8.1. Normative References .......................................7
8.2. Informative References .....................................8
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Audio Levels ....................................................3
4. Signaling (Setup) Information ...................................5
5. Considerations on Use ...........................................6
6. Security Considerations .........................................6
7. IANA Considerations .............................................7
8. References ......................................................7
8.1. Normative References .......................................7
8.2. Informative References .....................................8
In a centralized Real-time Transport Protocol (RTP) [RFC3550] audio conference, an audio mixer or forwarder receives audio streams from many or all of the conference participants. It then selectively forwards some of them to other participants in the conference. In large conferences, it is possible that such a server might be receiving a large number of streams, of which only a few are intended to be forwarded to the other conference participants.
在集中式实时传输协议（RTP）[RFC3550]音频会议中，音频混音器或转发器从许多或所有会议参与者接收音频流。然后，它有选择地将其中一些转发给会议的其他参与者。在大型会议中，这样的服务器可能正在接收大量流，其中只有少数流打算转发给其他会议参与者。
In such a scenario, in order to pick the audio streams to forward, a centralized server needs to decode, measure audio levels, and possibly perform voice activity detection on audio data from a large number of streams. The need for such processing limits the size or number of conferences such a server can support.
在这种情况下，为了拾取要转发的音频流，集中式服务器需要解码、测量音频电平，并可能对来自大量流的音频数据执行语音活动检测。对此类处理的需求限制了此类服务器可以支持的会议的大小或数量。
As an alternative, this document defines an RTP header extension [RFC5285] through which senders of audio packets can indicate the audio level of the packets' payload, reducing the processing load for a server.
作为替代方案，本文档定义了RTP报头扩展[RFC5285]，通过该扩展，音频数据包的发送者可以指示数据包有效负载的音频级别，从而减少服务器的处理负载。
The header extension in this document is different than, but complementary with, the one defined in [RFC6465], which defines a mechanism by which audio mixers can indicate to clients the levels of the contributing sources that made up the mixed audio.
本文档中的标题扩展不同于[RFC6465]中定义的标题扩展，但与[RFC6465]中定义的标题扩展是互补的，后者定义了一种机制，通过该机制，音频混音器可以向客户端指示构成混合音频的贡献源的级别。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的描述进行解释，并指出符合性实施的要求级别。
The audio level header extension carries the level of the audio in the RTP [RFC3550] payload of the packet with which it is associated. This information is carried in an RTP header extension element as defined by "A General Mechanism for RTP Header Extensions" [RFC5285].
音频电平报头扩展携带与其关联的数据包的RTP[RFC3550]有效载荷中的音频电平。该信息在“RTP报头扩展的通用机制”[RFC5285]定义的RTP报头扩展元素中携带。
The payload of the audio level header extension element can be encoded using either the one-byte or two-byte header defined in [RFC5285]. Figures 1 and 2 show sample audio level encodings with each of these header formats.
音频电平报头扩展元素的有效负载可以使用[RFC5285]中定义的单字节或双字节报头进行编码。图1和图2显示了每种头格式的音频级编码示例。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len=0 |V| level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len=0 |V| level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Sample Audio Level Encoding Using the One-Byte Header Format
图1：使用单字节头格式的音频级编码示例
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len=1 |V| level | 0 (pad) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len=1 |V| level | 0 (pad) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Sample Audio Level Encoding Using the Two-Byte Header Format
图2：使用双字节头格式的音频级编码示例
Note that, as indicated in [RFC5285], the length field in the one-byte header format takes the value 0 to indicate that 1 byte follows. In the two-byte header format, on the other hand, the length field takes the value of 1.
请注意，如[RFC5285]所示，单字节头格式的长度字段的值为0，表示后面跟着1个字节。另一方面，在双字节头格式中，长度字段的值为1。
The magnitude of the audio level itself is packed into the seven least significant bits of the single byte of the header extension, shown in Figures 1 and 2. The least significant bit of the audio level magnitude is packed into the least significant bit of the byte. The most significant bit of the byte is used as a separate flag bit "V", defined below.
音频电平本身的大小被压缩到报头扩展单字节的七个最低有效位中，如图1和图2所示。音频电平幅度的最低有效位被压缩到字节的最低有效位。字节的最高有效位用作单独的标志位“V”，定义如下。
The audio level is expressed in -dBov, with values from 0 to 127 representing 0 to -127 dBov. dBov is the level, in decibels, relative to the overload point of the system, i.e., the highest-intensity signal encodable by the payload format. (Note: Representation relative to the overload point of a system is particularly useful for digital implementations, since one does not need to know the relative calibration of the analog circuitry.) For example, in the case of u-law (audio/pcmu) audio [ITU.G711], the 0 dBov reference would be a square wave with values +/- 8031. (This translates to 6.18 dBm0, relative to u-law's dBm0 definition in Table 6 of [ITU.G711].)
音频电平用-dBov表示，0到127之间的值表示0到-127 dBov。dBov是相对于系统过载点的电平（分贝），即有效载荷格式可编码的最高强度信号。（注：相对于系统过载点的表示对于数字实现特别有用，因为人们不需要知道模拟电路的相对校准。）例如，在u律（音频/pcmu）音频[ITU.G711]的情况下，0 dBov参考将是值为+/-8031的方波。（相对于[ITU.G711]表6中u-law的dBm0定义，这转化为6.18 dBm0。）
The audio level for digital silence -- for a muted audio source, for example -- MUST be represented as 127 (-127 dBov), regardless of the dynamic range of the encoded audio format.
无论编码音频格式的动态范围如何，数字静音的音频电平（例如，对于静音音频源）必须表示为127（-127 dBov）。
The audio level header extension only carries the level of the audio in the RTP payload of the packet with which it is associated, with no long-term averaging or smoothing applied. For payload formats that contain extra error-correction bits or loss-concealment information, the level corresponds only to the data that would result from the payload's normal decoding process, not what it would produce under error or packet loss concealment. The level is measured as a root mean square of all the samples in the audio encoded by the packet.
音频电平报头扩展仅携带与其相关联的分组的RTP有效载荷中的音频电平，而不应用长期平均或平滑。对于包含额外纠错位或丢失隐藏信息的有效负载格式，该级别仅对应于有效负载正常解码过程产生的数据，而不是错误或包丢失隐藏下产生的数据。该电平被测量为数据包编码的音频中所有样本的均方根。
To simplify implementation of the encoding procedures described here, Appendix A of [RFC6465] provides a sample Java implementation of an audio level calculator that helps obtain such values from raw linear Pulse Code Modulation (PCM) audio samples.
为了简化此处描述的编码过程的实现，[RFC6465]的附录A提供了音频电平计算器的Java实现示例，该计算器有助于从原始线性脉冲编码调制（PCM）音频样本中获取此类值。
In addition, a flag bit (labeled "V") optionally indicates whether the encoder believes the audio packet contains voice activity. If the V bit is in use, the value 1 indicates that the encoder believes the audio packet contains voice activity, and the value 0 indicates that the encoder believes it does not. (The voice activity detection algorithm is unspecified and left implementation-specific.) If the V bit is not in use, its value is unspecified and MUST be ignored by receivers. The use of the V bit is signaled using the extension attribute "vad", discussed in Section 4.
此外，标志位（标记为“V”）可选地指示编码器是否相信音频分组包含语音活动。如果V位正在使用，值1表示编码器认为音频数据包包含语音活动，值0表示编码器认为不包含语音活动。（语音活动检测算法未指定，且留有具体实现。）如果V位未使用，则其值未指定，且接收器必须忽略。V位的使用通过第4节中讨论的扩展属性“vad”发出信号。
When this header extension is used with RTP data sent using the RTP Payload for Redundant Audio Data [RFC2198], the header's data describes the contents of the primary encoding.
当此报头扩展与使用冗余音频数据的RTP有效载荷[RFC2198]发送的RTP数据一起使用时，报头的数据描述主编码的内容。
Note: This audio level is defined in the same manner as is audio noise level in the RTP Payload Comfort Noise specification [RFC3389]. In [RFC3389], the overall magnitude of the noise level in comfort noise is encoded into the first byte of the payload, with spectral information about the noise in subsequent bytes. This specification's audio level parameter is defined so as to be identical to the comfort noise payload's noise-level byte.
注：该音频电平的定义方式与RTP有效负载舒适性噪声规范[RFC3389]中的音频噪声电平相同。在[RFC3389]中，舒适性噪声中噪声级的总体大小被编码到有效载荷的第一个字节中，关于噪声的频谱信息在随后的字节中。本规范的音频电平参数定义为与舒适性噪声有效负载的噪声电平字节相同。
The URI for declaring this header extension in an extmap attribute is "urn:ietf:params:rtp-hdrext:ssrc-audio-level".
在extmap属性中声明此头扩展的URI是“urn:ietf:params:rtp hdrext:ssrc audio level”。
It has a single extension attribute, named "vad". It takes the form "vad=on" or "vad=off". If the header extension element is signaled with "vad=on", the V bit described in Section 3 is in use, and MUST be set by senders. If the header extension element is signaled with "vad=off", the V bit is not in use, and its value MUST be ignored by receivers. If the vad extension attribute is not specified, the default is "vad=on".
它有一个名为“vad”的扩展属性。其形式为“vad=on”或“vad=off”。如果报头扩展元素发出“vad=on”信号，则第3节中描述的V位正在使用，并且必须由发送方设置。如果报头扩展元素发出“vad=off”信号，则V位不在使用中，接收机必须忽略其值。如果未指定vad扩展属性，则默认值为“vad=on”。
An example attribute line in the Session Description Protocol (SDP) for a conference might hence be:
因此，会议的会话描述协议（SDP）中的一个示例属性行可能是：
a=extmap:6 urn:ietf:params:rtp-hdrext:ssrc-audio-level vad=on
a=extmap:6 urn:ietf:params:rtp-hdrext:ssrc-audio-level vad=on
The vad extension attribute only controls the semantics of this header extension attribute, and does not make any statement about whether the sender is using any other voice activity detection features, such as discontinuous transmission, comfort noise, or silence suppression.
vad扩展属性仅控制此标题扩展属性的语义，不说明发送方是否正在使用任何其他语音活动检测功能，例如不连续传输、舒适噪音或静音抑制。
Using the mechanisms of [RFC5285], an endpoint MAY signal multiple instances of the header extension element, with different values of the vad attribute, so long as these instances use different values for the extension identifier. However, again following the rules of [RFC5285], the semantics chosen for a header extension element (including its vad setting) for a particular extension identifier value MUST NOT be changed within an RTP session.
使用[RFC5285]的机制，端点可以向具有不同vad属性值的标题扩展元素的多个实例发送信号，只要这些实例对扩展标识符使用不同的值。然而，同样遵循[RFC5285]的规则，为特定扩展标识符值的头扩展元素（包括其vad设置）选择的语义不得在RTP会话中更改。
Mixers and forwarders generally ought not base audio forwarding decisions directly on packet-by-packet audio level information, but rather ought to apply some analysis of the audio levels and trends. This general rule applies whether audio levels are provided by endpoints (as defined in this document), or are calculated at a server, as would be done in the absence of this information. This section discusses several issues that mixers and forwarders may wish to take into account. (Note that this section provides design guidance only, and is not normative.)
混音器和转发器通常不应该直接根据逐包音频级别信息做出音频转发决策，而是应该应用音频级别和趋势的一些分析。无论音频级别是由端点（如本文档中所定义）提供的，还是在服务器上计算的（如缺少此信息时所做的），此一般规则都适用。本节讨论了混合器和转发器可能希望考虑的几个问题。（请注意，本节仅提供设计指南，不具有规范性。）
First of all, audio levels generally ought to be measured over longer intervals than that of a single audio packet. In order to avoid false-positives for short bursts of sound (such as a cough or a dropped microphone), it is often useful to require that a participant's audio level be maintained for some period of time before considering it to be "real"; i.e., some type of low-pass filter ought to be applied to the audio levels. Note, though, that such filtering must be balanced with the need to avoid clipping of the beginning of a speaker's speech.
首先，通常应该在比单个音频包更长的时间间隔内测量音频电平。为了避免短时间爆发的声音（如咳嗽或麦克风掉落）出现误报，要求参与者的音频水平在被视为“真实”之前保持一段时间通常是有用的；i、 例如，某些类型的低通滤波器应该应用于音频电平。但请注意，这种过滤必须与避免削波说话人讲话开头的需要相平衡。
Additionally, different participants may have their audio input set differently. It may be useful to apply some sort of automatic gain control to the audio levels. There are a number of possible approaches to achieving this, e.g., by measuring peak audio levels, by average audio levels during speech, or by measuring background audio levels (average audio levels during non-speech).
此外，不同的参与者可能会有不同的音频输入设置。对音频电平应用某种自动增益控制可能是有用的。有许多可能的方法来实现这一点，例如，通过测量峰值音频电平、语音期间的平均音频电平或通过测量背景音频电平（非语音期间的平均音频电平）。
A malicious endpoint could choose to set the values in this header extension falsely, so as to falsely claim that audio or voice is or is not present. It is not clear what could be gained by falsely claiming that audio is not present, but an endpoint falsely claiming that audio is present, or falsely exaggerating its reported levels, could perform a denial-of-service attack on an audio conference, so as to send silence to suppress other conference members' audio, or could dominate a conference by seizing its speaker-selection algorithm. Thus, if a device relies on audio level data from untrusted endpoints, it SHOULD periodically audit the level information transmitted, taking appropriate corrective action against endpoints that appear to be sending incorrect data. (However, as it is valid for an endpoint to choose to measure audio levels prior to encoding, some degree of discrepancy could be present. This would not indicate that an endpoint is malicious.)
恶意端点可能会选择错误地设置此标头扩展中的值，从而错误地声明音频或语音存在或不存在。目前尚不清楚虚假声明音频不存在会带来什么，但虚假声明音频存在或虚假夸大其报告级别的端点可能会对音频会议执行拒绝服务攻击，从而发送静音以抑制其他会议成员的音频，或者可以通过掌握演讲人选择算法来控制会议。因此，如果设备依赖于来自不受信任端点的音频级别数据，则应定期审核传输的级别信息，对似乎发送不正确数据的端点采取适当的纠正措施。（但是，由于端点选择在编码之前测量音频电平是有效的，因此可能存在一定程度的差异。这并不表示端点是恶意的。）
In the Secure Real-time Transport Protocol (SRTP) [RFC3711], RTP header extensions are authenticated but not encrypted. When this header extension is used, audio levels are therefore visible on a packet-by-packet basis to an attacker passively observing the audio stream. As discussed in [SRTP-VBR-AUDIO], such an attacker might be able to infer information about the conversation, possibly with phoneme-level resolution. In scenarios where this is a concern, additional mechanisms MUST be used to protect the confidentiality of the header extension. This mechanism could be header extension encryption [SRTP-ENCR-HDR], or a lower-level security and authentication mechanism such as IPsec [RFC4301].
在安全实时传输协议（SRTP）[RFC3711]中，RTP报头扩展经过身份验证，但未加密。因此，当使用此报头扩展时，被动观察音频流的攻击者可以逐个包看到音频级别。如[SRTP-VBR-AUDIO]中所述，此类攻击者可能通过音素级别的分辨率推断出有关对话的信息。在这种情况下，必须使用其他机制来保护头扩展的机密性。该机制可以是报头扩展加密[SRTP-ENCR-HDR]，也可以是较低级别的安全和身份验证机制，如IPsec[RFC4301]。
This document defines a new extension URI in the RTP Compact Header Extensions subregistry of the Real-Time Transport Protocol (RTP) Parameters registry, according to the following data:
本文档根据以下数据在实时传输协议（RTP）参数注册表的RTP Compact Header Extensions子域中定义了一个新的扩展URI：
Extension URI: urn:ietf:params:rtp-hdrext:ssrc-audio-level
Description: Audio Level
Contact: jonathan@vidyo.com
Reference: RFC 6464
Extension URI: urn:ietf:params:rtp-hdrext:ssrc-audio-level
Description: Audio Level
Contact: jonathan@vidyo.com
Reference: RFC 6464
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[RFC2198]Perkins，C.，Kouvelas，I.，Hodson，O.，Hardman，V.，Handley，M.，Bolot，J.，Vega Garcia，A.，和S.Fosse Parisis，“冗余音频数据的RTP有效载荷”，RFC 21981997年9月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008.
[RFC5285]Singer，D.和H.Desneni，“RTP标头扩展的一般机制”，RFC 5285，2008年7月。
[ITU.G711] International Telecommunication Union, "Pulse Code Modulation (PCM) of Voice Frequencies", ITU-T Recommendation G.711, November 1988.
[ITU.G711]国际电信联盟，“语音频率的脉冲编码调制（PCM）”，ITU-T建议G.711，1988年11月。
[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, September 2002.
[RFC3389]Zopf，R.，“舒适噪声（CN）的实时传输协议（RTP）有效载荷”，RFC 3389，2002年9月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication", RFC 6465, December 2011.
[RFC6465]Ivov，E.，Ed.，Marocco，E.，Ed.，和J.Lennox，“混音器到客户端音频电平指示的实时传输协议（RTP）头扩展”，RFC 6465，2011年12月。
[SRTP-ENCR-HDR] Lennox, J., "Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP)", Work in Progress, October 2011.
[SRTP-ENCR-HDR]Lennox，J.，“安全实时传输协议（SRTP）中报头扩展的加密”，正在进行的工作，2011年10月。
[SRTP-VBR-AUDIO] Perkins, C. and JM. Valin, "Guidelines for the use of Variable Bit Rate Audio with Secure RTP", Work in Progress, July 2011.
[SRTP-VBR-AUDIO]Perkins，C.和JM。Valin，“带安全RTP的可变比特率音频使用指南”，正在进行的工作，2011年7月。
Authors' Addresses
作者地址
Jonathan Lennox (editor) Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 US
Jonathan Lennox（编辑）美国新泽西州哈肯萨克市哈肯萨克大道433号七楼Vidyo，邮编：07601
EMail: jonathan@vidyo.com
EMail: jonathan@vidyo.com
Emil Ivov Jitsi Strasbourg 67000 France
埃米尔·伊沃夫·吉茨·斯特拉斯堡67000法国
EMail: emcho@jitsi.org
EMail: emcho@jitsi.org
Enrico Marocco Telecom Italia Via G. Reiss Romoli, 274 Turin 10148 Italy
Enrico Marocco Telecom Italia Via G.Reiss Romoli，274意大利都灵10148
EMail: enrico.marocco@telecomitalia.it
EMail: enrico.marocco@telecomitalia.it