draft-ietf-avtext-mixer-to-client-audio-level-03.txt   draft-ietf-avtext-mixer-to-client-audio-level-04.txt 
Network Working Group E. Ivov, Ed. Network Working Group E. Ivov, Ed.
Internet-Draft Jitsi Internet-Draft Jitsi
Intended status: Standards Track E. Marocco, Ed. Intended status: Standards Track E. Marocco, Ed.
Expires: January 6, 2012 Telecom Italia Expires: February 28, 2012 Telecom Italia
J. Lennox J. Lennox
Vidyo, Inc. Vidyo, Inc.
July 5, 2011 August 27, 2011
A Real-Time Transport Protocol (RTP) Header Extension for Mixer-to- A Real-Time Transport Protocol (RTP) Header Extension for Mixer-to-
Client Audio Level Indication Client Audio Level Indication
draft-ietf-avtext-mixer-to-client-audio-level-03 draft-ietf-avtext-mixer-to-client-audio-level-04
Abstract Abstract
This document describes a mechanism for RTP-level mixers in audio This document describes a mechanism for RTP-level mixers in audio
conferences to deliver information about the audio level of conferences to deliver information about the audio level of
individual participants. Such audio level indicators are transported individual participants. Such audio level indicators are transported
in the same RTP packets as the audio data they pertain to. in the same RTP packets as the audio data they pertain to.
Status of this Memo Status of this Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 6, 2012. This Internet-Draft will expire on February 28, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4
4. Audio Levels . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Audio Levels . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Signaling Information . . . . . . . . . . . . . . . . . . . . 7 5. Signaling Information . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
9. Changes From Earlier Versions . . . . . . . . . . . . . . . . 11 9. Changes From Earlier Versions . . . . . . . . . . . . . . . . 11
9.1. Changes From Draft -02 . . . . . . . . . . . . . . . . . . 11 9.1. Changes From Draft -03 . . . . . . . . . . . . . . . . . . 11
9.2. Changes From Draft -01 . . . . . . . . . . . . . . . . . . 11 9.2. Changes From Draft -02 . . . . . . . . . . . . . . . . . . 11
9.3. Changes From Draft -00 . . . . . . . . . . . . . . . . . . 11 9.3. Changes From Draft -01 . . . . . . . . . . . . . . . . . . 11
9.4. Changes From Draft -00 . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Reference Implementation . . . . . . . . . . . . . . 13 Appendix A. Reference Implementation . . . . . . . . . . . . . . 13
A.1. AudioLevelCalculator.java . . . . . . . . . . . . . . . . 13 A.1. AudioLevelCalculator.java . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The Framework for Conferencing with the Session Initiation Protocol The Framework for Conferencing with the Session Initiation Protocol
skipping to change at page 5, line 4 skipping to change at page 5, line 4
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Protocol Operation 3. Protocol Operation
According to RFC 3550 [RFC3550] a mixer is expected to include in According to RFC 3550 [RFC3550] a mixer is expected to include in
outgoing RTP packets a list of identifiers (CSRC IDs) indicating the outgoing RTP packets a list of identifiers (CSRC IDs) indicating the
sources that contributed to the resulting stream. The presence of sources that contributed to the resulting stream. The presence of
such CSRC IDs allows RTP clients to determine, in a binary way, the such CSRC IDs allows RTP clients to determine, in a binary way, the
active speaker(s) in any given moment. RTCP also provides a basic active speaker(s) in any given moment. RTCP also provides a basic
mechanism to map the CSRC IDs to user identities through the CNAME mechanism to map the CSRC IDs to user identities through the CNAME
field. More advanced mechanisms, may exist depending on the field. More advanced mechanisms can exist depending on the signaling
signaling protocol used to establish and control a conference. In protocol used to establish and control a conference. In the case of
the case of the Session Initiation Protocol [RFC3261] for example, the Session Initiation Protocol [RFC3261] for example, the Event
the Event Package for Conference State [RFC4575] defines a <src-id> Package for Conference State [RFC4575] defines a <src-id> tag which
tag which binds CSRC IDs to media streams and SIP URIs. binds CSRC IDs to media streams and SIP URIs.
This document describes an RTP header extension that allows mixers to This document describes an RTP header extension that allows mixers to
indicate the audio-level of every conference participant (CSRC) in indicate the audio-level of every contributing conference participant
addition to simply indicating their on/off status. This new header (CSRC) in addition to simply indicating their on/off status. This
extension uses "General Mechanism for RTP Header Extensions" new header extension uses "General Mechanism for RTP Header
described in [RFC5285]. Extensions" described in [RFC5285].
Each instance of this header contains a list of one-octet audio Each instance of this header contains a list of one-octet audio
levels expressed in -dBov, with values from 0 to 127 representing 0 levels expressed in -dBov, with values from 0 to 127 representing 0
to -127 dBov(see Figure 2 and Figure 3). Appendix A provides a to -127 dBov(see Figure 2 and Figure 3). Appendix A provides a
reference implementation indicating one way of obtaining such values reference implementation indicating one way of obtaining such values
from raw audio samples. from raw audio samples.
Every audio level value pertains to the CSRC identifier located at Every audio level value pertains to the CSRC identifier located at
the corresponding position in the CSRC list. In other words, the the corresponding position in the CSRC list. In other words, the
first value would indicate the audio level of the conference first value would indicate the audio level of the conference
skipping to change at page 5, line 38 skipping to change at page 5, line 38
packet. packet.
When encoding audio level information, a mixer SHOULD include in a When encoding audio level information, a mixer SHOULD include in a
packet information that corresponds to the audio data being packet information that corresponds to the audio data being
transported in that same packet. It is important that these values transported in that same packet. It is important that these values
follow the actual stream as closely as possible. Therefore a mixer follow the actual stream as closely as possible. Therefore a mixer
SHOULD also calculate the values after the original contributing SHOULD also calculate the values after the original contributing
stream has undergone possible processing such as level normalization, stream has undergone possible processing such as level normalization,
and noise reduction for example. and noise reduction for example.
It may sometimes happen that a conference involves more than a single It can sometimes happen that a conference involves more than a single
mixer. In such cases each of the mixers MAY choose to relay the CSRC mixer. In such cases each of the mixers MAY choose to relay the CSRC
list and audio-level information they receive from peer mixers (as list and audio-level information they receive from peer mixers (as
long as the total CSRC count remains below 16). Given that the long as the total CSRC count remains below 16). Given that the
maximum audio level is not precisely defined by this specification, maximum audio level is not precisely defined by this specification,
it is likely that in such situations average audio levels would be it is likely that in such situations average audio levels would be
perceptibly different for the participants located behind the perceptibly different for the participants located behind the
different mixers. different mixers.
4. Audio Levels 4. Audio Levels
The audio level header extension carries the level of the audio in The audio level header extension carries the level of the audio in
the RTP payload of the packet it is associated with. This the RTP payload of the packet it is associated with. This
information is carried in an RTP header extension element as defined information is carried in an RTP header extension element as defined
by the "General Mechanism for RTP Header Extensions" [RFC5285]. by the "General Mechanism for RTP Header Extensions" [RFC5285].
The payload of the audio level header extension element can be The payload of the audio level header extension element can be
encoded using the one or the two-byte header defined in [RFC5285]. encoded using the one-byte or the two-byte header defined in
Figure 2 and Figure 3 show sample audio level encodings with each of [RFC5285]. Figure 2 and Figure 3 show sample audio level encodings
them. with each of them.
0 1 2 3 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 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=2 |0| level 1 |0| level 2 |0| level 3 | | ID | len=2 |0| level 1 |0| level 2 |0| level 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sample audio level encoding using the one-byte header format Sample audio level encoding using the one-byte header format
Figure 2 Figure 2
0 1 2 3 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 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=3 |0| level 1 |0| level 2 | | ID | len=3 |0| level 1 |0| level 2 |
skipping to change at page 6, line 44 skipping to change at page 6, line 44
In the case of the one-byte header format, the 4-bit len field is the In the case of the one-byte header format, the 4-bit len field is the
number minus one of data bytes (i.e. audio level values) transported number minus one of data bytes (i.e. audio level values) transported
in this header extension element following the one-byte header. in this header extension element following the one-byte header.
Therefore, the value zero in this field indicates that one byte of Therefore, the value zero in this field indicates that one byte of
data follows. In the case of the two-byte header format the 8-bit data follows. In the case of the two-byte header format the 8-bit
len field contains the exact number of audio levels carried in the len field contains the exact number of audio levels carried in the
extension. RFC 3550 [RFC3550] only allows RTP packets to carry a extension. RFC 3550 [RFC3550] only allows RTP packets to carry a
maximum of 15 CSRC IDs. Given that audio levels directly refer to maximum of 15 CSRC IDs. Given that audio levels directly refer to
CSRC IDs, implementations MUST NOT include more than 15 audio level CSRC IDs, implementations MUST NOT include more than 15 audio level
values. The maximum value allowed in the len field is therefore 14 values. The maximum value allowed in the len field is therefore 14
for one-byte header format adn 15 for two-byte header format. for one-byte header format and 15 for two-byte header format.
Audio levels in this document are defined in the same manner as is Audio levels in this document are defined in the same manner as is
audio noise level in the RTP Payload Comfort Noise specification audio noise level in the RTP Payload Comfort Noise specification
[RFC3389]. In the comfort noice specification, the overall magnitude [RFC3389]. In the comfort noise specification, the overall magnitude
of the noise level in comfort noise is encoded into the first byte of of the noise level in comfort noise is encoded into the first byte of
the payload, with spectral information about the noise in subsequent the payload, with spectral information about the noise in subsequent
bytes. This specification's audio level parameter is defined so as bytes. This specification's audio level parameter is defined so as
to be identical to the comfort noise payload's noise-level byte. to be identical to the comfort noise payload's noise-level byte.
The magnitude of the audio level itself is packed into the seven The magnitude of the audio level itself is packed into the seven
least significant bits of the single byte of the header extension, least significant bits of the single byte of the header extension,
shown in Figure 2 and Figure 3. The least significant bit of the shown in Figure 2 and Figure 3. The least significant bit of the
audio level magnitude is packed into 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 unused and always set byte. The most significant bit of the byte is unused and always set
skipping to change at page 8, line 20 skipping to change at page 8, line 20
the media-level section(s) of SDP, i.e., after an "m=" line) or the media-level section(s) of SDP, i.e., after an "m=" line) or
globally if there is more than one stream containing audio level globally if there is more than one stream containing audio level
indicators in a session. indicators in a session.
Presence of the above attribute in the SDP description of a media Presence of the above attribute in the SDP description of a media
stream indicates that RTP packets in that stream, which contain the stream indicates that RTP packets in that stream, which contain the
level extension defined in this document, will be carrying them with level extension defined in this document, will be carrying them with
an ID of 7. an ID of 7.
Conferencing clients that support audio level indicators and have no Conferencing clients that support audio level indicators and have no
mixing capabilities would not be able to content for this audio level mixing capabilities would not be able to provide content for this
extension and would hence have to always include the direction audio level extension and would hence have to always include the
parameter in the "extmap" attribute with a value of "recvonly". direction parameter in the "extmap" attribute with a value of
Conference focus entities with mixing capabilities can omit the "recvonly". Conference focus entities with mixing capabilities can
direction or set it to "sendrecv" in SDP offers. Such entities would omit the direction or set it to "sendrecv" in SDP offers. Such
need to set it to "sendonly" in SDP answers to offers with a entities would need to set it to "sendonly" in SDP answers to offers
"recvonly" parameter and to "sendrecv" when answering other with a "recvonly" parameter and to "sendrecv" when answering other
"sendrecv" offers. "sendrecv" offers.
This specification only defines use of the audio level extensions in This specification only defines use of the audio level extensions in
audio streams. They MUST NOT be advertised with other media types audio streams. They MUST NOT be advertised with other media types
such as video or text for example. such as video or text for example.
The following Figure 4 and Figure 5 show two example offer/answer The following Figure 4 and Figure 5 show two example offer/answer
exchanges between a conferencing client and a focus, and between two exchanges between a conferencing client and a focus, and between two
conference focus entities. conference focus entities.
skipping to change at page 10, line 24 skipping to change at page 10, line 24
conference is confidential. Also, as discussed in conference is confidential. Also, as discussed in
[I-D.perkins-avt-srtp-vbr-audio], an attacker might be able to [I-D.perkins-avt-srtp-vbr-audio], an attacker might be able to
infer information about the conversation, possibly with phoneme- infer information about the conversation, possibly with phoneme-
level resolution. level resolution.
3. Both of the above are concerns that stem from the design of the 3. Both of the above are concerns that stem from the design of the
RTP protocol itself and they would probably also apply when using RTP protocol itself and they would probably also apply when using
CSRC identifiers the way they were specified in RFC 3550 CSRC identifiers the way they were specified in RFC 3550
[RFC3550]. It is therefore important that according to the needs [RFC3550]. It is therefore important that according to the needs
of a particular scenario, implementors and deployers consider use of a particular scenario, implementors and deployers consider use
of header extension encryption of header extension encryption
[I-D.lennox-avtcore-srtp-encrypted-header-ext] or a lower level [I-D.ietf-avtcore-srtp-encrypted-header-ext] or a lower level
security and authentication mechanism. security and authentication mechanism.
7. IANA Considerations 7. IANA Considerations
This document defines a new extension URI that, if approved, would This document defines a new extension URI that, if approved, would
need to be added to the RTP Compact Header Extensions sub-registry of need to be added to the RTP Compact Header Extensions sub-registry of
the Real-Time Transport Protocol (RTP) Parameters registry, according the Real-Time Transport Protocol (RTP) Parameters registry, according
to the following data: to the following data:
Extension URI: urn:ietf:params:rtp-hdrext:csrc-audio-level Extension URI: urn:ietf:params:rtp-hdrext:csrc-audio-level
skipping to change at page 10, line 46 skipping to change at page 10, line 46
Contact: emcho@jitsi.org Contact: emcho@jitsi.org
Reference: RFC XXXX Reference: RFC XXXX
Note to the RFC-Editor: please replace "RFC XXXX" by the number of Note to the RFC-Editor: please replace "RFC XXXX" by the number of
this RFC. this RFC.
8. Acknowledgments 8. Acknowledgments
Lyubomir Marinov contributed level measurement and rendering code. Lyubomir Marinov contributed level measurement and rendering code.
Keith Drage, Roni Even, Ingemar Johansson, Michael Ramalho, Magnus Keith Drage, Roni Even, John Elwell, Kevin P. Fleming, Ingemar
Westerlund and several others provided helpful feedback over the Johansson, Michael Ramalho, Magnus Westerlund and several others
dispatch mailing list. provided helpful feedback over the avt and avtext mailing lists.
Jitsi's participation in this specification is funded by the NLnet Jitsi's participation in this specification is funded by the NLnet
Foundation. Foundation.
9. Changes From Earlier Versions 9. Changes From Earlier Versions
Note to the RFC-Editor: please remove this section prior to Note to the RFC-Editor: please remove this section prior to
publication as an RFC. publication as an RFC.
9.1. Changes From Draft -02 9.1. Changes From Draft -03
o Addressed editorial comments made on the mailing list.
9.2. Changes From Draft -02
o Removed the no-data use case that allowed sending levels in RTP o Removed the no-data use case that allowed sending levels in RTP
packets. Choosing the right RTP payload type for this use case packets. Choosing the right RTP payload type for this use case
would have incurred complexity without bringing any real value. would have incurred complexity without bringing any real value.
o Merged the "Header Format" and the "Audio level encoding" sections o Merged the "Header Format" and the "Audio level encoding" sections
into a single "Audio Levels" section. into a single "Audio Levels" section.
o Changed encoding related text so that it would cover both the one- o Changed encoding related text so that it would cover both the one-
byte and the two-byte header formats. byte and the two-byte header formats.
o Clarified use of root mean square for dBov calculation o Clarified use of root mean square for dBov calculation
o Added a reference to [I-D.perkins-avt-srtp-vbr-audio] to better o Added a reference to [I-D.perkins-avt-srtp-vbr-audio] to better
explain some "Security Considerations" . explain some "Security Considerations" .
o Other minor editorial changes. o Other minor editorial changes.
9.2. Changes From Draft -01 9.3. Changes From Draft -01
o Removed code related the AudioLevelRenderer from "APPENDIX A. o Removed code related the AudioLevelRenderer from "APPENDIX A.
Reference Implementation" as it was considered an implementation Reference Implementation" as it was considered an implementation
matter by the working group. matter by the working group.
o Modified the AudioLevelCalculator in "APPENDIX A. Reference o Modified the AudioLevelCalculator in "APPENDIX A. Reference
Implementation" to take overload as a parameter. Implementation" to take overload as a parameter.
o Clarified non-use of audio levels in video streams o Clarified non-use of audio levels in video streams
o Closed the P.56 open issue. It was agreed on IETF 80 that P.56 is o Closed the P.56 open issue. It was agreed on IETF 80 that P.56 is
mostly about speech levels and the levels transported by the mostly about speech levels and the levels transported by the
extension defined here should also be able to serve as an extension defined here should also be able to serve as an
indication for noise. indication for noise.
o The Open Issues section has been removed as all issues that were o The Open Issues section has been removed as all issues that were
in there are now resolved or clarified. in there are now resolved or clarified.
o Editorial changes for consistency with o Editorial changes for consistency with
[I-D.ietf-avtext-client-to-mixer-audio-level]. [I-D.ietf-avtext-client-to-mixer-audio-level].
9.3. Changes From Draft -00 9.4. Changes From Draft -00
o Added code for sound pressure calculation and measurement in o Added code for sound pressure calculation and measurement in
"APPENDIX A. Reference Implementation". "APPENDIX A. Reference Implementation".
o Changed affiliation for Emil Ivov. o Changed affiliation for Emil Ivov.
o Removed "Appendix: Design choices". o Removed "Appendix: Design choices".
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
skipping to change at page 12, line 18 skipping to change at page 12, line 24
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008. Header Extensions", RFC 5285, July 2008.
10.2. Informative References 10.2. Informative References
[I-D.ietf-avtcore-srtp-encrypted-header-ext]
Lennox, J., "Encryption of Header Extensions in the Secure
Real-Time Transport Protocol (SRTP)",
draft-ietf-avtcore-srtp-encrypted-header-ext-00 (work in
progress), June 2011.
[I-D.ietf-avtext-client-to-mixer-audio-level] [I-D.ietf-avtext-client-to-mixer-audio-level]
Lennox, J., Ivov, E., and E. Marocco, "A Real-Time Lennox, J., Ivov, E., and E. Marocco, "A Real-Time
Transport Protocol (RTP) Header Extension for Client-to- Transport Protocol (RTP) Header Extension for Client-to-
Mixer Audio Level Indication", Mixer Audio Level Indication",
draft-ietf-avtext-client-to-mixer-audio-level-02 (work in draft-ietf-avtext-client-to-mixer-audio-level-03 (work in
progress), June 2011. progress), July 2011.
[I-D.lennox-avtcore-srtp-encrypted-header-ext]
Lennox, J., "Encryption of Header Extensions in the Secure
Real-Time Transport Protocol (SRTP)",
draft-lennox-avtcore-srtp-encrypted-header-ext-00 (work in
progress), March 2011.
[I-D.perkins-avt-srtp-vbr-audio] [I-D.perkins-avt-srtp-vbr-audio]
Perkins, C. and J. Valin, "Guidelines for the use of Perkins, C. and J. Valin, "Guidelines for the use of
Variable Bit Rate Audio with Secure RTP", Variable Bit Rate Audio with Secure RTP",
draft-perkins-avt-srtp-vbr-audio-05 (work in progress), draft-perkins-avt-srtp-vbr-audio-05 (work in progress),
December 2010. December 2010.
[ITU.G.711] [ITU.G.711]
International Telecommunications Union, "Pulse Code International Telecommunications Union, "Pulse Code
Modulation (PCM) of Voice Frequencies", ITU- Modulation (PCM) of Voice Frequencies", ITU-
skipping to change at page 13, line 34 skipping to change at page 13, line 39
the sound pressure level of a signal with specific samples. It can the sound pressure level of a signal with specific samples. It can
be used in mixers to generate values suitable for the level extension be used in mixers to generate values suitable for the level extension
headers. headers.
The implementation is provided in Java but does not rely on any of The implementation is provided in Java but does not rely on any of
the language specific and can be easily ported to another. the language specific and can be easily ported to another.
A.1. AudioLevelCalculator.java A.1. AudioLevelCalculator.java
/** /**
* Calculates the audio level of specific samples of a singal based on * Calculates the audio level of specific samples of a signal based on
* sound pressure level. * sound pressure level.
*/ */
public class AudioLevelCalculator public class AudioLevelCalculator
{ {
/** /**
* Calculates the sound pressure level of a signal with specific * Calculates the sound pressure level of a signal with specific
* <tt>samples</tt>. * <tt>samples</tt>.
* *
* @param samples the samples of the signal to calculate the sound * @param samples the samples of the signal to calculate the sound
skipping to change at page 14, line 13 skipping to change at page 14, line 18
* <tt>int</tt> value, the sample size in bits is determined by the * <tt>int</tt> value, the sample size in bits is determined by the
* caller via <tt>overload</tt>. * caller via <tt>overload</tt>.
* *
* @param offset the offset in <tt>samples</tt> at which the samples * @param offset the offset in <tt>samples</tt> at which the samples
* start * start
* *
* @param length the length of the signal specified in * @param length the length of the signal specified in
* <tt>samples<tt> starting at <tt>offset</tt> * <tt>samples<tt> starting at <tt>offset</tt>
* *
* @param overload the overload (point) of <tt>signal</tt>. * @param overload the overload (point) of <tt>signal</tt>.
* For example, <tt>overload</tt> may be {@link Byte#MAX_VALUE} * For example, <tt>overload</tt> can be {@link Byte#MAX_VALUE}
* for 8-bit signed samples or {@link Short#MAX_VALUE} for * for 8-bit signed samples or {@link Short#MAX_VALUE} for
* 16-bit signed samples. * 16-bit signed samples.
* *
* @return the sound pressure level of the specified signal * @return the sound pressure level of the specified signal
*/ */
public static int calculateSoundPressureLevel( public static int calculateSoundPressureLevel(
int[] samples, int offset, int length, int[] samples, int offset, int length,
int overload) int overload)
{ {
/* /*
 End of changes. 25 change blocks. 
49 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/