< draft-ietf-codec-requirements-04.txt   draft-ietf-codec-requirements-05.txt >
codec JM. Valin codec JM. Valin
Internet-Draft Octasic Inc. Internet-Draft Mozilla
Intended status: Informational K. Vos Intended status: Informational K. Vos
Expires: November 20, 2011 Skype Technologies S.A. Expires: January 28, 2012 Skype Technologies S.A.
May 19, 2011 July 27, 2011
Codec Requirements Requirements for an Internet Audio Codec
draft-ietf-codec-requirements-04 draft-ietf-codec-requirements-05
Abstract Abstract
This document provides specific requirements for an Internet audio This document provides specific requirements for an Internet audio
codec. These requirements address quality, sampling rate, bit-rate, codec. These requirements address quality, sampling rate, bit-rate,
and packet loss robustness, as well as other desirable properties. and packet loss robustness, as well as other desirable properties.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 November 20, 2011. This Internet-Draft will expire on January 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 20 skipping to change at page 2, line 20
3.1. Point to point calls . . . . . . . . . . . . . . . . . . . 5 3.1. Point to point calls . . . . . . . . . . . . . . . . . . . 5
3.2. Conferencing . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Conferencing . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Telepresence . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Telepresence . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Teleoperation and Remote Software Services . . . . . . . . 6 3.4. Teleoperation and Remote Software Services . . . . . . . . 6
3.5. In-game voice chat . . . . . . . . . . . . . . . . . . . . 7 3.5. In-game voice chat . . . . . . . . . . . . . . . . . . . . 7
3.6. Live distributed music performances / Internet music 3.6. Live distributed music performances / Internet music
lessons . . . . . . . . . . . . . . . . . . . . . . . . . 7 lessons . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.7. Delay Tolerant Networking or Push-to-Talk Services . . . . 8 3.7. Delay Tolerant Networking or Push-to-Talk Services . . . . 8
3.8. Other applications . . . . . . . . . . . . . . . . . . . . 8 3.8. Other applications . . . . . . . . . . . . . . . . . . . . 8
4. Constraints Imposed by the Internet on the Codec . . . . . . . 9 4. Constraints Imposed by the Internet on the Codec . . . . . . . 9
4.1. Security . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Detailed Basic Requirements . . . . . . . . . . . . . . . . . 11
5. Detailed Basic Requirements . . . . . . . . . . . . . . . . . 12 5.1. Operating space . . . . . . . . . . . . . . . . . . . . . 11
5.1. Operating space . . . . . . . . . . . . . . . . . . . . . 12 5.2. Quality and bit-rate . . . . . . . . . . . . . . . . . . . 11
5.2. Quality and bit-rate . . . . . . . . . . . . . . . . . . . 12 5.3. Packet loss robustness . . . . . . . . . . . . . . . . . . 12
5.3. Packet loss robustness . . . . . . . . . . . . . . . . . . 13 5.4. Computational resources . . . . . . . . . . . . . . . . . 13
5.4. Computational resources . . . . . . . . . . . . . . . . . 14 6. Additional considerations . . . . . . . . . . . . . . . . . . 15
6. Additional considerations . . . . . . . . . . . . . . . . . . 16 6.1. Low-complexity audio mixing . . . . . . . . . . . . . . . 15
6.1. Low-complexity audio mixing . . . . . . . . . . . . . . . 16 6.2. Encoder side potential for improvement . . . . . . . . . . 15
6.2. Encoder side potential for improvement . . . . . . . . . . 16 6.3. Layered bit-stream . . . . . . . . . . . . . . . . . . . . 15
6.3. Layered bit-stream . . . . . . . . . . . . . . . . . . . . 16 6.4. Partial redundancy . . . . . . . . . . . . . . . . . . . . 16
6.4. Partial redundancy . . . . . . . . . . . . . . . . . . . . 17 6.5. Stereo support . . . . . . . . . . . . . . . . . . . . . . 16
6.5. Stereo support . . . . . . . . . . . . . . . . . . . . . . 17 6.6. Bit error robustness . . . . . . . . . . . . . . . . . . . 16
6.6. Bit error robustness . . . . . . . . . . . . . . . . . . . 17 6.7. Time stretching and shortening . . . . . . . . . . . . . . 16
6.7. Time stretching and shortening . . . . . . . . . . . . . . 17 6.8. Input robustness . . . . . . . . . . . . . . . . . . . . . 17
6.8. Input robustness . . . . . . . . . . . . . . . . . . . . . 18 6.9. Support of Audio forensics . . . . . . . . . . . . . . . . 17
6.9. Support of Audio forensics . . . . . . . . . . . . . . . . 18 6.10. Legacy compatibility . . . . . . . . . . . . . . . . . . . 17
6.10. Legacy compatibility . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 10. Informative References . . . . . . . . . . . . . . . . . . . . 21
10. Informative References . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
This document provides requirements for an audio codec designed This document provides requirements for an audio codec designed
specifically for use over the Internet. The requirements attempt to specifically for use over the Internet. The requirements attempt to
address the needs of the most common Internet interactive audio address the needs of the most common Internet interactive audio
transmission applications and to ensure good quality when operating transmission applications and to ensure good quality when operating
in conditions that are typical for the Internet. These requirements in conditions that are typical for the Internet. These requirements
address the quality, sampling rate, delay, bit-rate, and packet loss address the quality, sampling rate, delay, bit-rate, and packet loss
skipping to change at page 5, line 49 skipping to change at page 5, line 49
lower bit-rates. lower bit-rates.
3.2. Conferencing 3.2. Conferencing
Conferencing applications (which support multi-party calls) have Conferencing applications (which support multi-party calls) have
additional requirements on top of the requirements for point-to-point additional requirements on top of the requirements for point-to-point
calls. Conferencing systems often have higher-fidelity audio calls. Conferencing systems often have higher-fidelity audio
equipment and have greater network bandwidth available -- especially equipment and have greater network bandwidth available -- especially
when video transmission is involved. For that reason, support for when video transmission is involved. For that reason, support for
super-wideband audio becomes important, with useful bit-rates in the super-wideband audio becomes important, with useful bit-rates in the
32 - 64 kb/s range. The ability to vary the bit-rate according to 32 - 64 kb/s range. The ability to vary the bit-rate (VBR) according
the "difficulty" of the audio signal (VBR) is a desirable feature for to the "difficulty" of the audio signal is a desirable feature for
the codec. This not only saves bandwidth "on average", but it can the codec. This not only saves bandwidth "on average", but it can
also help conference servers make more efficient use of the available also help conference servers make more efficient use of the available
bandwidth by using more bandwidth for important audio streams and bandwidth by using more bandwidth for important audio streams and
less bandwidth for less important ones (e.g. background noise). less bandwidth for less important ones (e.g. background noise).
Conferencing end-points often operate in hands-free conditions, which Conferencing end-points often operate in hands-free conditions, which
creates acoustic echo problems. For this reason lower delay is creates acoustic echo problems. For this reason lower delay is
important, as it reduces the quality degradation due to any residual important, as it reduces the quality degradation due to any residual
echo after acoustic echo cancellation (AEC). For this reason, the echo after acoustic echo cancellation (AEC). For this reason, the
codec delay must be less than 30 ms for this application. An codec delay must be less than 30 ms for this application. An
skipping to change at page 10, line 34 skipping to change at page 10, line 34
design should take into consideration explicit congestion design should take into consideration explicit congestion
notification (ECN) and may include features that would improve the notification (ECN) and may include features that would improve the
quality of an ECN implementation. quality of an ECN implementation.
The IETF has defined a set of application-layer protocols to be used The IETF has defined a set of application-layer protocols to be used
for transmitting real-time transport of multimedia data, including for transmitting real-time transport of multimedia data, including
voice. It is thus important for the resulting codec to be easy to voice. It is thus important for the resulting codec to be easy to
use with these protocols. For example, it must be possible to create use with these protocols. For example, it must be possible to create
an [RTP] payload format that conforms to BCP 36 [PAYLOADS]. If any an [RTP] payload format that conforms to BCP 36 [PAYLOADS]. If any
codec parameters need to be negotiated between end-points, the codec parameters need to be negotiated between end-points, the
negotiation should be as easy as possible to carry over SIP/SDP or negotiation should be as easy as possible to carry over SIP
alternatively over XMPP/Jingle. [RFC3261]/SDP [RFC4566] or alternatively over XMPP [RFC6120]/Jingle
[XEP-0167].
4.1. Security
Just like for any protocol to be used over the Internet, security is
a very important aspect to consider. This goes beyond the obvious
considerations of preventing buffer overflows and similar attacks
that can lead to denial-of-service or remote code execution. One
very important security aspect is to make sure that the decoders have
a bounded and reasonable worst-case complexity. This prevents an
attacker from causing a DoS by sending packets that are specially
crafted to take a very long (or infinite) time to decode.
A more subtle aspect is the information leak that can occur when the
codec is used over an encrypted channel (e.g. [SRTP]). For example,
it was suggested [wright08] that use of source-controlled VBR may
reveal some information about a conversation through the size of the
compressed packets. For that reason, it should be possible to use
the codec at truely constant bit-rate if needed.
5. Detailed Basic Requirements 5. Detailed Basic Requirements
This section summarizes all the constraints imposed by the target This section summarizes all the constraints imposed by the target
applications and by the Internet into a set of actual requirements applications and by the Internet into a set of actual requirements
for codec development. for codec development.
5.1. Operating space 5.1. Operating space
The operating space for the target applications can be divided in The operating space for the target applications can be divided in
skipping to change at page 12, line 50 skipping to change at page 11, line 50
o (Narrowband and wideband not required) o (Narrowband and wideband not required)
5.2. Quality and bit-rate 5.2. Quality and bit-rate
The quality of a codec is directly linked to the bit-rate, so these The quality of a codec is directly linked to the bit-rate, so these
two must be considered jointly. When comparing the bit-rate of two must be considered jointly. When comparing the bit-rate of
codecs, the overhead of IP/UDP/RTP headers should not be considered, codecs, the overhead of IP/UDP/RTP headers should not be considered,
but any additional bits required in the RTP payload format after the but any additional bits required in the RTP payload format after the
header (e.g. required signalling) should be considered. In terms of header (e.g. required signalling) should be considered. In terms of
quality vs bit-rate, the codec to be developed must be better than quality vs bit-rate, the codec to be developed must be better than
the currently available codecs that satisfy the IPR requirements in the following codecs, that are generally considered as royalty-free:
the guidelines document, which are:
o For narrowband: Speex (NB), and iLBC(*) o For narrowband: Speex (NB) [Speex], and iLBC(*) [RFC3951]
o For wideband: Speex (WB), G.722.1(*) o For wideband: Speex (WB) [Speex], G.722.1(*) [ITU.G722.1]
o For super-wideband/fullband: G.722.1C(*) o For super-wideband/fullband: G.722.1C(*) [ITU.G722.1]
The codecs marked with (*) do not meet all the licensing guidelines, The codecs marked with (*) have additional licensing restrictions,
but the codecs to be developed should still not perform significantly but the codec to be developed should still not perform significantly
worse. In addition to the quality targets listed above, a desirable worse. In addition to the quality targets listed above, a desirable
objective is for the codec quality to be no worse than AMB-NB and objective is for the codec quality to be no worse than AMB-NB and
AMR-WB, for narrowband and wideband, respectively. Quality should be AMR-WB, for narrowband and wideband, respectively. Quality should be
measured for multiple languages, including tonal languages. The case measured for multiple languages, including tonal languages. The case
of multiple simultaneous voices (as sometimes happens in of multiple simultaneous voices (as sometimes happens in
conferencing) should be evaluated as well. conferencing) should be evaluated as well.
The comparison with the above codecs assumes that the codecs being The comparison with the above codecs assumes that the codecs being
compared have similar delay characteristics. The bit-rate required compared have similar delay characteristics. The bit-rate required
for a certain level of quality may be higher than the referenced for a certain level of quality may be higher than the referenced
skipping to change at page 14, line 30 skipping to change at page 13, line 30
a mono signal on one core of a recent x86 CPU (as measured with the a mono signal on one core of a recent x86 CPU (as measured with the
unix "time" utility or equivalent) are as follows: unix "time" utility or equivalent) are as follows:
o Narrowband: 40 MHz (2% of a 2 GHz CPU core) o Narrowband: 40 MHz (2% of a 2 GHz CPU core)
o Wideband: 80 MHz (4% of a 2 GHz CPU core) o Wideband: 80 MHz (4% of a 2 GHz CPU core)
o Superwideband/fullband: 200 MHz (10% of a 2 GHz CPU core) o Superwideband/fullband: 200 MHz (10% of a 2 GHz CPU core)
It is a desirable objective that the MHz values listed above also be It is a desirable objective that the MHz values listed above also be
achievable on fixed-point DSPs that are capable of single-cycle MAC achievable on fixed-point digital signal processors that are capable
operations (16x16 multiplication accumulated into 32 bits). of single-cycle multiply-accumulate operations (16x16 multiplication
accumulated into 32 bits).
For applications that require mixing (e.g. conferencing), it should For applications that require mixing (e.g. conferencing), it should
be possible to estimate the energy and/or the voice activity status be possible to estimate the energy and/or the voice activity status
of the decoded signal with less than 10% of the complexity figures of the decoded signal with less than 10% of the complexity figures
listed above. listed above.
It is the intent to maximize the range of devices on which a codec It is the intent to maximize the range of devices on which a codec
can be implemented. For this reasons, the reference implementation can be implemented. For this reasons, the reference implementation
must not depend on special hardware features or instructions to be must not depend on special hardware features or instructions to be
present in order to meet the complexity requirement. However, it may present in order to meet the complexity requirement. However, it may
be desirable to take advantage of such hardware when available, be desirable to take advantage of such hardware when available,
(e.g., hardware accelerators for operations like FFTs and (e.g., hardware accelerators for operations like fast Fourier
convolutions). A codec should also minimize the use of saturating transforms and convolutions). A codec should also minimize the use
arithmetic so as to be implementable on architectures that do not of saturating arithmetic so as to be implementable on architectures
provide hardware saturation (e.g. ARMv4). that do not provide hardware saturation (e.g. ARMv4).
The combined codec size and data ROM should be small enough not to The combined codec size and data ROM should be small enough not to
cause significant implementation problems on typical embedded cause significant implementation problems on typical embedded
devices. The codec context/state size required should be no more devices. The codec context/state size required should be no more
than 2*R*C bytes in floating-point, where R is the sampling rate and than 2*R*C bytes in floating-point, where R is the sampling rate and
C is the number of channels. For fixed-point, that size should be C is the number of channels. For fixed-point, that size should be
less than R*C. The scratch space required should also be less than less than R*C. The scratch space required should also be less than
2*R*C bytes for floating point or less than R*C bytes for fixed- 2*R*C bytes for floating point or less than R*C bytes for fixed-
point. point.
skipping to change at page 16, line 45 skipping to change at page 15, line 45
6.2. Encoder side potential for improvement 6.2. Encoder side potential for improvement
In many codecs, it is possible to improve the quality by improving In many codecs, it is possible to improve the quality by improving
the encoder without breaking compatibility (i.e. without changing the the encoder without breaking compatibility (i.e. without changing the
decoder). Potential for improvement varies from one codec to decoder). Potential for improvement varies from one codec to
another. It is generally low for PCM or ADPCM codecs and higher for another. It is generally low for PCM or ADPCM codecs and higher for
perceptual transform codecs. All things being equal, being able to perceptual transform codecs. All things being equal, being able to
improve a codec after the bit-stream is a desirable property. improve a codec after the bit-stream is a desirable property.
However, this should not be done at the expense of quality in the However, this should not be done at the expense of quality in the
reference encoder. Other potential improvements include signal- reference encoder. Other potential improvements include signal-
adaptive frame size selection and improved DTX algorithms that take adaptive frame size selection and improved discontinuous transmission
advantage of predicting the decoder sides PLC algorithms. (DTX) algorithms that take advantage of predicting the decoder sides
packet loss concealment (PLC) algorithms.
6.3. Layered bit-stream 6.3. Layered bit-stream
A layered codec makes it possible to transmit only a certain subset A layered codec makes it possible to transmit only a certain subset
of the bits and still obtain a valid bit-stream with a quality that of the bits and still obtain a valid bit-stream with a quality that
is equivalent to the quality that would be obtained from encoding at is equivalent to the quality that would be obtained from encoding at
the corresponding rate. While this is not a necessary feature for the corresponding rate. While this is not a necessary feature for
most applications, it can be desirable for cases where a "mixing most applications, it can be desirable for cases where a "mixing
server" needs to handle a large number of streams with limited server" needs to handle a large number of streams with limited
computational resources. computational resources.
skipping to change at page 19, line 7 skipping to change at page 18, line 7
dropped. For this reason, the encoder must allow DTX to be disabled dropped. For this reason, the encoder must allow DTX to be disabled
when required (e.g. for emergency calls). when required (e.g. for emergency calls).
6.10. Legacy compatibility 6.10. Legacy compatibility
In order to create the best possible codec for the Internet, there is In order to create the best possible codec for the Internet, there is
no requirement for compatibility with legacy Internet codecs. no requirement for compatibility with legacy Internet codecs.
7. Security Considerations 7. Security Considerations
The codec requirements themselves do not have security Although this document itself does not have security considerations,
considerations. However, codec security issues are discussed in this section describes the security requirements for the codec.
Section 4.1.
Just like for any protocol to be used over the Internet, security is
a very important aspect to consider. This goes beyond the obvious
considerations of preventing buffer overflows and similar attacks
that can lead to denial-of-service or remote code execution. One
very important security aspect is to make sure that the decoders have
a bounded and reasonable worst-case complexity. This prevents an
attacker from causing a DoS by sending packets that are specially
crafted to take a very long (or infinite) time to decode.
A more subtle aspect is the information leak that can occur when the
codec is used over an encrypted channel (e.g. [SRTP]). For example,
it was suggested [wright08] [white11] that use of source-controlled
VBR may reveal some information about a conversation through the size
of the compressed packets. For that reason, it should be possible to
use the codec at truely constant bit-rate if needed.
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
9. Acknowledgments 9. Acknowledgments
The original authors of this document are: Jean-Marc Valin, Slava The original authors of this document are: Jean-Marc Valin, Slava
Borilin, Koen Vos, Christopher Montgomery and Raymond (Juin-Hwey) Borilin, Koen Vos, Christopher Montgomery and Raymond (Juin-Hwey)
Chen. We would like to thank all the other people who contributed Chen. We would like to thank all the other people who contributed
directly or indirectly to this document, including Jason Fischl, directly or indirectly to this document, including Jason Fischl,
Gregory Maxwell, Alan Duric, Jonathan Christensen, Julian Spittka, Gregory Maxwell, Alan Duric, Jonathan Christensen, Julian Spittka,
Michael Knappe, Christian Hoene, and Henry Sinnreich. We also like Michael Knappe, Christian Hoene, and Henry Sinnreich. We also like
to thank Cullen Jennings and Gregory Lebovitz for their advice. to thank Cullen Jennings and Gregory Lebovitz for their advice.
10. Informative References 10. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011.
[XEP-0167]
Ludwig, S., Saint-Andre, P., Egan, S., McQueen, R., and D.
Cionoiu, "Jingle RTP Sessions", XSF XEP 0167,
December 2009.
[RFC3951] Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn,
W., and J. Linden, "Internet Low Bit Rate Codec (iLBC)",
RFC 3951, December 2004.
[ITU.G722.1]
International Telecommunications Union, "Low-complexity
coding at 24 and 32 kbit/s for hands-free operation in
systems with low frame loss", ITU-T Recommendation
G.722.1, May 2005.
[Speex] Xiph.Org Foundation, "Speex: http://www.speex.org/", 2003.
[carot09] Carot, A., Werner, C., and T. Fischinger, "Towards a [carot09] Carot, A., Werner, C., and T. Fischinger, "Towards a
Comprehensive Cognitive Analysis of Delay-Influenced Comprehensive Cognitive Analysis of Delay-Influenced
Rhythmical Interaction", 2009. Rhythmical Interaction: http://www.carot.de/icmc2009.pdf",
2009.
[PAYLOADS] [PAYLOADS]
Handley, M. and C. Perkins, "Guidelines for Writers of RTP Handley, M. and C. Perkins, "Guidelines for Writers of RTP
Payload Format Specifications", RFC 2736, BCP 36. Payload Format Specifications", RFC 2736, BCP 36.
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. [RTP] 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", RFC 3550. applications", RFC 3550.
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[wright08] [wright08]
Wright, C., Ballard, L., Coull, S., Monrose, F., and G. Wright, C., Ballard, L., Coull, S., Monrose, F., and G.
Masson, "Spot me if you can: Uncovering spoken phrases in Masson, "Spot me if you can: Uncovering spoken phrases in
encrypted VoIP conversations", 2008. encrypted VoIP conversations:
http://www.cs.jhu.edu/~cwright/oakland08.pdf", 2008.
[white11] White, A., Matthews, A., Snow, K., and F. Monrose,
"Phonotactic Reconstruction of Encrypted VoIP
Conversations: Hookt on fon-iks
http://www.cs.unc.edu/~fabian/papers/foniks-oak11.pdf",
2011.
Authors' Addresses Authors' Addresses
Jean-Marc Valin Jean-Marc Valin
Octasic Inc. Mozilla
4101, Molson Street 650 Castro Street
Montreal, Quebec Mountain View, CA 94041
Canada USA
Email: jean-marc.valin@octasic.com Email: jmvalin@jmvalin.ca
Koen Vos Koen Vos
Skype Technologies S.A. Skype Technologies S.A.
Stadsgarden 6 Stadsgarden 6
Stockholm, 11645 Stockholm, 11645
Sweden Sweden
Email: koen.vos@skype.net Email: koen.vos@skype.net
 End of changes. 21 change blocks. 
74 lines changed or deleted 108 lines changed or added

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