Subject: [codec] Codec Standardization Expertise

From: stephen botzko <[email-masked]>
Date: Thu, 30 Jul 2009 13:49:13 -0400

Exactly what this expertise consisted of was one of the subjects in the BOF
today.

I have three comments -

(1) The proposed WG charter appears to span several distinct ITU-T groups.

SG16/Q9: "Embedded variable bit rate coding of speech signals"
SG16/Q10:  "Speech and audio coding and related software tools"
SG12/Q7: "Methods, tools, and test plans for the subjective assessment of
speech, audio, and audiovisual quality interactions"

There are some other groups in SG12 which arguably are also covered in this
charter, including perhaps SG12/Q9 (Perceptual-based objective methods for
voice, audio, and visual quality measurements).

I am not intending to say that the charter is too broad (though of course it
might be argued that it is).  Just that when we identify the needed
expertise, we should include the full set of relevant groups in the other
SDOs.  So far we are asking folks if they are "codec experts".  Other skills
are needed.

(2) Over the audio stream I heard a comment to the effect that "anyone with
two ears is competent to evaluate codec quality".  Lots of applause.  I
think this statement is naive and dangerously misleading.  People with ears
clearly listened to iLBC, and apparently still missed its issue with tonal
languages.  (Yes its experimental and wasn't adequately reviewed. That is
the point).

It is true that anyone who can hear can serve as a test subject.  But
reviewing/validating the test plan and the observed results is not something
that anyone can do.  This is not to say that there is no one in the IETF who
has the skills.  But I am still thinking that the discussions so far are
seriously understating the importance of proper characterization and
testing.  The bulk of the time in other SDOs is spent on requirements
definition and testing questions.  The actual algoriithm development is
treated as a homework assignment.

(3) Using other organizations (such as perhaps SG12/Q7???) to evaluate our
codecs also came up in the meeting.  That might be an interesting
collaboration if possible.  But I don't think you'll get useful results
without a lot of up-front discussion.  (I have seen how those liason
statements get written!).

Regards,
Stephen Botzko
Polycom

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 30 Jul 2009 16:15:12 -0400

(Many useful comments elided, to focus on one.)
In fact, the community response to this comment (about evaluating 
codecs) is symptomatic of the expertise problem.  I know just enough 
abou this space to know that random pairs of ears, even random pairs of 
high quality ears, are not sufficient to evaluate whether a codec does a 
good job, much less a good job across all of the requirements.
However, like many communities, and like many problem areas, we tend to 
assume we understand more than we do.  So folks like the idea of just 
using peoples ears to evaluate the codecs in some simple fashion.

Yours,
Joel M. Halpern

stephen botzko wrote:
...
> (2) Over the audio stream I heard a comment to the effect that "anyone 
> with two ears is competent to evaluate codec quality".  Lots of 
> applause.  I think this statement is naive and dangerously misleading.  
> People with ears clearly listened to iLBC, and apparently still missed 
> its issue with tonal languages.  (Yes its experimental and wasn't 
> adequately reviewed. That is the point).  
> 
> reviewing/validating the test plan and the observed results is not 
> something that anyone can do.  This is not to say that there is no one 
> in the IETF who has the skills.  But I am still thinking that the 
> discussions so far are seriously understating the importance of proper 
> characterization and testing.  The bulk of the time in other SDOs is 
> spent on requirements definition and testing questions.  The actual 
> algoriithm development is treated as a homework assignment.
...
> Regards,
> Stephen Botzko
> Polycom
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec

---

From: "Slava Borilin" <[email-masked]>
Date: Fri, 31 Jul 2009 00:30:47 +0400

Joel,

We (SPIRIT Skype XIPH at least) don't expect "ear test".
We are just saying for the time being, that the methods are rather
"well-defined" for judging the codec quality in terms of mos score, so
there was no the main focus for todays BOF.

During the work of the WG, if its formed, definitely we will deploy the
correct process for codec evaluation, with the help and aids from others
who are skilled in this, like you and Stephen hopefully.

best regards,
Slava Borilin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Joel M. Halpern
Sent: Thursday, July 30, 2009 10:15 PM
To: [email-masked]
Subject: Re: [codec] Codec Standardization Expertise

Yours,
Joel M. Halpern

stephen botzko wrote:
...

...

---

From: Alexander Chemeris <[email-masked]>
Date: Thu, 30 Jul 2009 22:18:26 +0400

Hello,

If I understand correctly what's going on, then this WG is meant to be
a recommendation and classification body, a collaboration point for everyone
interested in the topic. ITU-T groups does their job, they standardize
codecs, quality measures, etc and do their job good enough. What they
do not do - they do not and can not recommend any given codec for
a broad use in the voice over the Internet. That's just not their objective.
So, this group can produce a list criteria for VoIP codecs, evaluate
existing codecs using existing test methods and recommend (or not
recommend) some of the codecs for broad use.
As a bonus, this WG promise to be a good place of collaboration
among codec developers who want to outline the requirements for
an ideal VoIP codec and try jointly to develop one for later standardization
by this WG.

So, in a fewer words:
1) This is not an opposite to ITU-T, but rather complementary.
2) This is not about codec development, but rather about specification
of requirements and fixation of current state of affairs and recommendations.

Please, correct me if I've got things incorrectly.

-- 
Regards,
Alexander Chemeris.

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 30 Jul 2009 22:42:22 +0200 (CEST)

> who are skilled in this, like you and Stephen hopefully.

As I stated at the microphone during the session, the most important 
aspect I see an a network engineer is that the Internet behaviour needs to 
drive both the codec design and how it's transported, not the other way 
around. Codecs can't set demand on how the Internet should behave, it just 
doesn't work in the real world.

If you can't make a codec that can gracefully handle intermittent 2 second 
packet jitter and 10% packetloss and then go back to good 
quality/end-to-end delay again when conditions improve, then you have to 
realise what you're doing isn't not suitable to fit on the Internet.

The codecs I've seen before in the ITU space has completely dropped the 
ball here (mainly experience from G.711 and G.729 here though).

As soon as I see 20 ms jitter tolerances and 0.5% packet loss to reach 
decent MOS values I get.... errr.. tired.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Slava Borilin" <[email-masked]>
Date: Fri, 31 Jul 2009 00:44:13 +0400

You are 100% right.

This should be the step1 of the WG - to define the REAL CONDITIONS for
the codec to work in.

best regards,
Slava Borilin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mikael Abrahamsson
Sent: Thursday, July 30, 2009 10:42 PM
To: [email-masked]
Subject: Re: [codec] Codec Standardization Expertise

As I stated at the microphone during the session, the most important 
aspect I see an a network engineer is that the Internet behaviour needs
to 
drive both the codec design and how it's transported, not the other way 
around. Codecs can't set demand on how the Internet should behave, it
just 
doesn't work in the real world.

If you can't make a codec that can gracefully handle intermittent 2
second 
packet jitter and 10% packetloss and then go back to good 
quality/end-to-end delay again when conditions improve, then you have to

---

From: stephen botzko <[email-masked]>
Date: Thu, 30 Jul 2009 17:02:20 -0400

I agree overall, and am happy to see some consensus on importance of the
characterization and testing,

But to be fair, the issues with jitter and packet loss are generally due to
the packetization constraints in the RTP RFC, not the ITU-T spec itself.
G.719's packetization RFC allows for interleaved and overlapped (redundant)
audio frames, and permits the duplicate frames to be at lower rates.  That
allows for good quality to be maintained under packet loss conditions
(though if the network is congested, of course you need to use an overall
lower rate)..  All the codecs I've used will recover state very quickly when
conditions improve.  I can't see how the codec can solve an end-to-end delay
problem, it seems to me that if the delay doesn't heal itself when
conditions improve, it is likely to be a transport problem that the codec
can't influence.

Regards,
Stephen Botzko
Polycom

On Thu, Jul 30, 2009 at 4:42 PM, Mikael Abrahamsson <[email-masked]>wrote:

>> correct process for codec evaluation, with the help and aids from others who
>> are skilled in this, like you and Stephen hopefully.
>>
>
> As I stated at the microphone during the session, the most important aspect
> I see an a network engineer is that the Internet behaviour needs to drive
> both the codec design and how it's transported, not the other way around.
> Codecs can't set demand on how the Internet should behave, it just doesn't
> work in the real world.
>
> packet jitter and 10% packetloss and then go back to good quality/end-to-end
> delay again when conditions improve, then you have to realise what you're
> doing isn't not suitable to fit on the Internet.
>

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 30 Jul 2009 23:21:37 +0200

Hi

Sorry to say that this is just desinformation. If the objective is to
convince the average IETF'er then you may score a few points but people
who are active in speech coding in other standards foras and happen to
read threads like this will only see it as narrowminded propaganda. 

It has probably been said before... 
Speech codec develepment and specification of speech services done in
other standards foras today are mainly targeting packet switched
transport, jitter and packet loss is nothing new, it makes me equally
tired to see that numerous proponents of a codec WG try to convince the
IETF that we are going to solve a problem that the other standards foras
did not know existed, it is just wrong !

/Ingemar

> From: Mikael Abrahamsson [mailto:[email-masked]] 
> Sent: den 30 juli 2009 22:42
> To: [email-masked]
> > During the work of the WG, if its formed, definitely we will deploy 
> > the correct process for codec evaluation, with the help and 
> aids from 
> > others who are skilled in this, like you and Stephen hopefully.
> 
> As I stated at the microphone during the session, the most 
> important aspect I see an a network engineer is that the 
> Internet behaviour needs to drive both the codec design and 
> how it's transported, not the other way around. Codecs can't 
> set demand on how the Internet should behave, it just doesn't 
> work in the real world.
> 
> If you can't make a codec that can gracefully handle 
> intermittent 2 second packet jitter and 10% packetloss and 
> then go back to good quality/end-to-end delay again when 
> conditions improve, then you have to realise what you're 
> The codecs I've seen before in the ITU space has completely 
> dropped the ball here (mainly experience from G.711 and G.729 
> here though).
> 
> As soon as I see 20 ms jitter tolerances and 0.5% packet loss 
> to reach decent MOS values I get.... errr.. tired.
> 
> --

---

From: "Slava Borilin" <[email-masked]>
Date: Fri, 31 Jul 2009 01:23:48 +0400

;-)

best regards,
Slava Borilin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ingemar Johansson S
Sent: Thursday, July 30, 2009 11:22 PM
To: Mikael Abrahamsson; [email-masked]
Subject: Re: [codec] Codec Standardization Expertise

Hi

/Ingemar

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 30 Jul 2009 17:26:10 -0400

Slava, my apologies if you, or anyone else who works extensively with 
codec, understood my note as suggesting that you asked for what was 
suggested.

Those of you who work with codecs extensively seem (to the extent I am 
competent to judge) to know your business.

My point was rather that the community that is supposed to evaluate the 
working group product, outside of the WG, has serious misconceptions 
about what it takes to do the work, to evaluate the work, to test the 
work, and all the other aspects.  And I was using this comment by a 
respected IETF participant as an exemplar of my concern about the misfit 
between the IETF community and this problem space.  (And the real point 
is not even the person who said it.  Rather it is the communities 
reaction to the statement.)

Yours,
Joel

---

From: Simon Perreault <[email-masked]>
Date: Thu, 30 Jul 2009 23:32:57 +0200

Of course the people of the IETF community know that evaluating a codec
is not done by ears alone.

The applause was in the same spirit as if "THIS IS SPARTA!" had been
shouted. For comic relief.

Can we stop with the ad hominem arguments now and get to work on the
charter?

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

---

From: stephen botzko <[email-masked]>
Date: Thu, 30 Jul 2009 17:40:54 -0400

I don't think I made any ad hominem arguments.  Hopefully that wasn't aimed
at me.

Listening on the audio feed, it absolutely sounded like several members
thought precisely that.  The comment was repeated several times, and was
never contradicted.

Without being there, it was hard to read the mood. But it didn't sound like
comic relief over the air.

Regards,
Stephen Botzko
Polycom

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 31 Jul 2009 07:01:29 +0200 (CEST)

> did not know existed, it is just wrong !

So what codec and *transport* that someone else has standardized will work 
in the conditions I stated?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 31 Jul 2009 07:17:24 +0200 (CEST)

On Thu, 30 Jul 2009, stephen botzko wrote:

> But to be fair, the issues with jitter and packet loss are generally due 
> to the packetization constraints in the RTP RFC, not the ITU-T spec 
> itself. G.719's packetization RFC allows for interleaved and overlapped 
> (redundant) audio frames, and permits the duplicate frames to be at 
> lower rates.  That allows for good quality to be maintained under packet 
> loss conditions (though if the network is congested, of course you need 
> to use an overall lower rate)..  All the codecs I've used will recover 
> state very quickly when conditions improve.  I can't see how the codec 
> can solve an end-to-end delay problem, it seems to me that if the delay 
> doesn't heal itself when conditions improve, it is likely to be a 
> transport problem that the codec can't influence.

We need to design something that works, and that involves creating a codec 
and a transport that handles the real world, not trying to adapt the real 
world to the constraints of the codec and transport. Saying you need a 
lower rate in case of congestion isn't the case either, that won't help 
yourself anything because you're most likely competing with TCP flows 
which will take all they can get. What you need to do is "stand your 
ground", perhaps go for lower sound quality but keep the bitrate so the 
packets you actually get through will make sounds at the other end that is 
as good as it can get during the conditions. G.719 might do this as you 
say, I don't know.

We need a codec and transport that when faced with adverse network 
conditions will handle this gracefully and adapt its jitter buffer (if 
jitter increases to 1s, it should increase its jitter buffer to handle 
this, then when network conditions improve it needs to somehow lower the 
jitter buffer again which means it'll have to play sound "faster" to catch 
up). All this needs to work between the codec/transport layers, and 
information regarding sound needs to be spread across several packets in 
case of packet loss (degrade sound quality nicely), and to retain the low 
end-to-end delay when network conditions are good, it also needs to go 
back to the usual "all sound for these 20ms sound in one packet"-mode for 
that.

So the codec and underlying transport cannot *influence* the network IP 
behavior, but it needs to be able to ADAPT to it and handle it, providing 
as good user experience as possible.

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 31 Jul 2009 08:16:34 +0200

Hi

> So what codec and *transport* that someone else has 
> standardized will work in the conditions I stated?

Please have a look at sections 8-10 in 
http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-830.zip
In addition annex C contains examples of adaptation state machines

Regards
Ingemar

> Sent: den 31 juli 2009 07:01
> To: Ingemar Johansson S
> Cc: [email-masked]
> > tired to see that numerous proponents of a codec WG try to convince 
> > the IETF that we are going to solve a problem that the 
> other standards 
> > foras did not know existed, it is just wrong !
> 
> So what codec and *transport* that someone else has 
> standardized will work in the conditions I stated?
> 
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 31 Jul 2009 10:07:29 +0200 (CEST)

On Fri, 31 Jul 2009, Ingemar Johansson S wrote:

> http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-830.zip In 
> addition annex C contains examples of adaptation state machines

So I read 8-10 (well, 8 and 9, section 10 was kind of hard to understand) 
and the logic seems sound and seems to do a lot of what I have been 
talking about.

Where can I download a program to install on two PCs (linux or windows) to 
test in my lab if this actually works in the conditions I'm describing?
(I'll put something between them that'll induce delay, jitter and 
packetloss)

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 31 Jul 2009 10:08:19 +0200 (CEST)

On Fri, 31 Jul 2009, Mikael Abrahamsson wrote:

> Where can I download a program to install on two PCs (linux or windows) 
> to test in my lab if this actually works in the conditions I'm 
> describing? (I'll put something between them that'll induce delay, 
> jitter and packetloss)

Sorry, I should have written "program that implements this"...

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 31 Jul 2009 11:12:29 +0200

Hi

Like I said before. I really don't see why we need a codec WG in IETF to
solve the issues mentioned below, please again see sections 8-10 +annex
C in
http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-830.zip and
you'll realize that these issues are already addressed.

I claim that with a codec WG in IETF we will not invent something new,
we only duplicate all or a subset of other SDO's work.

The only possible difference I see is the strive for royalty free or
license free and AFAIK there is no guarantee of that in IETF. 
But.... it is important to ask the question if we create this WG to
solve a technical problem or to solve a business problem ? I don't see
the technical "novelty" as other SDO's are aleady working on this, what
is left is the business problem (or license problem or whatever). Is it
enough motivation to create a WG ?.  

/Ingemar 

> Sent: den 31 juli 2009 07:17
> To: [email-masked]
> > But to be fair, the issues with jitter and packet loss are 
> generally 
> > due to the packetization constraints in the RTP RFC, not the ITU-T 
> > spec itself. G.719's packetization RFC allows for interleaved and 
> > overlapped
> > lower rates.  That allows for good quality to be maintained under 
> > packet loss conditions (though if the network is congested, 
> of course 
> > you need to use an overall lower rate)..  All the codecs I've used 
> > will recover state very quickly when conditions improve.  I 
> can't see 
> > how the codec can solve an end-to-end delay problem, it seems to me 
> > that if the delay doesn't heal itself when conditions 
> improve, it is 
> > likely to be a transport problem that the codec can't influence.
> 
> We need to design something that works, and that involves 
> creating a codec and a transport that handles the real world, 
> not trying to adapt the real world to the constraints of the 
> codec and transport. Saying you need a lower rate in case of 
> congestion isn't the case either, that won't help yourself 
> anything because you're most likely competing with TCP flows 
> which will take all they can get. What you need to do is 
> "stand your ground", perhaps go for lower sound quality but 
> keep the bitrate so the packets you actually get through will 
> make sounds at the other end that is as good as it can get 
> during the conditions. G.719 might do this as you say, I don't know.
> 
> We need a codec and transport that when faced with adverse 
> network conditions will handle this gracefully and adapt its 
> jitter buffer (if jitter increases to 1s, it should increase 
> its jitter buffer to handle this, then when network 
> conditions improve it needs to somehow lower the jitter 
> buffer again which means it'll have to play sound "faster" to 
> catch up). All this needs to work between the codec/transport 
> layers, and information regarding sound needs to be spread 
> across several packets in case of packet loss (degrade sound 
> quality nicely), and to retain the low end-to-end delay when 
> network conditions are good, it also needs to go back to the 
> usual "all sound for these 20ms sound in one packet"-mode for that.
> 
> So the codec and underlying transport cannot *influence* the 
> network IP behavior, but it needs to be able to ADAPT to it 
> and handle it, providing as good user experience as possible.
> 
> --

---

From: Alexander Chemeris <[email-masked]>
Date: Fri, 31 Jul 2009 13:32:03 +0400

Hi,

> enough motivation to create a WG ?.

What about the way, I described in my first mail in this thread?
I.e. this WG to be a codec evaluation and recommendation body,
rather then codec-standardization.

PS While your statement that there is nothing new invented here (yet)
is correct, you miss that while everyone knows the problems, there are
still no ideal VoIP codec. The effort to carefully specify needs of VoIP
is half of the way to encouraging someone to create one. And thus is
worthwhile.
PPS Royalty-free requirement is not "just a some small addition to
other's SDO requirements". It's a vital part. Other SDOs were failing
to produce royalty-free codecs till now. Why should we rely on them for
the future?

-- 
Regards,
Alexander Chemeris.

SIPez LLC.

---

From: stephen botzko <[email-masked]>
Date: Fri, 31 Jul 2009 06:24:05 -0400

Saying you need a lower rate in case of congestion isn't the case either,
that won't help yourself anything because you're most likely competing with
TCP flows which will take all they can get. What you need to do is "stand
your ground" ...

I do not believe this is the prevailing view in the IETF. It is inconsistent
with the language in newer packetization RFCs, including the language in RFC
5404.  Likewise section 2.4 of RFC 3550 clearly implies that the appropriate
adaptation to network congestion is to reduce bandwidth use.

Ignoring congestion on the grounds that other flows might ignore it also
does not seem to be a very useful approach.

Regards,
Stephen Botzko
Polycom

On Fri, Jul 31, 2009 at 1:17 AM, Mikael Abrahamsson <[email-masked]>wrote:

>> to the packetization constraints in the RTP RFC, not the ITU-T spec itself.
> world to the constraints of the codec and transport. Saying you need a lower
> rate in case of congestion isn't the case either, that won't help yourself
> anything because you're most likely competing with TCP flows which will take
> all they can get. What you need to do is "stand your ground", perhaps go for
> lower sound quality but keep the bitrate so the packets you actually get
> through will make sounds at the other end that is as good as it can get
> jitter increases to 1s, it should increase its jitter buffer to handle this,
> then when network conditions improve it needs to somehow lower the jitter
> buffer again which means it'll have to play sound "faster" to catch up). All
> this needs to work between the codec/transport layers, and information
> regarding sound needs to be spread across several packets in case of packet
> loss (degrade sound quality nicely), and to retain the low end-to-end delay
> when network conditions are good, it also needs to go back to the usual "all
> sound for these 20ms sound in one packet"-mode for that.
>
> behavior, but it needs to be able to ADAPT to it and handle it, providing as
> good user experience as possible.
>
>
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 31 Jul 2009 13:06:21 +0200 (CEST)

On Fri, 31 Jul 2009, stephen botzko wrote:

> I do not believe this is the prevailing view in the IETF.

Ok, fair enough. I still have the opinion that it depends on the kind of 
problem seen, if real time (which is the general case in case of VoIP ) 
flow size is very small compared to others, then reducing the BW has 
marginal improvement potential, and since this is most likely high 
importance traffic to the user, yes, codec bw should be reduced but some 
of that reduction should be spent on improving reliability in the stream 
(more redundant information transmitted so a call can be sustained in 
acceptable quality).

> does not seem to be a very useful approach.

I didn't say ignore, at least I didn't mean to. Let's call it a 
re-allocation of resources from high quality to means of maintaining 
acceptable quality instead.

---

From: stephen botzko <[email-masked]>
Date: Fri, 31 Jul 2009 07:14:50 -0400

Ok.  You ended up agreeing with what I said in my first post. I pointed out
the redundant frames/interleaved frame transmission in the G.719 rfc, but
said you should also switch to a lower bandwidth mode if the network were
congested.

Regards,
Stephen Botzko
Polycom

On Fri, Jul 31, 2009 at 7:06 AM, Mikael Abrahamsson <[email-masked]>wrote:

> problem seen, if real time (which is the general case in case of VoIP ) flow
> size is very small compared to others, then reducing the BW has marginal
> improvement potential, and since this is most likely high importance traffic
> to the user, yes, codec bw should be reduced but some of that reduction
> should be spent on improving reliability in the stream (more redundant
> information transmitted so a call can be sustained in acceptable quality).
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 31 Jul 2009 13:22:37 +0200 (CEST)

> said you should also switch to a lower bandwidth mode if the network were

Absolutely, I never meant to advocate *increasing* bw by means of 
maintaining codec bw but transmitting more redundant information, thus 
increasing the overall IP bits/s used.

---

From: Herve Taddei <[email-masked]>
Date: Fri, 31 Jul 2009 13:43:40 +0200

Hi,

> to produce royalty-free codecs till now. Why should we rely on them for

I don’t think there is any insurance that the IETF work will provide a RF
codec. What is the benefit of this work if you don’t get RF codecs? So far,
it really seems to be the only argument to start this work. 

And there is something some people seem to always forget/ignore is that
there are already some standards that are RF codecs: G.722, G.722.1,
G.722.1C, G.711 and certainly some others. Some people say they don’t fit
their needs, but when I read the current draft charter it does not seem to
be true as these codecs perfectly fit it. The fact that these codecs have RF
conditions because either it was a company choice to offer them for free or
because their patents ran out is irrelevant to the discussion. The fact is
there are already RF codecs. 

Then we can read that you need an Internet dedicated codec, but so far in
the charter there is nothing special that could make me thinking, yes this
is an Internet codec.

To your last point, why should you rely on other SDOs:
- because usually it is where main telcos, vendors and experts are,
- because their codec evaluation/characterization is well defined,
- because their codec applications/requirements are well organized and codec
standardization is started based on these definitions.

Best regards

Hervé

---

From: Alexander Chemeris <[email-masked]>
Date: Fri, 31 Jul 2009 16:41:41 +0400

Hi,

> it really seems to be the only argument to start this work.

Sorry, probably you do not follow, but RF requirement was put on the very
first slides and repeated several times later. Moreover, several serious
companies offers to open their codecs as RF ones - you should have missed
this too. After all, there is CELT, being built as RF from the ground up. There
is a lot of willing for RF codec(s).

> there are already RF codecs.

Sorry, these codecs does not meet other criteria. They're not bandwidth
efficient, they do not behave well in the presence of packet loss, etc.

> the charter there is nothing special that could make me thinking, yes this

Please, read all requirements again. Think of them together, not about
each one separately.

> standardization is started based on these definitions.

Sounds good, with the only exception, I mentioned above - absence of
RF codec they standardized. Plus lack of modern codecs, suitable for
the use of the Internet programmers, not telco ones. Plus absence of
really low-delay WB codec. Plus inability to participate for usual people,
not belonging to big telcos. Oh, isn't there too much exceptions?

And yet I don't see reasons I should not rely on IETF.

-- 
Regards,
Alexander Chemeris.

SIPez LLC.

---

From: Ron <[email-masked]>
Date: Fri, 31 Jul 2009 22:38:00 +0930

> it really seems to be the only argument to start this work. 

And there is likewise absolutely no warranty that the most expensive
patent-pending codec you could licence today will not also be subject
to further claims from other third parties, long after you've taken
them to the full deployment stage.

This seems like a completely neutral argument that has no relevance
to either side of the debate.  The IETF has well defined policies
for dealing with these issues.  Why do you think those are less
applicable here than to any other standard it has published?

> there are already RF codecs. 

If you really believe that G.711 is "good enough" for these purposes,
and that is the opinion of other SDOs, then that seems like the most
compelling argument I've seen so far for why this WG is desperately
needed.

> the charter there is nothing special that could make me thinking, yes this

What do you think is missing that would make you think that?  I'm sure
suggestions along those lines would be very well received, and was indeed
what further discussion should be focussing on right now.  If you know and
don't want to share, that seems like politics, not engineering.

> - because usually it is where main telcos, vendors and experts are,

If they had served this purpose well do you really think there would be
so much momentum behind forming this research group?  There are clearly
experts outside of this closed 'inner circle'.  If those people feel
that these groups have become obstructive or irrelevant, who do you
really think could possibly be to blame for that?

> standardization is started based on these definitions.

Are you implying that they somehow have an exclusive franchise on the
fundamentals of signal processing and engineering that have changed
little in the last 20 years?

If the argument is this group has no competence, then clearly other SDOs
have nothing whatsoever to fear from it.  Either it will produce nothing,
or junk that will be quickly debunked by the expert science of those SDOs.
Or they'll create something genuinely useful and these other groups will
have the chance to prove their Ultimate Wizardlyness by improving upon it.

And at the end of the day, isn't that what engineering is all about?

If friendly competition is the engine room of rapid innovation, what do
other SDOs possibly have to fear here except failure on their own part?
If they are as unquestionably expert as has been asserted, then surely
they have nothing to fear at all.

But I guess we'll see about that soon enough ;)

Genuinely Curious,
Ron

---

From: Herve Taddei <[email-masked]>
Date: Fri, 31 Jul 2009 16:06:24 +0200

> first slides and repeated several times later. Moreover, several serious

It is one thing to put them on the slide, it is another thing to get it.

BTW, you can give a look from IESG BOF report: “- understanding it would not
be possible to guarantee that resulting codecs would be royalty free”

> efficient, they do not behave well in the presence of packet loss, etc.

What is bandwidth efficient and robust enough? Please come up with values I
have not seen them so far.

For example, from the list of codecs presented yesterday CELT has a bitrate
between 40 and 128 kbit/s, SBC has a bitrate between 50 to 350 kbit/s. Are
those the bandwidth efficient codecs? FYI, the codecs I listed have bitrates
between 32 and 64 kbit/s.

> each one separately.

Requirements? Where? There is a charter and a slide with technical
considerations from the presentation yesterday that don’t seem to be
requirements to me. Or are there what you call requirements? So far we only
got some kind of very standard list of codec features, nothing special.

BTW from BOF meeting report:

- define requirements in far better depth, (I-Ds would be nice)

At least it seems that it was agreed that it is needed to clarify that.

> RF codec they standardized. 

Wrong as said at the beginning of my email.

> not belonging to big telcos. Oh, isn't there too much exceptions?

Do you know the delay of G.722? Do you think you will be able to do less? I
would be quite interested (fyi, 2 samples at 16 kHz, I let you compute).

Finally, small companies also participate to other SDOs, please give a look
to their member lists.

Best regards

Hervé

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Fri, 31 Jul 2009 10:20:50 -0400

"Ideal VoIP Codec" Commentary follows:

1>>>From Mikael Abrahamsson
Saying you need a lower rate in case of congestion isn't the case
either, that won't help yourself anything because you're most likely
competing with TCP flows which will take all they can get.

AND

So the codec and underlying transport cannot *influence* the network IP
behavior, but it needs to be able to ADAPT to it and handle it,
providing as good user experience as possible.

2>>>From Alexander Chemeris

PS While your statement that there is nothing new invented here (yet) is
correct, you miss that while everyone knows the problems, there are
still no ideal VoIP codec.

3>>>From Stephen Botzko

To me these comments are all manifestations of the same basic fact for
non-QoS Internet transport:

If you VoIP flow constitutes a MINORITY FLOW in a general elastic flow
(i.e., more TCP or SCTP than UDP) at your bottleneck link ... then
changing your VoIP rate will have minimal impact on the congestion at
the bottleneck link ... as that congestion is primarily a function of
the elastic traffic. This relates to Comment 1 above.

The problem is that you don't know by observing your flow if indeed your
traffic (or your traffic type, in this case inelastic UDP) is a MAJORITY
traffic or not. If the bottleneck link consisted of mostly inelastic
traffic (perhaps a VoIP service provider), then reducing your rate will
indeed help with congestion. If your VoIP flow is a minority traffic
type in the bottleneck link - a reduction in the VoIP sending rate may
have NO (significant) EFFECT on clearing congestion (owing to how the
elastic protocols work).

Therefore reducing your rate under observed congestion MAY OR MAY NOT
help the congestion on your path - but will definitely degrade your
experience. Indeed, some VoIP implementations (that I do not sanction)
actually increase their rate to improve their performance during poor
Internet transport (shame on them).

If you: 1) are using non-QoS transport and 2) have no detailed knowledge
of the (elastic vs. inelastic) traffic mix in the bottleneck link ....
then you simply do not know if rate reduction will help regarding
congestion. I think this is the reason for comment #3.

So what to do? What is the "ideal VoIP codec" (comment 2 above)?

It depends on your application space (use case).

If you are a VoIP service provider and your codec has the ability to
reduce its rate significantly (perhaps going from wideband to
narrowband), rate reduction should be a part of your ideal codec. Why?
Because your VoIP traffic is likely a majority flow in some bottleneck
link.

If you are a large VoIP user, and you know that your inelastic traffic
can - at potential bottlenecks - be a majority traffic type, rate
reduction should be a part of your ideal codec.

If you are an isolated user (perhaps an individual peer-to-peer
application) where your VoIP flow is pretty much guaranteed to be a
minority flow in a mostly elastic traffic (at any potential bottleneck
link), then rate reduction is probably not in your best interest (as the
other elastic traffic you have no control over effectively dictate your
transport performance and will consume any bandwidth reduction you
provide).

The problem is, the codec itself cannot tell - it can only observe loss.

Can we get off the topic of "ideal Internet codec" now? And move to what
we can and should implement.

Appropriate options should be a part of any codec design. We already
mentioned that we should be able to enable/disable time scale
modification. I think we should agree that appropriate rate adaption
knobs should also be provided (along with guidance on how to set them
for a particular use case).

Not to pontificate about other SDOs ... but ... defining the USE CASES
for such a codec will go a long way to designing the right knobs/options
the "Internet codec" should have. Let's stop trying to convince others
with email about what characteristics a singular "ideal VoIP codec"
should have from the perspective of a single use case. "The Internet"
ISN'T a singular use case (hopefully that should be obvious by now).

Rather, let's move to a requirements/use case analysis of what
characteristics are needed in the anticipated VoIP environments (use
cases). I would like to see a combined requirements and use case
document before we progress further - as no one use case assumption
should "win".

Off Soapbox,

Michael Ramalho

PS - If you have commentary, please respond with facts with minimal
inflammatory innuendo.

From: [email-masked] [mailto:[email-masked]] On Behalf
Of stephen botzko
Sent: Friday, July 31, 2009 6:24 AM
To: Mikael Abrahamsson
Cc: [email-masked]
Subject: Re: [codec] Codec Standardization Expertise

Saying you need a lower rate in case of congestion isn't the case
either, that won't help yourself anything because you're most likely
competing with TCP flows which will take all they can get. What you need
to do is "stand your ground" ...

I do not believe this is the prevailing view in the IETF. It is
inconsistent with the language in newer packetization RFCs, including
the language in RFC 5404.  Likewise section 2.4 of RFC 3550 clearly
implies that the appropriate adaptation to network congestion is to
reduce bandwidth use.  

Regards,
Stephen Botzko
Polycom

On Fri, Jul 31, 2009 at 1:17 AM, Mikael Abrahamsson <[email-masked]>
wrote:

We need to design something that works, and that involves creating a
codec and a transport that handles the real world, not trying to adapt
the real world to the constraints of the codec and transport. Saying you
need a lower rate in case of congestion isn't the case either, that
won't help yourself anything because you're most likely competing with
TCP flows which will take all they can get. What you need to do is
"stand your ground", perhaps go for lower sound quality but keep the
bitrate so the packets you actually get through will make sounds at the
other end that is as good as it can get during the conditions. G.719
might do this as you say, I don't know.

We need a codec and transport that when faced with adverse network
conditions will handle this gracefully and adapt its jitter buffer (if
jitter increases to 1s, it should increase its jitter buffer to handle
this, then when network conditions improve it needs to somehow lower the
jitter buffer again which means it'll have to play sound "faster" to
catch up). All this needs to work between the codec/transport layers,
and information regarding sound needs to be spread across several
packets in case of packet loss (degrade sound quality nicely), and to
retain the low end-to-end delay when network conditions are good, it
also needs to go back to the usual "all sound for these 20ms sound in
one packet"-mode for that.

So the codec and underlying transport cannot *influence* the network IP
behavior, but it needs to be able to ADAPT to it and handle it,
providing as good user experience as possible.

---

From: Daniel Petrie <[email-masked]>
Date: Fri, 31 Jul 2009 07:52:55 -0700 (PDT)

Perhaps we need a better definition of the requirements here.  I think the key point is barrier to entry.  A better definition of the requirement might be readily available implementations and royalty free.  722.1 and 722.1C may be royalty free, but there is a huge filter on the access to the code.  How may open source implementations do you know of for 722.1 and 722.1C?  Has someone out there actually gone through and successfully gotten 722.1 or 722.1C and willing to share who much time and money that it cost them just to get the codec?

I think iLBC is a fine example of the model for royalty free and readily accessable codec.

---

From: Brian West <[email-masked]>
Date: Fri, 31 Jul 2009 10:02:14 -0500

Daniel,
	I know of one such implementation of G.722.1 and G.722.1C that is  
open source and readily available.  Better yet its even been wrapped  
up in to a nice API that you can easily use it in a Multi threaded  
application.  I know pjsip has one in their SVN tree also.

http://svn.freeswitch.org/svn/freeswitch/trunk/libs/libg722_1/

http://svn.freeswitch.org/svn/freeswitch/trunk/src/mod/codecs/mod_siren/mod_siren.c

I did obtain special permission to put the code in our SVN to lower  
the burden on the users of FreeSWITCH to use this codec.  For anyone  
shipping a commercial product using this codec in binary form will  
need to acquire a license from Polycom directly as per the notice at  
the top of mod_siren.c (guess I should rename this to mod_g7221 or  
something equally descriptive now)

Thanks,
Brian

On Jul 31, 2009, at 9:52 AM, Daniel Petrie wrote:

>
> Perhaps we need a better definition of the requirements here.  I  
> think the key point is barrier to entry.  A better definition of the  
> requirement might be readily available implementations and royalty  
> free.  722.1 and 722.1C may be royalty free, but there is a huge  
> filter on the access to the code.  How may open source  
> implementations do you know of for 722.1 and 722.1C?  Has someone  
> out there actually gone through and successfully gotten 722.1 or  
> 722.1C and willing to share who much time and money that it cost  
> them just to get the codec?
>

---

From: Alexander Chemeris <[email-masked]>
Date: Fri, 31 Jul 2009 19:40:01 +0400

I should admit you're very good in manipulating facts and words
to prove your POV.

> would be quite interested (fyi, 2 samples at 16 kHz, I let you compute).

In the above statements you refer to different codecs.
One (G.722) has a small latency (but high bitrate), other (G.722.1) is
low-bandwidth,
but high latency. We need more advanced codec, sorry.

> Finally, small companies also participate to other SDOs, please give a look

What about individuals? Is is that easy as in IETF?
Where are their mailing lists? Audio translations from meetings?
How much should I pay to attend?

-- 
Regards,
Alexander Chemeris.

SIPez LLC.

---

From: Gerard Fernando <[email-masked]>
Date: Fri, 31 Jul 2009 09:08:26 -0700

RF requirements:

Herve Taddei wrote:
> BTW, you can give a look from IESG BOF report: “- understanding it 
> would not be possible to guarantee that resulting codecs would be 
> royalty free”
>
>  
>

I also feel that having the RF requirement on slides does not ensure 
such an outcome. If the WG considers this to be important then there 
should be a well defined methodology which includes the development of 
an IP (intellectual property) disclosure and review process appropriate 
to producing a royalty-free outcome.

Kind regards

Gerard Fernando

Sun Labs
Sun Microsystems, Inc.
16 Network Circle, UMPK16
Menlo Park, CA 94025
USA

---

From: Alexander Chemeris <[email-masked]>
Date: Fri, 31 Jul 2009 20:16:25 +0400

On Fri, Jul 31, 2009 at 20:08, Gerard Fernando<[email-masked]> wrote:
> I also feel that having the RF requirement on slides does not ensure such an
> outcome. If the WG considers this to be important then there should be a
> well defined methodology which includes the development of an IP
> (intellectual property) disclosure and review process appropriate to
> producing a royalty-free outcome.

Right. I just wanted to point that there is such intention. How to
achieve it is a question for further evaluation. I clearly see it's
not the easiest problem to solve, but it should be possible to solve
it.

-- 
Regards,
Alexander Chemeris.

SIPez LLC.

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 31 Jul 2009 09:17:26 -0700

With the possible exception of certain mandatory-to-implement security
technologies, there is no such thing as a Royalty-Free REQUIREMENT in the
IETF .  Some working groups strive harder to create unencumbered or
royalty-free RFC, some don¹t care overly much, but none has such a
requirement.  Please stop talking about it.
Stephan

On 7/31/09 9:08 AM, "Gerard Fernando" <[email-masked]> wrote:

>> BTW, you can give a look from IESG BOF report: ³- understanding it would not
>> be possible to guarantee that resulting codecs would be royalty free²
>>  
>>  
>>  
> 
> outcome. If the WG considers this to be important then there should be a well
> defined methodology which includes the development of an IP (intellectual
> property) disclosure and review process appropriate to producing a
> royalty-free outcome.
> 
> Kind regards
> Gerard Fernando
> Sun Labs
> Sun Microsystems, Inc.

---

From: stephen botzko <[email-masked]>
Date: Fri, 31 Jul 2009 12:24:10 -0400

Though I am getting weary on RF discussions, and *very* tired of having
every thread turn into an IPR debate, I do have one request.

It would be helpful to have clearer picture of the proposed WG process
before the next BOF.

I can envision some approaches to IPR management that could result in many
companies backing out from participation.

For example, the process might require us to study other companies' patents
in order to design work-arounds.  As Stephan Wenger noted a while ago, among
other things this can create a risk of triple-damages liability for
participants.  This could create issues for some.

Understanding / gaining rough concensus on the proposed process might make
it easier to gauge if this will be a problem or not.

Regards,
Stephen Botzko
Polycom

On Fri, Jul 31, 2009 at 12:08 PM, Gerard Fernando
<[email-masked]>wrote:

> BTW, you can give a look from IESG BOF report: “- understanding it would
> not be possible to guarantee that resulting codecs would be royalty free”
>
>
>
>
> I also feel that having the RF requirement on slides does not ensure such
> an outcome. If the WG considers this to be important then there should be a

---

From: stephen botzko <[email-masked]>
Date: Fri, 31 Jul 2009 13:00:53 -0400

In the above statements you refer to different codecs.
One (G.722) has a small latency (but high bitrate), other (G.722.1) is
low-bandwidth, but high latency. We need more advanced codec,

Though obviously latency is an important requirement for a codec
application, higher latencies do not necessarily mean that the codec is less
advanced.

I would classify G.722.1 as a moderate latency codec (40 ms).  It is
particularly suited to videoconferencing, where the video latency usually is
greater than 40 ms. Also, It is low complexity (< 5.5 WMOPS for
encoder+decoder)..  Annex C doubles the complexity, but also provides
superwideband audio (32 kHz sampling)

Regards,
Stephen Botzko
Polycom

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 31 Jul 2009 13:06:54 -0400

> is a lot of willing for RF codec(s).

In the absence of a requirements draft that has gone through the  
consensus process, slides on a viewgraph presentation are suggestions,  
nothing more. I wish that people would stop claiming consensus on this
point when it has not been called and seems clearly not to have  
developed.

Regards
Marshall

---

From: Gerard Fernando <[email-masked]>
Date: Fri, 31 Jul 2009 10:38:57 -0700

Although I appreciate that many folks might be getting "weary" of RF 
discussion it is this very issue that will determine the value of any 
standard developed by this WG. I'm still firmly of the opinion that the 
_only_ reason for the IETF to embark on codec standardization is if such 
standards were to be RF.

If the WG were to develop a process, as described below, for IPR 
management  then  that'll certainly help.

Kind regards

Sun Labs
Sun Microsystems, Inc.

stephen botzko wrote:
> Though I am getting weary on RF discussions, and _very_ tired of 
> having every thread turn into an IPR debate, I do have one request.
>
> I can envision some approaches to IPR management that could result in 
> many companies backing out from participation. 
>
> For example, the process might require us to study other companies' 
> patents in order to design work-arounds.  As Stephan Wenger noted a 
> while ago, among other things this can create a risk of triple-damages 
> liability for participants.  This could create issues for some.
>
> Understanding / gaining rough concensus on the proposed process might 
> make it easier to gauge if this will be a problem or not.
>
> Regards,
> Stephen Botzko
> Polycom
>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     RF requirements:
>
>
>     Herve Taddei wrote:
>>
>>     BTW, you can give a look from IESG BOF report: “- understanding
>>     it would not be possible to guarantee that resulting codecs would
>>     be royalty free”
>>
>>      
>>
>
>     I also feel that having the RF requirement on slides does not
>     ensure such an outcome. If the WG considers this to be important
>     then there should be a well defined methodology which includes the
>     development of an IP (intellectual property) disclosure and review
>     process appropriate to producing a royalty-free outcome.
>
>     Kind regards
>
>     Gerard Fernando
>
>     Sun Labs
>     Sun Microsystems, Inc.
>     [email-masked] <mailto:[email-masked]>

---

From: Stefan Sayer <[email-masked]>
Date: Fri, 31 Jul 2009 20:43:03 +0200

o Herve Taddei [07/31/09 16:06] in reply to Alexander Chemeris:
> What is bandwidth efficient and robust enough? Please come up with 
> values I have not seen them so far.
> 
> For example, from the list of codecs presented yesterday CELT has a 
> bitrate between 40 and 128 kbit/s, SBC has a bitrate between 50 to 350 
> kbit/s. Are those the bandwidth efficient codecs? FYI, the codecs I 
> listed have bitrates between 32 and 64 kbit/s.
CELT has good quality at 32kbit/s and I would say that for speech even 
at around 20 kbit/s it performs quite well (all at 32 kHz).

BR
Stefan

---

From: Stefan Sayer <[email-masked]>
Date: Fri, 31 Jul 2009 21:07:28 +0200

Hello,

> loss conditions (though if the network is congested, of course you need 
How much additional packet loss resilience would be possible to achieve 
from a true multiple description mode for the codec and interleaved 
packetization, where reconstruction of a lower quality signal would be 
possible in the presence of one description, or some out of a few 
descriptions?

For this to work, not only the RTP packetization has to support it so 
that the receiver understands what it is that was received, but the 
codec itself must support this mode. (I would assume that for efficiency 
reasons, this needs to be an alternate coding mode, which the sender 
could switch to if it detects, e.g. with the help of RTCP, excessive loss.)

I see that in the IP-MR RTP format it is possible to reconstruct from 
the base layer, which may be sent redundantly. How much better could 
this work if reconstruction from any combination of layers would be 
possible?

Thanks
Stefan Sayer

---

From: stephen botzko <[email-masked]>
Date: Fri, 31 Jul 2009 15:25:13 -0400

All G.719 RTP receivers are required to receive the overlap mode.  The codec
itself doesn't really have to "understand it", all you have to do is build a
non-overlapped series of frames as you de jitter (and the overlapped frames
as you packetize).  If you are running at two different rates, you can run
two encoder instances (or jointly optimize one instance to produce two
bitstreams).

I'm not an expert on the SPIRIT IP-MR codec.

Regards,
Stephen Botzko
Polycom

On Fri, Jul 31, 2009 at 3:07 PM, Stefan Sayer <[email-masked]>wrote:

>> (redundant) audio frames, and permits the duplicate frames to be at lower
>> rates.  That allows for good quality to be maintained under packet loss
>> conditions (though if the network is congested, of course you need
>>
> For this to work, not only the RTP packetization has to support it so that
> the receiver understands what it is that was received, but the codec itself
> must support this mode. (I would assume that for efficiency reasons, this
> needs to be an alternate coding mode, which the sender could switch to if it
> detects, e.g. with the help of RTCP, excessive loss.)
>
> I see that in the IP-MR RTP format it is possible to reconstruct from the
> base layer, which may be sent redundantly. How much better could this work
> if reconstruction from any combination of layers would be possible?
>
> Thanks
> Stefan Sayer
>
>

---

From: Stefan Sayer <[email-masked]>
Date: Fri, 31 Jul 2009 21:26:17 +0200

o Michael Ramalho (mramalho) [07/31/09 16:20]:
> (i.e., more TCP or SCTP than UDP) at your bottleneck link … then 
> the bottleneck link … as that congestion is primarily a function of the 
> elastic traffic. This relates to Comment 1 above.
what could have an impact in this situation is to reduce packet length 
by increasing packet rate (even if relatively more bandwidth is spent on 
header overhead). This leads to a requirement for short or controllable 
frame length ("frame size adoption knobs").

Stefan

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 31 Jul 2009 21:51:36 +0200

> liability for participants.  This could create issues for some.

Actually, I would be curious to know how the ITU-T (and other SDOs)
deals with that issue. Do companies submitting codecs to the ITU-T
completely avoid searching for patents or do they accept the
triple-damages liability?

	Jean-Marc

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 31 Jul 2009 14:08:29 -0700

Hi Jean-Marc,

To directly answer it, in all RAND SDOs (and in the IETF), the technical WGs
rarely, if ever, discuss patent rights.  That does not mean that back at
home the very same people wouldn't check on patent rights---typically under
supervision of a patent lawyer and under attorney-client privileges.  This
analysis may include both technical aspects---possible encumbrances--- as
well as business aspects (such as "friendliness" of the possible
rightholder, pre-existing licensing deals, and so on).  Back in the meeting
room, folks find more or less substantial technical arguments to derail
contributions they don't like.  I would argue that the same dynamics apply
to the IETF as well; the differences between IETF and, say, the ITU in this
field are rather subtle.

Below please find a summary of the policy aspects relevant to your question.
I apologize for the word-count.

The IETF and all other SDOs relevant in this discussion AFAIK (that are:
ITU, 3GPP and its organizational partners such as ETSI, 3GPP2 and its
organizational parts such as TIA, and ISO/IEC) have in common a requirement
to disclose patent rights that are, or may become, essential to practice a
standard.  There are subtle differences how these requirements are
formulated, and how they are exercised in practice.  For example, in some
organizations it is deemed sufficient if one were declaring one's possible
essential patent claims without further information of the patent itself.
There are also differences in the disclosure timing requirements---which are
arguably ill-defined in all mentioned organizations.  Most organizations
maintain a database of the declarations received, and most of them state
explicitly that not submitting declarations constitutes a process violation.

In addition, all of the mentioned organization *except the IETF* do require
all their members to license patent rights necessary to practice any of
their standards under RAND terms.  This serves as the main safety net for
possible righttakers.  In response to this safety net, arguably, the
disclosure practice at least in some groups of the non-IETF SDOs mentioned
above is somewhat more relaxed than what one could read out of a strict
interpretation of the policy.

In all above mentioned SDOs, when submitting a patent declaration, you have
the option (and commonly, you are required) to state, in broad terms, your
licensing policy.  In most organizations, you have the choice between
stating something like "royalty-free", "RAND", or "unwilling to license".
In the IETF, you have many more choices, including the choice of free-form.
The interpretation of a free-form licensing commitment will usually require
some experience on the legalese.  Some organizations also allow you to
provide "ex ante" information of your royalty rates.  Of course, those are
never discussed in meetings, for antitrust reasons.

The IETF does not have any form of requirement for licensing terms---not a
minimum RAND requirement, and certainly not a minimum RF requirement.  There
are good reasons for this situation, the most commonly cited one being that
the IETF does not have a membership model which could be used to bind in
(corporate) members into an obligation.  There have been cases where the
IETF standardized I-Ds knowing that patent rights may not be available under
RAND terms.  

Of the mentioned organizations, most (if not all---too lazy to double-check
all those policies) prefer unencumbered over encumbered solutions by policy.
Some, for example the ITU, do prefer encumbered, but royalty-free solutions
over royalty-bearing ones.  All give a working group the liberty to include
royalty-bearing technologies into their standards.

If you look for an SDO organizational model that supports an RF
standardization process, you would have to look at W3C, OASIS, and similar
organizations.  The have been able to maintain an RF ecosystem in their
field through a number of mechanisms, that include a very strict membership
model, a well-defined chartering process, and a conflict resolution model
for the case of discovered patent claims not available under RF terms.
Their policy is not transferable to the IETF.

Finally, some of the community-driven micro-SDOs (many of which coming from
the open source environment) have managed to keep their standards free of
known royalty-bearing IPR, by agreeing to appropriate terms after the
standard has been set, but before it was published.  There is an effort
ongoing in the Open Web Foundation to "standardize" a policy template for
those cicro-SDOs.  
The micro-SDO approach works well for a small group of people/companies with
identical goals, and sufficient community pressure to reign in those tempted
to make a quick buck---and, if you are prepared to throw away man-years of
work if your RF goal turns out to be unachievable.  However, it would not
work well with such diverse business interests as we appear to have here.
Still, their model would be the one I would have chosen if I were aligned
with an RF business model for a speech/audio codec.  However, clearly, this
model is not compatible with the IETF policy or IETF practice right now.

Regards,
Stephan