doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc6464.txt b/doc/rfc/rfc6464.txt
new file mode 100644
index 0000000..e96fe9c
--- /dev/null
+++ b/doc/rfc/rfc6464.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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
+
+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.
+
+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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lennox, et al.               Standards Track                    [Page 1]
+
+RFC 6464         Client-to-Mixer Audio Level Indication    December 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+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
+
+   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.
+
+   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.
+
+
+
+Lennox, et al.               Standards Track                    [Page 2]
+
+RFC 6464         Client-to-Mixer Audio Level Indication    December 2011
+
+
+   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.
+
+2.  Terminology
+
+   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.
+
+3.  Audio Levels
+
+   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].
+
+   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.
+
+                    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
+
+
+      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
+
+   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.
+
+
+
+
+Lennox, et al.               Standards Track                    [Page 3]
+
+RFC 6464         Client-to-Mixer Audio Level Indication    December 2011
+
+
+   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.
+
+   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].)
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+Lennox, et al.               Standards Track                    [Page 4]
+
+RFC 6464         Client-to-Mixer Audio Level Indication    December 2011
+
+
+   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.
+
+      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.
+
+4.  Signaling (Setup) Information
+
+   The URI for declaring this header extension in an extmap attribute is
+   "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".
+
+   An example attribute line in the Session Description Protocol (SDP)
+   for a conference might hence be:
+
+      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.
+
+   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.
+
+
+
+
+
+
+
+
+Lennox, et al.               Standards Track                    [Page 5]
+
+RFC 6464         Client-to-Mixer Audio Level Indication    December 2011
+
+
+5.  Considerations on Use
+
+   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.
+
+   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).
+
+6.  Security Considerations
+
+   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.)
+
+
+
+
+
+Lennox, et al.               Standards Track                    [Page 6]
+
+RFC 6464         Client-to-Mixer Audio Level Indication    December 2011
+
+
+   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].
+
+7.  IANA Considerations
+
+   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:
+
+      Extension URI: urn:ietf:params:rtp-hdrext:ssrc-audio-level
+      Description:   Audio Level
+      Contact:       jonathan@vidyo.com
+      Reference:     RFC 6464
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [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.
+
+   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
+              Jacobson, "RTP: A Transport Protocol for Real-Time
+              Applications", STD 64, RFC 3550, July 2003.
+
+   [RFC5285]  Singer, D. and H. Desineni, "A General Mechanism for RTP
+              Header Extensions", RFC 5285, July 2008.
+
+
+
+
+
+
+
+
+
+
+Lennox, et al.               Standards Track                    [Page 7]
+
+RFC 6464         Client-to-Mixer Audio Level Indication    December 2011
+
+
+8.2.  Informative References
+
+   [ITU.G711] International Telecommunication Union, "Pulse Code
+              Modulation (PCM) of Voice Frequencies",
+              ITU-T Recommendation G.711, November 1988.
+
+   [RFC3389]  Zopf, R., "Real-time Transport Protocol (RTP) Payload for
+              Comfort Noise (CN)", RFC 3389, September 2002.
+
+   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+              RFC 3711, March 2004.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, December 2005.
+
+   [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.
+
+   [SRTP-ENCR-HDR]
+              Lennox, J., "Encryption of Header Extensions in the Secure
+              Real-Time Transport Protocol (SRTP)", Work in Progress,
+              October 2011.
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lennox, et al.               Standards Track                    [Page 8]
+
+RFC 6464         Client-to-Mixer Audio Level Indication    December 2011
+
+
+Authors' Addresses
+
+   Jonathan Lennox (editor)
+   Vidyo, Inc.
+   433 Hackensack Avenue
+   Seventh Floor
+   Hackensack, NJ  07601
+   US
+
+   EMail: jonathan@vidyo.com
+
+
+   Emil Ivov
+   Jitsi
+   Strasbourg  67000
+   France
+
+   EMail: emcho@jitsi.org
+
+
+   Enrico Marocco
+   Telecom Italia
+   Via G. Reiss Romoli, 274
+   Turin  10148
+   Italy
+
+   EMail: enrico.marocco@telecomitalia.it
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lennox, et al.               Standards Track                    [Page 9]
+