Re: [codec] WG Review: Internet Wideband Audio Codec (codec)

["Christian Hoene" <[e-mail]>]

Dear Xavior Marjou,

> We fully share the points 1) and 2) stated in the e-mail below from
> Cullen since implementing and deploying a new codec in networks
> (gateways, service plate-forms, mediaservers...) and in terminals
> represents high costs for service providers, manufacturers and chipset
> providers in terms of development, deployment and testing with risks
> to create bugs and problems affecting customers. Furthermore, this
> multiplies the problems of interoperability with already deployed
> codecs and the transcoding needs to be addressed with related costs
> (gateways) and quality degradations.

I have heard similar concerns from German traditional telcos, too. However,
the currently envisioned codec is based on a more Internet like scenario: a
dumb network and smart end terminal. This means: fewer gateways and less
transcoding inside the network but smarter end terminals (=phones). Also,
the codec is intended to be used in an end-to-end fashion with the encoding
and decoding done at the Internet phones. 

If a phone needs to communicate with a gateway, it can use G.729 or G.711.
Thus, I do not see an immediate need to enhance gateways to support the new
codec nor any costs involved with that. Similar, phones must not be updated
if the old small or wideband quality is sufficient. 

Every new technology comes with bugs and problems at the beginning. But the
new codec will have new features and better quality (e.g. playing music and
listening to music, higher reliability because of rate adaptation, etc.),
which will attract customers. Thus, one should bear the costs to deploy it;
otherwise a provider will lose its market share.

> Therefore, the 3 stages mentionned are essential to be run
> sequentially:
> "(1) get consensus on the requirements, (2) see if an existing codec
> meets the requirements, and (3) specify a new codec only if none are
> found in stage 2. Initially the WG would be chartered for (1) and when
> that was done it would be re-charted for (2) and so on. "

Obviously, the current requirements document does contain features which are
not supported by today's standardized codecs. As an example, take time
stretching and time compression. Thus, everybody following the discussion
must come to the conclusion that (2) has been answered with no. 

> Requirements established first in stage 1 shall be sent for stage 2 to
> other SDOs as stated in the current version of the Charter:
> 
> " The working group will communicate detailed description of the
> requirements and goals to other SDOs including the ITU-T, 3GPP, and
> MPEG to help determine if existing codecs meet the requirements
> "(however in the current version of the Charter, it is inconsistent to
> state first that the goal of the WG is to develop of a new codec and
> to state some lines after that existing codecs will be considered...)
> 
> Based on the answers collected from these SDOs, conclusion for stage 2
> shall be delivered and constitute the input and prerequisit for any
> decision to continue in stage 3 to produce a new codec and re-Charter
> the Group for this

Your changes look like an attempt to slow down and hinder the work. As
Monty, I have to object your arguments.

With best regards,

 Christian