Subject: [codec] Codec guidelines and requirements drafts

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 04 Sep 2009 15:06:46 -0400

Hi,

As a follow-up to the codec BoF in Stockholm, a group of interested IETF 
participants has been working on how to move forward regarding this work at 
the IETF.  As a result, today we have submitted two Internet-Drafts:

(1) http://www.ietf.org/id/draft-valin-codec-guidelines-00.txt
(2) http://www.ietf.org/id/draft-valin-codec-requirements-00.txt

We welcome feedback on these drafts on the [email-masked] list.

Cheers,

	Jean-Marc

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Sep 2009 21:50:02 +0200 (CEST)

Hi,

from my network engineering side these look good apart from the fact that 
they do not mention adaptive jitter buffer for the transport. Is this an 
omission done because these drafts are codec and not transport centric, or 
has this requirement been overlooked?

I firmly belive (as I also stated at the mic at IETF75) that any Internet 
codec+transport needs to gracefully handle initial jitter of 10 ms or less 
with small (perhaps 20-40 ms) jitter buffer during parts of the call, and 
then it needs to adapt to jitter going up to multiple seconds (thus 
inferring multiple second jitter buffer and end-to-end delay), and then 
when conditions on the IP packet layer improve, it needs to gracefully 
adapt back to much smaller jitter buffer again.

This is because on the packet layer we have packet transport networks that 
do re-transmits itself and thus can deliver packets quite late 
(802.11abgn, 2G/3G GSM/UMTS networks, just to name a few), but they still 
get delivered but with huge delay/jitter spikes (can be for prolonged 
periods of time as well).

I believe these conditions should be in the requrements/guidelines since 
Packet Loss Concealment is there? (unless people disagree with my opinion 
that any Internet codec+transport should handle and behave the way I 
described above, of course)

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 04 Sep 2009 16:03:47 -0400

Hi,

Mikael Abrahamsson wrote:
> from my network engineering side these look good apart from the fact 
> that they do not mention adaptive jitter buffer for the transport. Is 
> this an omission done because these drafts are codec and not transport 
> centric, or has this requirement been overlooked?

I agree that adaptive jitter buffering is a very important aspect of a 
complete voice transport system. The only reason that this is not mentioned 
in this particular draft is that we are only addressing codec requirements. 
In general, an adaptive jitter buffer should be able to work for any codec 
(you don't want a separate jitter buffer for each codec). The only part 
that *is* relevant for codec requirements is any aspect that the jitter 
buffer would want from the codec. For example, when a packet is late or 
lost, the jitter needs to conceal the loss and make sure to minimise its 
propagation in time. This is a job for the codec and is part of the 
requirements.

I really do think that there is important work to be done regarding jitter 
buffers and transport, but I think these should be done in a separate place 
(AVT WG?). Of course, the people who are working on that can (and should) 
talk to the codec people and tell them what "services" the codec can 
provide that would improve the overall audio quality. For example, some 
people have suggested that codecs should be able to facilitate time 
stretching/compressing. While this is not something that is currently in 
the requirements, I could very well imaging adding that (once there is 
agreement on the details).

	Jean-Marc

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Sep 2009 22:14:17 +0200 (CEST)

On Fri, 4 Sep 2009, Jean-Marc Valin wrote:

> that would improve the overall audio quality. For example, some people have 
> suggested that codecs should be able to facilitate time 
> stretching/compressing. While this is not something that is currently in the 
> requirements, I could very well imaging adding that (once there is agreement 
> on the details).

That sounds good, I think this is a key requirement. I believe 
stretching/compressing needs to be fairly fast/agressive, to be able to go 
from 1000 to 40 ms jitter buffer in just a few seconds (and as fast as 
needed when increasing it). The spatial compression could perhaps also be 
done via agressive silence suppression (at least for voice communication), 
but this can't be the only mechanism because it won't work if there is 
never silence.

Does anyone more into AVT WG know if there are already IETF 
standards/framework to handle this at the transport layer, or is there a 
lot of development needed there as well?

How do we assure that the end-to-end solution works when all is said and 
done? I'm a bit afraid that unless there is very tight cooperation, the 
end solution won't be as good as it could be if all of this was done in a 
single WG doing all the requirements and making sure that everything works 
together.

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 04 Sep 2009 16:27:37 -0400

Mikael Abrahamsson wrote:
> stretching/compressing needs to be fairly fast/agressive, to be able to 
> go from 1000 to 40 ms jitter buffer in just a few seconds (and as fast 
> as needed when increasing it). 

Again, it would be the jitter buffer's job to decide how aggressive to be. 
The only thing the codec (actually just the decoder) would do at this point 
is "obey" what the jitter buffer tell it to do.

> lot of development needed there as well?

Actually, an even more fundamental question here is "should there be a 
standard for jitter buffers?". My *personal* opinion on this is that we 
probably want to define "best practices" for jitter buffering (possibly 
with reference code), but we do not need an actual standard because at this 
point I do not see any inter-operability issue.

> end solution won't be as good as it could be if all of this was done in 
> a single WG doing all the requirements and making sure that everything 
> works together.

Well, you can cooperate across groups and in fact all IETF groups *have* to 
cooperate with other groups. But at the same time, you need to divide the 
problem otherwise the entire IETF would be a single working group ;-)

Cheers,

	Jean-Marc

---

From: "Slava Borilin" <[email-masked]>
Date: Sat, 5 Sep 2009 00:29:54 +0400

Mikael,

As it has been already discussed on the list, the goal is not to
design/specify "end-to-end" voice system, but only specify what is
MANDATORY for interop (=codec), and leave the upper layers to
proprietary solutions.

Of course, codec should be OPTIMIZED for such proprietary solutions as
much as possible, and that's why we are working on the requirements from
"overall system" perspective, which, however, should not be read that
"codec has to do everything", it should be read as "codec has to be good
for the systems that do the best practice on upper layers".

best regards,
Slava Borilin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mikael Abrahamsson
Sent: Saturday, September 05, 2009 12:14 AM
To: [email-masked]
Subject: Re: [codec] Codec guidelines and requirements drafts

That sounds good, I think this is a key requirement. I believe 
stretching/compressing needs to be fairly fast/agressive, to be able to
go 
from 1000 to 40 ms jitter buffer in just a few seconds (and as fast as 
needed when increasing it). The spatial compression could perhaps also
be 
done via agressive silence suppression (at least for voice
communication), 
but this can't be the only mechanism because it won't work if there is 
never silence.

done? I'm a bit afraid that unless there is very tight cooperation, the 
end solution won't be as good as it could be if all of this was done in
a 
single WG doing all the requirements and making sure that everything
works 
together.

-- 
Mikael Abrahamsson    email: [email-masked]
_______________________________________________
codec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/codec

---

From: Simon Perreault <[email-masked]>
Date: Fri, 4 Sep 2009 16:37:37 -0400

On Friday 04 September 2009 16:03:47 Jean-Marc Valin wrote:
> For example, some
> stretching/compressing.

Does someone have a precise idea of what that means?

Thanks,
Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Fri, 04 Sep 2009 17:11:36 -0400

> Does someone have a precise idea of what that means?

How precise?

Audio data arrives at some apparent rate, which we can measure in samples
per second on the local system sample clock.  If the link latency and
buffering are constant, and the two endpoints' sample clocks tick at the
same rate, then the audio data will arrive at the "right" speed, and can
simply be decoded and thrown into the sound card's output buffer.

If the buffer has to expand or contract over some period of time, or if
one of the endpoints ticks faster than the other, then fewer or more
samples will be received than the sound card requires to be played.  The
codec must provide some mechanism to resolve this discrepancy.  Commonly
suggested mechanisms include resampling (which bends pitch), smart
time-stretching to preserve pitch, and "adjust during silence".

To me, the important question here is: what sort of interface does the
codec need to expose for time dilation? For example, it might be a
function that says "turn the next N coded samples into M decoded samples,
please".

--Ben

---

From: Ron <[email-masked]>
Date: Sat, 5 Sep 2009 08:40:31 +0930

On Fri, Sep 04, 2009 at 04:03:47PM -0400, Jean-Marc Valin wrote:
> For example, some people have suggested that codecs
> should be able to facilitate time stretching/compressing.

This would be a very attractive feature for the decoder to support
directly, as we increasingly move toward transports where it is
impossible or impractical to achieve precise clock synchronisation
between endpoints.

While it's not impossible to do this external to the codec, I'd be
quite surprised if gains could not be made to both computational
complexity and quality if this were to be factored into the decoder
stage and encoded data from the outset.

  Ron

---

From: stephen botzko <[email-masked]>
Date: Fri, 4 Sep 2009 21:33:12 -0400

I agree that there is a need for receivers to resample (or otherwise
drop/add samples) in order to match the encoder's A/D clock rate with the
receiver's D/A clock rate. If normal commercial crystals are used for clock
sources, the A/D and D/A clocks may be mismatched by up to about 10 samples
per second (for 48 khz audio).

I am puzzled as to why you would want to build this resamplng into the codec
however - I see no technical advantage in doing this

The resampling is not related to the decoder operation itself, and needs to
be done no motter what codec is in use..Some form of fixed resampling is
often required anyway, in order to match (for instance) a 32 kHz sample rate
used by a codec to the 48 kHz sample rate used by the sampling hardware.

Stephen Botzko
Polycom

---

From: Steve Underwood <[email-masked]>
Date: Sat, 05 Sep 2009 10:33:41 +0800

Hi Stephen,

The subject was not resampling, but time stretching. A time stretcher 
can become trivial if it is implemented within the codec, and generally 
produces better sounding results.

Steve

On 09/05/2009 09:33 AM, stephen botzko wrote:
> drop/add samples) in order to match the encoder's A/D clock rate with 
> the receiver's D/A clock rate. If normal commercial crystals are used 
> for clock sources, the A/D and D/A clocks may be mismatched by up to 
> about 10 samples per second (for 48 khz audio).
>
> I am puzzled as to why you would want to build this resamplng into the 
> codec however - I see no technical advantage in doing this
>
> The resampling is not related to the decoder operation itself, and 
> needs to be done no motter what codec is in use..Some form of fixed 
> resampling is often required anyway, in order to match (for instance) 
> a 32 kHz sample rate used by a codec to the 48 kHz sample rate used by 
> the sampling hardware.
>
> Stephen Botzko
> Polycom
>
> On Fri, Sep 4, 2009 at 5:11 PM, Benjamin M. Schwartz 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Simon Perreault wrote:

---

From: "Christian Hoene" <[email-masked]>
Date: Sat, 5 Sep 2009 06:24:16 +0200

Hello,

We discussed the need for time stretching already three months ago
http://www.ietf.org/mail-archive/web/codec/current/msg00090.html
May I cite Koen Vos again: " For instance, we've had detailed discussions
about what it takes to make a codec work on the Internet. We seemed to agree
that the codec should support not only packet loss concealment, but also
time compression/stretching to handle network jitter. (Incidentally, such
time modification is not supported by any ITU, 3GPP or ETSI codec, which
complicates their use for Internet applications.)"
http://www.ietf.org/mail-archive/web/codec/current/msg00456.html
I never read anything against this requirement on this list. Thus, it can be
seen as a topic of clear consensus. 

Thus, Jean Marc, I am wondering why the input from this mailing list is
ignored in your IETF requirements document- even if it is supported by one
of your coauthors. 

If the pace of progress on technical issues remains as low as it is, - I bet
- you wouldn't get your codecs standardized in ten years time.

Christian

--------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of Tübingen
Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen.de/

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Steve Underwood
> Sent: Saturday, September 05, 2009 4:34 AM
> To: stephen botzko
> Cc: [email-masked]; [email-masked]

---

From: Alexander Chemeris <[email-masked]>
Date: Sat, 5 Sep 2009 12:21:10 +0400

Hi,

My few notes about the draft. I'll split this into two mails - this one
is about technical considerations:

1) I wonder why support for double- or multi-talk is not mentioned.
It's usually claimed that CELP codecs have hard time encoding conferences,
where there are a lot of double- or multi-talk parts. I believe it should be
stated as MUST or at least SHOULD for conferencing scenario and
included in testing set.

2) I also think we should add an ability to retieve not only signal power,
but a more complex VAD decision from the decoder, even without decoding
a frame. I believe it sohuld be stressed more, that this is a very desired
feature for conferencing and even more for gaming (where you can have
1000s of player and you can't go with decoding every stream). This would
allow codec's use in so called tandem-free bridges, where streamsare not
decoded at all.

3) It is also usually stated that VBR is bad for speech transport over
the Internet, because it leads to higher loss rates then when CBR is used.
So I would make more stress on making CBR works better, then requiring
VBR. (here I refer to source-controlled VBR, which leads to fast bitrate
changes).

-- 
Regards,
Alexander Chemeris.

SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: +1 (617) 273-4000

---

From: Alexander Chemeris <[email-masked]>
Date: Sat, 5 Sep 2009 12:22:16 +0400

Hi,

Here are the second part of my notes on drafts, non-technical part:

1) It should be clearly defined, that codec evaluation MUST be done for
several languages, taking into account diferent types of them - e.g. tonal
languages, caucasian languages, etc. If we aim at creating a world-wide
codec, it should work good for more then English and few european
languages.

2) Section 2, bullet 4: "Once a sufficient number of proposals has been
received...". It should be clearly defined when it this "sufficient" number
is reached. I actually don't like the word "sufficient", because it's not
clean, sufficient for what is meant here.

3) Some time frames must be defined. At least it should be clearly
stated that the effort aims at providing working codec in 1yr, 5yrs,
100yrs, etc. Taking into account the size of the goal, it might take
indefinite time to achieve and should be limited.

4) In Section 3.1:
   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.  This would have to be investigated when
   standardizing a codec.
At least it sohuld be specified how it's planned to be investigated? What
is should be the result of such investigation? Actually I don't see why
it should be done in the scope of this effort.

-- 
Regards,
Alexander Chemeris.

SIPez LLC.

---

From: Alexander Chemeris <[email-masked]>
Date: Sat, 5 Sep 2009 12:44:33 +0400

On Sat, Sep 5, 2009 at 01:11, Benjamin M.
> function that says "turn the next N coded samples into M decoded samples,

I also greatly support inclusion of this feature to "SHOULD" as it is already
done with PLC. This will save a lot of CPU power and considerable increase
voice quality in harsh network conditions.

As it was already said, there are two kinds of time adjustment - "slow" and
"fast". Slow one reflect the need to adjust playback rate to compensate
clock skew between end points. Fast adjustment is usually done when you
need to increase/decrease jitter buffer length to adopt to network conditions.
Slow adjustments may be made with resampling, but this is not suitable for
conferencing and gaming cases, so usually slow adjustments are actually
done as a set of repeating small fast adjustments. So even in case of LAN
you will have to do time adjustments. And it's best made inside of a codec.

re: API
I've put a lot of time thinking about this when implemented sipX media engine,
and I same to conclusion that the best way to express desire of time stretch
is with three values:
1) Signed number of samples you need to add/remove (e.g. +100 - I need to
add 100 samples to the stream to increase JB length; -1200 - I need to remove
1200 samples from the stream to considerably decrease JB length)
2) Some number of enumeration, showing the urgency (e.g. 0 - relax, you can
do this during silent period, 1 - hurry up, stretch actual speech, 2 - urgent!
if you do not stretch, we'll have to drop frames).
3) Next frame, if available. This allows to perform interpolation instead of
extrapolation, improving quality. Though if stretching is done inside the codec,
this probably is not needed.

-- 
Regards,
Alexander Chemeris.

SIPez LLC.

---

From: Jean-Marc Valin <[email-masked]>
Date: Sat, 05 Sep 2009 09:39:23 -0400

> stated as MUST or at least SHOULD for conferencing scenario and

Indeed, this is a very good point that we forgot for the
conferencing-type applications. Will add that.

> allow codec's use in so called tandem-free bridges, where streamsare not

Well, the current text reads like this: "the ability to derive
sufficient parameters, such as loudness and/or spectral envelope, for
estimating voice activity of a compressed frame without fully decoding
that frame". I believe that the spectral envelope contains pretty much
what you need here. Any other info that you think is important?

> VBR. (here I refer to source-controlled VBR, which leads to fast bitrate

Do you have any reference regarding VBR and loss rate? In any case, I
think it's clear that both VBR and CBR have valid use cases.

	Jean-Marc

---

From: Simon Perreault <[email-masked]>
Date: Sat, 5 Sep 2009 10:16:00 -0400

On Saturday 05 September 2009 04:44:33 Alexander Chemeris wrote:
> need to increase/decrease jitter buffer length to adopt to network
> conditions. Slow adjustments may be made with resampling, but this is not
> suitable for conferencing and gaming cases, so usually slow adjustments are
> actually done as a set of repeating small fast adjustments. So even in case
> of LAN you will have to do time adjustments. And it's best made inside of a
> codec.

This last sentence puzzles me. Care to explain it?

Thanks,
Simon

---

From: Jean-Marc Valin <[email-masked]>
Date: Sat, 05 Sep 2009 09:50:13 -0400

> codec, it should work good for more then English and few european

I think this actually belongs to the requirements, but otherwise I
totally agree that this is currently missing.

> clean, sufficient for what is meant here.

Will try and come up with something clearer. In any case, it's not that
much about numbers as it is about having all the "building blocks"
required. Any thoughts?

> indefinite time to achieve and should be limited.

Someone more knowledgeable of the IETF process can correct me if I'm
wrong here, but my understanding is that the time frame belongs to the
charter "milestones" section.

> it should be done in the scope of this effort.

I think this is where cross area review is useful. I assume that in the
worst case, we would end up with using only CBR for SRTP.

Cheers,

	Jean-Marc

---

From: Koen Vos <[email-masked]>
Date: Sat, 05 Sep 2009 15:52:10 -0700

Quoting Jean-Marc Valin:

>> [...]

I'm only aware of the opposite relationship between VBR and packet  
loss: short peaks at higher rate are easily handled by the packet  
buffer in the bottleneck (e.g. DSL modem). Even temporarily exceeding  
the network bandwidth only results in a small amount of jitter.
On the other hand, constantly exceeding the network bandwidth not only  
guarantees packet loss, but also keeps the packet buffer filled up,  
easily adding hundreds of milliseconds of extra delay to the call.

Other arguments against using CBR:
- At a given quality level, VBR results in fewer total bits (~ half)  
being sent over the network over the duration of a call.
- VBR helps on the receiving end to estimate the available network  
bandwidth, so that the codec can adjust to it (using a feedback  
channel).

VBR seems better suited for the Internet than CBR.

best,
koen.

---

From: Koen Vos <[email-masked]>
Date: Sat, 05 Sep 2009 16:19:09 -0700

> worst case, we would end up with using only CBR for SRTP.

There's already a draft suggesting that:
http://www.ietf.org/id/draft-perkins-avt-srtp-vbr-audio-01.txt

The [wright08] reference talks about recognizing whole sentences, from  
a small "dictionary" of 122 sentences, all read in a controlled  
environment, with the same TIMIT database being used for training and  
evaluation.  I'm sure that just the *length* of the sentence reveals  
information about which sentence is being read.  So should we also  
look into hiding the duration of calls?

The [wright08] results do not provide any evidence that "free" speech  
can be recognized by looking at packet sizes.  Speech recognition is  
hard even when the speech signal is available.

koen.

---

From: Jean-Marc Valin <[email-masked]>
Date: Sat, 05 Sep 2009 21:57:58 -0400

Koen Vos a écrit :
> The [wright08] reference talks about recognizing whole sentences, from a
> small "dictionary" of 122 sentences, all read in a controlled
> information about which sentence is being read.  So should we also look
> into hiding the duration of calls?

I think [wright08] is interesting in that it raises awareness about a
*potential* issue with VBR. However, I think its main limitation is that
is that it shows a potential information leak in the *Speex* VBR. At
this point, I'm not sure whether the results would generalise to a codec
other than Speex, which decides on the rate based on very simple
heuristics (very unlike SILK). So while I think we need to be careful,
I'm not yet ready to say that encrypted VBR is evil. OTOH, I think pure
CBR has its advantages as well and see no reason we can't have both.

> hard even when the speech signal is available.

I can confirm this. The Speex VBR leaks in the order of 50 bits/second.
That would make a pretty bad recogniser -- even if the VBR code was
specifically optimised for recognition rate.

Cheers,

	Jean-Marc

---

From: Koen Vos <[email-masked]>
Date: Sun, 06 Sep 2009 16:42:18 -0700

Quoting Jean-Marc Valin:

> OTOH, I think pure CBR has its advantages as well and see no reason  
> we can't have both.

Agree that we can have both. But just out of curiosity, what are  
specific advantages of CBR (besides the irrational fear that VBR would  
enable eavesdropping)?

I think Internet codecs should be optimized for low average bitrate  
more than low peak bitrate, because data channels have become shared.  
Similarly, average complexity is more important than peak complexity,  
because there are fewer hard real-time requirements in the system  
(especially on the encoder side).

best,
koen.

---

From: Jean-Marc Valin <[email-masked]>
Date: Sun, 06 Sep 2009 21:07:13 -0400

Koen Vos a écrit :
> Quoting Jean-Marc Valin:
>> OTOH, I think pure CBR has its advantages as well and see no reason we
>> can't have both.
> 

I wouldn't call the fear of encrypted VBR irrational, even though I
believe it is likely blown out of proportion. Actually, to me the main
leak involved in VBR is letting an eavesdroper know when there is active
speech. This is pretty much the same leak as that caused by a VAD, or
even knowing someone is present from the increased video bandwidth.

In any case, the fact that some people want CBR justifies including it
as a requirement. This is not to say that we shouldn't also have VBR, or
even that it shouldn't be optimised for VBR. If we have a very good VBR
codec, I don't think it would be that hard to do CBR with it (even if it
means doing a bit of padding).

> I think Internet codecs should be optimized for low average bitrate more
> than low peak bitrate, because data channels have become shared.

I agree that for most applications, average bit-rate is probably more
important than peak.

> (especially on the encoder side).

I actually disagree about average complexity. Even though average
complexity matters, peak complexity is what determines whether (e.g.) an
embedded DSP is powerful enough to run the codec in real-time.

Cheers,

	Jean-Marc

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Sun, 06 Sep 2009 21:17:42 -0400

> specific advantages of CBR (besides the irrational fear that VBR would

I can think of many advantages to a codec whose peak bandwidth (in a
window of N milliseconds) can easily be limited.  For example, there are
many places where telephone modems are still the most common form of
internet connection.  A good mono voice codec capped at 32kbps could
easily outperform the underlying telephone system for voice quality, in
addition to providing the connectivity advantages of VoIP.

If you can limit peak bandwidth, then CBR is trivial.

---

From: Koen Vos <[email-masked]>
Date: Sun, 06 Sep 2009 21:26:54 -0700

> embedded DSP is powerful enough to run the codec in real-time.

The hard real-time aspect is part of circuit-switched calls, where  
payloads have to be ready at guaranteed times in order to be sent in  
the allocated circuit-switched time slot. For VoIP applications it's  
ok if a packet is sent a few microseconds, or even milliseconds,  
behind schedule. More importantly, in the vast majority of cases, the  
codec will run on a processor with soft real-time constraints, where  
the processing power is shared with other applications.

Minimizing average complexity:
- Increases battery life on mobile devices
- Enables less powerful devices to run the codec (as long as those  
devices have soft real-time constraints)
- Reduces global energy consumption

For voice communications, the trend is away from fixed allocated  
resources to flexible, shared resources. It's not just about a network  
protocol. My hope is that IETF will be faster to recognize this than  
other SDOs.

koen.

---

From: Koen Vos <[email-masked]>
Date: Sun, 06 Sep 2009 21:48:19 -0700

> even knowing someone is present from the increased video bandwidth.

How would people take advantage of that kind of information? Surely  
the fact there was a call to begin with (and the sending and receiving  
IP addresses) are much more revealing and incriminating? Does SRTP  
provide mechanisms to obfuscate those?

I'll change my mind when there's an application that transcribes  
(encrypted, VBR) Skype calls by sniffing the packets. (Writing such an  
app must be a sure was to get rich and famous.)

> as a requirement.

Some people on this list want steep royalties to be part of the  
codec.. Don't there need to be rational arguments?

The problem is really that eavesdropping (1) was never shown to work  
and (2) has strong arguments against it based on information theory,  
yet is almost impossible to disprove.

FWIW, Skype cares *a lot* about preventing eavesdropping, and will  
continue to use VBR.

koen.

---

From: Jean-Marc Valin <[email-masked]>
Date: Mon, 07 Sep 2009 00:58:10 -0400

Hi,

OK, there's actually a few different issues here. For a decoder, I would
argue that the worst-case complexity is the most important because when
you're waiting for a packet that hasn't arrived yet, you want to wait as
long as possible before choosing to consider it lost. For that, you need
to consider the worst-case complexity of the decoder, otherwise you risk
an audio underrun.

On the encoder side I agree that you can tolerate a bit more "complexity
jitter" and I'm certainly in favour of *also* minimising the average
complexity. But even then, you have to be careful about two things:
1) How bad the worst case is. This has to be bounded. If it takes an
encoder on average 10 ms to encode a 20 ms frame, it's obviously not
acceptable to have the worst-case take 200 ms!
2) How correlated the complexity is to the input signal. If the
complexity looks random, then it may be OK. However, if speech frames
take a lot more CPU than silence/noise frames, your DSP still needs to
be able to encode the speech periods in real-time without lagging.

So I'm not at all against reducing the average complexity of the codec.
I'm just saying that we still have to be very careful about the worst
case complexity. Fortunately, I think most algorithms tend to have a
worst case that isn't too far from the average. And of course, if we can
reduce the average without making the worst case much worse, then we
should definitely do it.

Cheers,

	Jean-Marc

Koen Vos a écrit :
> payloads have to be ready at guaranteed times in order to be sent in the
> allocated circuit-switched time slot. For VoIP applications it's ok if a
> packet is sent a few microseconds, or even milliseconds, behind
> schedule. More importantly, in the vast majority of cases, the codec
> will run on a processor with soft real-time constraints, where the
> processing power is shared with other applications.
>

---

From: Koen Vos <[email-masked]>
Date: Sun, 06 Sep 2009 22:01:30 -0700

> If you can limit peak bandwidth, then CBR is trivial.

I agree.

When a 40 kbps, 20 ms packet is sent over a 32 kbps channel, it will  
take 25 ms to transport that packet. The packet will thus arrive 5 ms  
"late", but won't be lost. And the late arrival may not even be  
noticed because of other jitter from the network.

SILK deals with this by defining a maximum delay that can be built up  
in the network buffer. So if the bitrate is set to 32 kbps, and the  
maximum delay is 10 ms, that means that one packet may be sent at 48  
kbps, or 10 consecutive packets may be sent at 33.6 kbps, but after  
that the bitrate is no longer allowed to exceed 32 kbps.

koen.

---

From: Jean-Marc Valin <[email-masked]>
Date: Mon, 07 Sep 2009 01:10:53 -0400

Koen Vos a écrit :
> How would people take advantage of that kind of information? Surely the
> fact there was a call to begin with (and the sending and receiving IP
> addresses) are much more revealing and incriminating? Does SRTP provide
> mechanisms to obfuscate those?

The only case I can think of is when you have an audio link running all
day long, with most of the time nobody talking. Observing the rate would
tell you when a meeting starts. I don't mean to say that this is really
very bad. I'm just saying it's the only real "threat" I see.

> app must be a sure was to get rich and famous.)

Oh, I totally agree with you on this point. I'm not at all concerned
about ever having a continuous speech recognizer running from VBR packet
sizes -- especially considering that most VBR implementations probably
leak much less information than the Speex one. OTOH, I wouldn't be too
surprised if you could get a yes/no recognizer to work, although I'm not
sure what the use of that would be.

> Some people on this list want steep royalties to be part of the codec..
> Don't there need to be rational arguments?
> 
> The problem is really that eavesdropping (1) was never shown to work and
> (2) has strong arguments against it based on information theory, yet is
> almost impossible to disprove.
> 

You don't need to convince my that VBR is good and useful. I'm just
trying to understand what would be so bad with *also* supporting CBR.

	Jean-Marc

---

From: Ron <[email-masked]>
Date: Mon, 7 Sep 2009 17:31:40 +0930

> very bad. I'm just saying it's the only real "threat" I see.

You can also tell who is talking.  Which combined with other sources
of information leakage may result in some interesting correlations.

If for example you were monitoring a call between me and my stockbroker,
you might make a fairly reasonably guess about whether they were giving
me tips, or I was giving them instructions, based on who was doing most
of the talking.  Combine that with other information a MITM might observe
about my online or other activity, and it may be possible to tip the
balances of probability in the sort of ways that are interesting (in a
probably illegally profitable sort of way) in that domain.
</tinfoil hat>

I'm likewise not utterly paranoid about the conversation itself being
decoded precisely, but information leakage has a way of being useful
when you least want it to.  For the majority of people it may never
be an issue, but if the people who do (have to) care have to use a
different codec, that can be a form of information leakage too...

That may not be a terribly compelling argument, but saying "I can't
really see a way to use this either" doesn't really mean a lot unless
the person saying that is reporting on the consensus of a group of
eminent cryptographers who have made a determined effort to use it :)

Cheers,
Ron

---

From: Alexander Chemeris <[email-masked]>
Date: Mon, 7 Sep 2009 12:09:01 +0400

> This last sentence puzzles me. Care to explain it?

I meant that codec usually have all (or most) of the information,
needed to perform
time stretching - like pitch, envelop, voice activity, etc.

-- 
Regards,
Alexander Chemeris.

SIPez LLC.

---

From: stephen botzko <[email-masked]>
Date: Mon, 7 Sep 2009 07:12:07 -0400

How would people take advantage of that kind of information?

My understanding is that the security concern is that a third party can
determine *when* someone is speaking simply by observing the audio bit
rate.  .

In any event, other VBR codecs (for instance RFC 5404 for G.719) have the
same "vulnerability".  However, that RFC does not mention VBR as a security
issue in the "security considerations" section (or anywhere else), so i
don't think it was a signifiant concern to AVT.

Providing for a CBR mode would allow the codec to pass through some gateways
that require fixed rate transports without transcoding.  For instance,G.719
can be carried on H.320 connections, and passed through SIP/H.320 gateways.
H.320 happens to require fixed rate audio.  In order to allow this scenario
to be supported w/o audio transcoding, RFC 5404 includes signaling to
negotiate CBR.

Of course, any VBR stream can be converted to CBR simply by padding the
bitstream.  So it would be easy to support it if someone needs it. (I am not
proposing that it be added, just observing that it is easy to do).

Regards
Stephen Botzko
Polycom

On Mon, Sep 7, 2009 at 12:48 AM, Koen Vos <[email-masked]> wrote:

> (encrypted, VBR) Skype calls by sniffing the packets. (Writing such an app
> must be a sure was to get rich and famous.)
>
>
> FWIW, Skype cares *a lot* about preventing eavesdropping, and will continue
> to use VBR.
>
> koen.

---

From: "Wyss, Felix" <[email-masked]>
Date: Mon, 7 Sep 2009 14:14:36 -0400

I agree.  Assuming something can't be done because one can't think of a way today is *very* dangerous when it comes to security.  The assumption must be that if information is leaked, there will be ways to exploit it.  There are many cases where the call content is highly structured, such as your example of a call to a stockbroker.  Many other types of service or IVR calls tend to be that way.  If an attacker knows at what point during a call a party likely speaks their credit card or social security number, the potential search space is greatly reduced.   

I thus think it is a MUST requirement that the encoder can be run in a mode where there is no correlation between packet size, packet rate and timing, and the short and long-term audio being encoded.  

--Felix

> Sent: Monday, September 07, 2009 04:02
> To: [email-masked]
> Subject: Re: [codec] Codec guidelines and requirements drafts:
> eavesdropping
> 
> the

---

From: Koen Vos <[email-masked]>
Date: Mon, 07 Sep 2009 18:47:38 -0700

Quoting Ron:

> of the talking.

Why not just look at who initiated the call?

koen.

---

From: Ron <[email-masked]>
Date: Tue, 8 Sep 2009 12:14:55 +0930

> Why not just look at who initiated the call?

Obviously you'd look at that too, but either of us may be returning a
missed call, or initiating the call based on an out of band signal,
or some prearranged schedule.  The originator alone doesn't tell you
which party has important information for the other, but the extra
information you could obtain in this manner from the _content_ of the
call about the direction of information flow might well hint that better.

Anyhow, we shouldn't get bogged down in this, that's a job for crypto
people and I'm sure they could come up with better examples than I
did.  I'm pretty sure they have similar correlation techniques already
deployed.  I don't think anyone disputes there _is_ information leakage
here, so if privacy is a factor in the codec requirements, then there
should be a way to cork that leakage.  We aren't the right people to
be judging its importance.

Whether that is done in the codec itself or in the security wrapper
that transports its packets is an open question to consider.  All I'm
saying is that we shouldn't handwave it away because _we_ have no use
for the information we see being leaked.

Recognising that CBR vs VBR is a tradeoff is good engineering, one may
be better than the other in more of the cases we are considering, but
neither is universally better than the other for all use cases.

 Ron

---

From: Koen Vos <[email-masked]>
Date: Mon, 07 Sep 2009 19:49:08 -0700

Quoting "Wyss, Felix":

> If an attacker knows at what point during a call a party likely  
> speaks their credit card or social security number, the potential  
> search space is greatly reduced.

Compelling example. Recognizing spoken digits from packet sizes would  
be an interesting study.

> I thus think it is a MUST requirement that the encoder can be run in  
> a mode where there is no correlation between packet size, packet  
> rate and timing, and the short and long-term audio being encoded.

Calls of an agreeing nature are on average shorter than calls with  
lots of discussion.  And without trying to be sexist, I have a  
suspicion there is a correlation between call duration and gender.   
Should a signaling stack have a mode without termination?

Anyway, I absolutely agree there is an information leak with VBR. I am  
not aware of any evidence that it is practically exploitable, but  
concede it's dangerous to just rule that out. But I also think the  
"market" for a codec without such a leak is small and unproven. If we  
make a MUST out of every niche market requirement, we will have a hard  
time getting things done. And anyone capable of implementing a  
reasonably secure communications tool will know how to pad a VBR codec.

In this case there's no problem as most proposals so far have a CBR  
mode anyway. I do however object to the basis for the requirement.

koen.

---

From: "Wyss, Felix" <[email-masked]>
Date: Wed, 9 Sep 2009 09:30:15 -0400

> Should a signaling stack have a mode without termination?

This is not relevant to the codec, though.  If the parties see the need to disguise the duration of the interaction, they can keep the streams up longer, for example to some fixed length.

> reasonably secure communications tool will know how to pad a VBR codec.

I believe content privacy is pretty fundamental and not just some "niche market requirement".

Isn't the goal of this Internet audio codec to avoid having proprietary and likely incompatible extensions?  Anything not clearly spelled out in the RFC is basically fair game and good luck getting devices from different vendors to play well together.  In our experience, it's hard enough to get devices that implement what's in the RFCs correctly and anything slightly unusual greatly increases the likelihood of incompatibilities and problems.  For example, I'd be reluctant to use RTP padding here for this very reason and because it's up to the sender and not part of the media type negotiation.

--Felix

---

From: stephen botzko <[email-masked]>
Date: Wed, 9 Sep 2009 10:57:01 -0400

All VBR codecs are potentially vulnerable to traffic analysis.  There is at
least one active draft in AVT on the subject already (
http://www.ietf.org/id/draft-perkins-avt-srtp-vbr-audio-01.txt).

IMHO, the best way to handle this right now is to let the AVT discussions
develop.

It might also be wise to limit the use of VBR to adaptation to network
conditions.  Alternatively, the VAD guidelines in the Perkin's draft
(section 3) might also be relevant (and could be adapted to the use of VBR
to minimize average bandwidth use).  Though I think those guidelines need
more scrutiny.

Either way, this is a reason for standardizing both the encoder and the
decoder - as this particular vulnerability is in the encoder.

Stephen Botzko
Polycom

On Wed, Sep 9, 2009 at 9:30 AM, Wyss, Felix <[email-masked]> wrote:

> This is not relevant to the codec, though.  If the parties see the need to
> disguise the duration of the interaction, they can keep the streams up
> longer, for example to some fixed length.
>
>
> Isn't the goal of this Internet audio codec to avoid having proprietary and
> likely incompatible extensions?  Anything not clearly spelled out in the RFC
> is basically fair game and good luck getting devices from different vendors
> to play well together.  In our experience, it's hard enough to get devices
> that implement what's in the RFCs correctly and anything slightly unusual
> greatly increases the likelihood of incompatibilities and problems.  For
> example, I'd be reluctant to use RTP padding here for this very reason and
> because it's up to the sender and not part of the media type negotiation.
>
> --Felix
>
>

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Wed, 9 Sep 2009 11:12:02 -0400

Re: "It might also be wise to limit the use of VBR to adaptation to
network conditions."

Huh? I think I might understand if you equated VAD/DTX (of a CBR codec)
or layered codec with VBR ... but in general?

For example, lossless codecs (data compression algorithms) have the
property that their output entropy is a function of the input signal
entropy. In other words, they are VBR by design.

To "pad" (or obfuscate) such codec operation is tantamount to wasting
information for a criteria (lack of information leakage) that might not
be important to the particular session.

I fail to see that this is a MUST requirement. The people looking for
exploitable and classifiable differences in the output (i.e.,
information leakage) will just have to look harder/longer (just ask
NSA).

Michael Ramalho

From: [email-masked] [mailto:[email-masked]] On Behalf
Of stephen botzko
Sent: Wednesday, September 09, 2009 10:57 AM
To: Wyss, Felix
Cc: [email-masked]
Subject: Re: [codec] Codec guidelines and requirements drafts:
eavesdropping

All VBR codecs are potentially vulnerable to traffic analysis.  There is
at least one active draft in AVT on the subject already
(http://www.ietf.org/id/draft-perkins-avt-srtp-vbr-audio-01.txt).

IMHO, the best way to handle this right now is to let the AVT
discussions develop.  

It might also be wise to limit the use of VBR to adaptation to network
conditions.  Alternatively, the VAD guidelines in the Perkin's draft
(section 3) might also be relevant (and could be adapted to the use of
VBR to minimize average bandwidth use).  Though I think those guidelines
need more scrutiny.

Stephen Botzko
Polycom

> Should a signaling stack have a mode without termination?

This is not relevant to the codec, though.  If the parties see the need
to disguise the duration of the interaction, they can keep the streams
up longer, for example to some fixed length.

> reasonably secure communications tool will know how to pad a VBR
codec.

I believe content privacy is pretty fundamental and not just some "niche
market requirement".

Isn't the goal of this Internet audio codec to avoid having proprietary
and likely incompatible extensions?  Anything not clearly spelled out in
the RFC is basically fair game and good luck getting devices from
different vendors to play well together.  In our experience, it's hard
enough to get devices that implement what's in the RFCs correctly and
anything slightly unusual greatly increases the likelihood of
incompatibilities and problems.  For example, I'd be reluctant to use
RTP padding here for this very reason and because it's up to the sender
and not part of the media type negotiation.

--Felix

---

From: stephen botzko <[email-masked]>
Date: Wed, 9 Sep 2009 11:36:29 -0400

conditions.

The Perkins draft (section 2) is suggesting that

  To avoid the potential information leaks that might enable traffic
   analysis, VBR audio codecs that alter the size or spacing of their
   output according to the characteristics of the input speech signal
   SHOULD NOT be used with encrypted SRTP sessions.

My comment was not intended to be general (for all time), just that it *might
*be wise to limit the use of VBR in the requirements for the *first* codec.
Although this is perhaps needlessly conservative from a bandwidth
perspective, it does prevent traffic analysis, and also ensures that the
codec does not need to have a distinct operating mode for SRTP.

Again, my view is that the AVT should take the lead on this, and I also note
that the Perkins draft is a recent submission.

MUSTs (and SHOULD NOTs) related to security are important, and in my view
any codec work in the IETF should conform to best practices as far as
security is concerned.  It would be particularly embarrassing if the AVT
published a BCP that the IETF codec group did not follow.

Regards,
Stephen Botzko
Polycom

On Wed, Sep 9, 2009 at 11:12 AM, Michael Ramalho (mramalho) <
[email-masked]> wrote:

>  Re: “It might also be wise to limit the use of VBR to adaptation to
> network conditions.”
>
>
>
> Huh? I think I might understand if you equated VAD/DTX (of a CBR codec) or
> layered codec with VBR … but in general?
>
>
>
> To “pad” (or obfuscate) such codec operation is tantamount to wasting
> information for a criteria (lack of information leakage) that might not be
> important to the particular session.
>
>
>
> exploitable and classifiable differences in the output (i.e., information
> leakage) will just have to look harder/longer (just ask NSA).
>
>
>
> Michael Ramalho
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *stephen botzko
> *Sent:* Wednesday, September 09, 2009 10:57 AM
> *To:* Wyss, Felix
> *Cc:* [email-masked]
> *Subject:* Re: [codec] Codec guidelines and requirements drafts:
> eavesdropping
>
>
>

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 9 Sep 2009 11:47:09 -0400

> entropy. In other words, they are VBR by design.

I think (well, I hope!) we all agree that asking a lossless codec to be CBR
doesn't make any sense.

> information leakage) will just have to look harder/longer (just ask

I don't think anyone said that VBR should be ruled out. The only thing that was
mentioned was having a CBR option in the codec for the cases where the user
*does* care. Of course, all of this only applies to lossy codecs (I'm still
waiting for a lossless codec that is guaranteed to always reduce the size!).

Cheers,

   Jean-Marc

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Wed, 9 Sep 2009 11:54:18 -0400

Re:" I thus think it is a MUST requirement that the encoder can be run in a mode where there is no correlation between packet size, packet rate and timing, and the short and long-term audio being encoded."

What is your definition of "no correlation"?

I can more or less guarantee you that humans can design a system that they believe has "no correlations" .... but if you train a classifier with enough training data with similar sessions .... that you can with high probability ascertain the use (or uses) of the channel.

As we speak, bittorrent (and other applications) are being classified (i.e., accurately identified) inside of IPSec tunnels (or TLS sessions) as I type this. We may not know what is going on inside those channels at any given instant - but we have some information (i.e., some information leakage!).

So this whole discussion is a matter of degree. Again, ask NSA or people applying decades-old classification techniques (VQ, HMMs, etc.) to unstructured data communications.

So while I may agree that *some effort* should/may be made to obfuscate what is going on (just to make it a little harder for the bad guys), it is asymptotically hard to design a system with "no correlations" .... as classification machines can see very small differences in channel behavior characteristics. I think voice and video transmissions are pretty easy to identify (as their entropy ranges and rates of change are well known).

I wouldn't like to see us go down this path only to find that some relatively unintelligent undergraduate student uses a MATLAB classification function to successfully identify our session with less than a few hours of effort.

Michael Ramalho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wyss, Felix
Sent: Monday, September 07, 2009 2:15 PM
To: 'Ron'; [email-masked]
Subject: Re: [codec] Codec guidelines and requirements drafts: eavesdropping

--Felix

---

From: Gregory Maxwell <[email-masked]>
Date: Wed, 9 Sep 2009 13:57:52 -0700

Michael Ramalho (mramalho) [[email-masked]] wrote:
> I can more or less guarantee you that humans can design a system that they believe has "no correlations" .
> ... but if you train a classifier with enough training data with similar sessions .... that you can with high probability ascertain the use (or uses) of the channel.
[snip]

No information = no correlation.  I'm a little surprised to see this CBR issue being debated.

First please take a moment to look at this:

http://www.cs.jhu.edu/~cwright/voip-vbr.pdf

In this paper they perform blind language identification using only VBR packet size sequences from speex.  While many people don't care if an evesdropper could identify their language from the coded packets, I think we'd all be surprised to have this happen (*but it's encrypted!*) and I hope we can understand that it might be a real security problem for some people.

Of course, it may be that other codecs don't suffer from this as badly as speex does— but we have no way to tell. Like many things in security we can try and fail, only to have an attacker show up later with a more powerful tool.  The ability to use a constant frame size kills that leak dead.  You are either leaking information about the interior channel or you are not, and if you are there is a great big uncertainty about how much of a leak the user can tolerate and how strong the attacker's statistical analysis is. 

True— there are other risks: Third parties are able to analyize the times and durations, look at who talks to who.  These leak information too, but these leaks are very difficult to cure even at an enormous cost and they exist for most secure communication systems. They are obvious and intuitive weaknesses which should not catch users of secure systems by surprise.  The same is not true of VBR: For VBR the possible leak is surprising and the leak can be completely closed at a low cost.

We do not reject SSL and SSH because it's possible that an attacker has installed a keylogger or because of the prevalence of malware may sometimes make them moot.

The magnitude of the leak presented by VBR, if the paper on speex is anything to go by, is significantly greater than the magnitude of weaknesses in some cryptosystems which were considered absolutely fatal.  If you ask a crypto/security focused person to build a secure system out of a data-dependant VBR codec they are going to pad it to a constant size. It's so inexpensive to close that weakness (even just using transport padding to a constant size) that even with the most conservative estimate of the leak amount it is obviously worth doing if your goal is security.

So *given* that some users are going to demand constant length output for security reasons or for frame-filling reasons wouldn't it be a good engineering criteria for the codec to be able fill constant size buffers exactly and have a chance to make some good use of the space provided rather than waste it with useless zeros? Wouldn't it be a win for interoperability to not have to contend with a multitude of external padding systems?

---

From: Alexander Chemeris <[email-masked]>
Date: Thu, 10 Sep 2009 01:52:19 +0400

Hi,

A few afterthoughts to add to my previous notes:

> stated as MUST or at least SHOULD for conferencing scenario and

Also test set should include double-encoding for the same purpose
of conferencing. It's likely that conference bridge will decode speech,
and then encode it again and this should not introduce big degradation
of quality.

Also re: CBR support.
>From what I know, CBR mode is usually less CPU intensive and less
memory hungry, and thus is much better suited for very small and dumb
chips. So ability to support true CBR (not the one with padding, but the
one with just one mode) is very much wanted. For such devices it's usually
required to have low-complexity codec with *acceptable* qulity, i.e. it
is not required to be perfect. I think we should add this point of low CPU
and memory consumption to the wanted list of CBR features in
requirements I-D.

-- 
Regards,
Alexander Chemeris.

SIPez LLC.

---

From: Koen Vos <[email-masked]>
Date: Wed, 09 Sep 2009 15:15:46 -0700

Quoting Jean-Marc Valin:

> I don't think anyone said that VBR should be ruled out. The only  
> thing that was mentioned was having a CBR option in the codec for  
> the cases where the user *does* care.

The privacy problem can easily be solved at a higher layer than the  
codec, by padding a VBR codec in conjunction with encryption. We can  
definitely help the SRTP guys figure out how to do that (padding with  
zeros would obviously be bad for the encryption). And I also have no  
problem with providing a CBR mode that they can prescribe.

Most users and applications will be fine with VBR however, because the  
information leak from VBR is small compared to other leaks (including  
IP addresses, which are easy to extract, can be used as evidence in  
court, etc). PSTN and GSM phones are far more "leaky" than  
well-encrypted VBR, and few people shun these because of privacy  
concerns.

Above all, using CBR for all modes would come at a high cost in  
bitrate, which would roughly double. That would hurt adoption of the  
codec, as many developers would simply choose a more efficient codec,  
and IWAC risks becoming irrelevant.

koen.

---

From: Koen Vos <[email-masked]>
Date: Wed, 09 Sep 2009 15:24:32 -0700

Quoting Alexander Chemeris:

> chips.

Haven't heard that before, any references?

I would say the CPU and memory consumption depend mostly on coding  
efficiency (ie, quality/bitrate). If anything, VBR has an advantage by  
not spending as many cycles encoding background noise.

koen.

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Thu, 10 Sep 2009 00:24:00 -0400

Koen Vos wrote:
> Above all, using CBR for all modes would come at a high cost in bitrate,
> which would roughly double. That would hurt adoption of the codec, as
> many developers would simply choose a more efficient codec, and IWAC
> risks becoming irrelevant.

No one is suggesting that CBR be the default.  In fact, the requirements
list VBR specifically as a required codec feature, with the implication
that the great majority of users will operate in a VBR mode.

The only requirement in the draft is that the reference encoder offer a
CBR mode, if the client requests it.  This hardly seems controversial, and
I can't imagine how such an optional encoder feature could hurt adoption
of the codec.  This CBR mode need not be particularly efficient, though
efficiency is always nice.  Even a padding scheme would satisfy the
requirements.

--Ben

---

From: Koen Vos <[email-masked]>
Date: Wed, 09 Sep 2009 22:04:14 -0700

> efficiency is always nice.  Even a padding scheme would satisfy the

You're right, there is no controversy: we'll have both CBR and VBR.

(My unhappiness is really with the SRTP draft suggesting that SRTP  
should not be used with VBR - I'll take it to the AVT list.)

koen.