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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf