Subject: Re: CNG

From: [email-masked]
Date: Thu, 4 Nov 1999 10:45:28 -0500

I would like to make three points concerning CN:

1) Who has ever implemented the CN in a real system? Whether you completely
squelch audio
in between talk spurts or you add in an artificial static representation of
white or colored noise makes
no difference on audio quality.  CN was and is an ill-conceived notion.
Holding on to it for legacy reasons
when nobody will likely defend it use doesn't make sense.  I think that the
CN type should be redefined.
 Anyone who does use it - please respond and defend its use.

2) One of the respondants to this string indicates that the current
VAD/DTX/CNG in G.729 and G.723.1
work pretty well.  While they seem to work ok under nominal conditions,
they suffer from some flaws:
     a) The g.723.1 DTX scheme will stream SID packets when you send all
very low energy (no energy)
     Careful analysis of equation A-10 in G.723.1, Annex A will show this
to be true.
     b) Both G.729 and G.723.1 VAD algorithms were not adequately tested
with lower levels of speech
     The consequences are that an annoying "swooshing" sound occurs when
the VAD misdetects
     speech as nonspeech and codes a SID.
     c) The DTX decision logic is flawed.  Low levels of non-stationary
noise (power hum) can almost
     completely defeat the intended packet rate reduction during nonspeech
periods.
If there was to be a standard for a VAD/DTX/CNG scheme for G.711, it should
be mindful of these flaws.

3) Should there be a similar VAD for G.726 as well?  As  we begin to
understand that VoIP does not really
mean "Internet" telephony, it means Internet Protocol Telephony, we see
that people are moving away from the
low bit rate vocoders because they are not robust to ambient or non-speech
sounds, they do not transport DTMF
they degrade in speakerphone calls, and they do not tandem well at all
(conferencing). G.726 is low
complexity and half the bit rate of G.711.  No, it is not 6.4 or 8.0 kbps,
but I don't believe that people will put up
with the poor robustness of these speech coders unless they get something
for it in return (like mobility as in
digital cell phones).

Kevin Bruemmer

Stephen Casner <[email-masked]> on 11/03/99 02:39:23 PM

To:   Robert Zopf <[email-masked]>
cc:   [email-masked], [email-masked] (bcc: Kevin Bruemmer)
Subject:  Re: CNG

I thank Rob Zopt for his message on Comfort Noise Generator (CNG)
enhancements.  Let me try to provide a bit of context for the AVT
working group.

Rob contacted me as a result of the working group last call
announcement on advancing the revision of the RFC 1890 RTP Audio/Video
Profile to Draft Standard.  One of the additions in that revision is a
Comfort Noise (CN) payload format which is a simple one-octet message
specifying the noise level.  Rob asked whether changes to the comfort
noise specification would still be possible at this point, and if so,
what form that should take.

I had seen the proposal on the ITU SG16 mailing list to provide an
enhanced CNG specification which included spectral shape in addition
to level.  In an earlier reply to messages from Rob and others about
this proposal, I said that if the CN payload format/encoding as
defined in the current A/V Profile draft is not useful as it stands,
then it should be replaced with something that is useful before the
draft revision of RFC 1890 is published as a new RFC.

I agree with Rob that it would not be a good idea to add comfort noise
functions to a modified version of the PCMU/A (G.711) payload format
because that would likely impair interoperability and would require
similar revisions to other payload formats to add comfort noise to
them.

Options include:

  - Extending the current CN defintion as Rob described in his message.
    The current "energy only" specification would still be valid, but
    additional spectral information could be added.  Receivers would
    know from the payload length whether the additional info was
    present.  Does this seem like a "safe" extension that would not
    cause problems for existing implementations of CN as in the draft?
    Note that CN has not been published in an RFC, but it has been in
    the sequence of draft revisions for at least two years.

  - Leaving the existing CN as is, but adding another CNG payload
    format for the enhanced generator.  This would avoid any
    compatibility issues, and would provide an opportunity to express
    the noise energy in a different way.  However, in H.323 it would
    require negotiation of both CN and CNG payload formats for
    backward compatibility with endpoints that only implement the
    existing CN.

For either of these options, there is a question of whether it is
possible to change the comfort noise specification in the revised
profile draft, and if so, how.  The answer is certainly yes because
the working group can decide that this function should be addressed
before the draft is submitted to the IESG for IETF-wide Last Call.

On the other hand, the advancement of RTP to Draft Standard is long
overdue, so we'd like to avoid introducing additional delay.  There
may be a compromise: ask for IESG Last Call on the main RTP spec, but
hold off on the profile.  The RTP spec cannot be published as an RFC
until the profile is also ready, but my concern is that the RTP spec
is large and somewhat significant and therefore the IESG review may
take some time.  I'd like to get that process started.

A question for the ITU folks is how much time would be required to
allow the enhanced CNG proposal to be completed and tested by the
speech experts to make sure it works correctly before we standardize
it.  This notion is well accepted within IETF.

If the consensus is that a new CNG payload format should be added
(leaving the existing CN unchanged), then it would be possible for the
new payload format to be defined in a separate RFC just as we expect
the continuing development of additional payload format RFCs for new
audio and video encodings.  Perhaps we could/should add words to the
CN definition in the current draft to say that enhanced comfort noise
payload formats are in development and will be published in future
RFCs.

I'd like to discuss these questions as part of the review of the RTP
spec and profile status in the AVT meeting at IETF next Wednesday.
Rob will be attending to participate in that discussion.

                                   -- Steve

---

From: Richard V Cox <[email-masked]>
Date: Thu, 04 Nov 1999 11:49:45 -0500

Comfort Noise has been used in Circuit Multiplication Equipment for
years.  Its precise implementation is left up to vendors of the
equipment.  I believe they just supply the noise level and insert
white noise, but since this information is not public, I can only
speculate.  Listening to speech over a loudspeaker vs on a handset
is what distinguishes whether CN is needed.  In an office like
mine, with lots of fan noise from computers and AC/heating system,
I would not need CN for listening to speech on a loudspeaker
unless the background noise level at the other end was very
high.  On the other hand, I believe that on a handset I would
draw the opposite conclusion unless the background noise
was very low at the other end.
    The issue of the VADs in G.723.1 and G.729 not working
well for low level speech is immaterial as to whether CN is
needed.  If they really don't work well enough for real world
conditions, they would need to be improved.
    So, put me down as being in favor of CN generally.
        Rich Cox

---

From: Robert Zopf <[email-masked]>
Date: Thu, 04 Nov 1999 18:49:52 -0500

See my comments below.

>  Anyone who does use it - please respond and defend its use.

I too interpreted the above as CNG in general, but now from your latest 
email I understand that you mean the CN as it exists in the profile draft.

Your question then is similar to Steve's, so we now have a two part 
question that is very relevant :  Does anyone make use of the CN today as 
it is defined in the draft profile, and if so, would the proposed extension 
cause any problems ?

So far, it seems the answer to both of parts is no.

>be mindful of these flaws.

I agree that this VAD causes some artifacts.  However, I made this 
reference as a comparison for the quality of CNG that may be 
acceptable.  If the G.729 VAD/DTX operates correctly, the comfort noise 
produced by the CNG algorithm is adequate.  Remember, the proposal is for a 
means to communicate the CN information, not the VAD/DTX used.

>for it in return (like mobility as in

Again, the VAD that is used is left to the implementation.  The redefined 
CN could certainly be used with G.726 as well.

Rob.

>Rob will be attending to participate in that discussion.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Rob Zopf
Principal Engineer
Speech Technology Group
Lucent Technologies, INS

Phone 	: (732) 578-3207
Fax		: (732) 578-3213
Email		: [email-masked]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Alexander Tulai <[email-masked]>
Date: Sat, 06 Nov 1999 21:52:31 -0500

Dear colleagues,

I would like to answer a few questions related to CNG.

1) Why ONLY a noise energy level mechanism has been
so far proposed as CNG for G.711 (both ATM and IP)?

Simpler and more complex VAD and CNG algorithms have
been used for a long time, so clearly not a lack of
of knowledge in the field prevented more sophisticated
mechanism to be adopted.
a/u-law PCM coders are the most popular in the world.
The a/u-law PCM coders are very cheap and no royalties
have to be paid by the end user.
The use of sophisticated speech compression algorithms
(for example those in the ITU-T series G.72x) has been
limited to applications where bandwidth was at a high
premium. Even so , their use has been somehow limited
by the the higher cost to the end user and the
reduced capability of transporting tones (DTMF, modem,
etc.). More recent speech compression algorithms have
been adopted with their own VAD and CNG mechanism and
the ratio between the computational power required by
the coder and that required by the VAD/CNG is around 5:1
or higher.
To implement a PCM to linear decoder or a linear to
PCM coder requires around 30 cycles/frame on a popular
C5x machine. This is roughly equivalent to 0.48 MIPS
for a full Compander. Some DSPs have the capability to do
these operations in 1 cycle (for example Mitel's Miliwat
DSP core).
To implement a VAD+CNG mechanism that requires around
2 MIPS leads us to the abberation where the ratio between
the coder CPU requirements and the VAD/CNG requirements
are around 1:4 or worst!!
If someone has 2 MIPS to spare probably has 6 as well.
And if 6 MIPS are available, why wouldn't one use a toll
quality 32 kbps ADPCM algorithm with no silence supression ?
RFC 1889 not only allows ADPCM, but it allows for changing
coders on the fly to accomodate various bandwidth needs.
So, now we see that a simple VAD/CNG was used simply
because it made a lot of sense to use something on the same
degree of complexity (i.e. low) with the PCM coders.

2) Does anybody use the CN level cell/packet mechanism ?
Yes, we do.
We support the existent draft-ietf-avt-profile-new-07.txt
document and we want to see it approved as an RFC without
any delay.

3) How about a more sophisticated CN, for example one based
on noise spectral information ?
We believe there is no need for standardizing such an algorithm
neither by IETF or ITU-T.
However, if enough support for the adoption of such an algorithm
is voiced at the next ITU-T meeting in Geneva, we are prepared
to participate in the activites for defining the terms of
reference of a CNG algorithm for G.711 as well as  making proposals
for a candidate algorithm.
I would be suprised if we would see at ITU-T just two proposals.

4) How fast should the work be done ?
Well , there is no question dealing with CN for G.711 .
I believe G.711 is too important for everybody. We need
a separate question under SG16.
The ITU-T procedures for standardization are strict and well
defined. In this particular case many companies may have a high
interest in following the work and contribuing to it.
Work can be progressed through reflector groups but the
Telecommuncation community cannot be properly informed without
a general meeting in Geneva.
We want to make sure that everybody in this world using PCM coders
has a chance to take notice of the new work proposed and a chance
to contribute.

Regards,
Alexander Tulai
Mitel Corporation
Ph: (613)592-2122
Fax: (613) 592-4784
[email-masked]

---

From: Robert Zopf <[email-masked]>
Date: Mon, 08 Nov 1999 23:34:10 -0500

All,

I would like to respond to Alexander's comments below in the context of the 
proposal on the table and the application it is intended for.
Please see my comments below.

At 09:52 PM 11/06/1999 -0500, Alexander Tulai wrote:

>More recent speech compression algorithms have

 From a previous email, we have :

It is true that G.711 is very low complexity and
adding any additional processing needed in a channel
must be highly scrutinized.  However, in real-world VoIP
systems each "Channel" is actually running much more
than G.711.  In fact listed below is what typically runs
within each G.711 channel with estimates of actual DSP
complexity.

0 - 1 MIPS  -- G.711 (HW/SW)
1 - 3 MIPS  -- Fax/Modem Detect
1- 3 MIPS -- DTMF Detect/Regeneration
7 - 15 MIPS -- G.165/G.168 LEC
0.25 - 2 MIPS -- VAD/CNG
0.25 - 3 MIPS -- Packet Loss Recovery
----------------------------------------------------------
10 MIPS - 27 MIPS

Therefore, if one ELECTED to incorporate an enhanced 1 MIP CNG
over what exists today within RFC 1890 it would only take between
4% - 10% of the complexity required to run an actual G.711 Channel.

So the computational ratio is actually between 10:1 and 25:1 for the 
application that is of concern.

The second issue is why would someone use G.711 with VAD/CNG instead of G.726 ?

One must consider the application, that being a voice call over H.323 using 
an RTP/UDP/IP stack.  In this situation, the header overhead is generally 
40 bytes. Because of the overhead, the transmission rate plays a larger 
role in overall system bit-rate than the codec bit-rate.  One must also 
consider the network over which the data is sent.  Below is a table 
illustrating the effective bit rate over an ATM link (assuming 48 byte cell 
and 5 byte header for simplicity) for G.711 with/without VAD-CNG and 
G.726.  This is only one example, but it does illustrate the benefits.

Parameters : frame size = 5ms, Voice Activity Factor = 0.6 (very realistic 
for a two-way call), CNG update rate = 200ms, CNG payload size=6 bytes.

Codec   Frames/Packet           Bit-Rate (No Vad)       Bit-Rate (Vad)

G.711           1                       169600                  102608
                 2                       127200                  77168

G726            1                       169600
                 2                       84800

For 1 frame/packet, both codecs require 2 ATM cells and the effective bit 
rate is the same.  For G.711 with Vad, we see significant bit-rate 
savings.  At 2 frames/packet, G726 provides a significant saving over G711 
without Vad, but G.711 with Vad-CNG still provides a savings over G.726.

Again, this is a simplified example, but it does show the value of using a 
VAD-CNG scheme.

In conclusion, when G.711 with VAD-CNG is considered in VoIP, it can 
provide significant bit-rate savings, better quality, and lower complexity 
compared to G.726.

>document and we want to see it approved as an RFC without

The use of the proposed "enhanced" CN payload is not mandatory, and 
defaults back to the existing definition.  If desired, the use of the 
enhancement  provides additional quality with little or no extra payload 
overhead, at a fractional increase in overall complexity, and remains 
generic to be used with any codec, not just G.711.  If Mitel has an RTP 
application in mind that uses only G.711 with a super fast VAD-DTX scheme 
and uses only energy for Comfort Noise, then it is still free to do 
so.  The proposal in no way changes this.

The enhanced CN payload has many advantages over the existing CN. There is 
still the opportunity for it to be part of the RTP profile, and it should 
be considered.

>I would be suprised if we would see at ITU-T just two proposals.

We look forward to proposals from all interested parties.

>has a chance to take notice of the new work proposed and a chance

The issue was first brought up at the Q12-14/16 Rapporteur's meeting in 
Berlin in August 1999.  Here is a summary of the issue after discussion by 
the complete group of experts :

It was noted that RFC 1890 is ill-defined; it will be the second version of 
RFC 1890 that should be referred to. Its current status is pre-RFC (see 
"draft-ietf-avt-profile-new-06.ps").  It was noted that the IETF work is 
general to all sample based coders, while the proposal focused on 
G.711.  There may be a need for non-G.711 work.

It was agreed:

1) To communicate a liaison to the IETF indicating that an issue exists and 
that more work is needed.
2) To communicate our concerns to Q19.

The general goal would be to work with the RTP editors and not produce 
additional standards unless necessary.

A liaison statement was generated from this meeting and sent to Q19.  This 
liaison was considered at the Q19-21/16 Rapporteur's meeting in Geneva in 
Sept. 1999.  Here is the summary from the Q19 Rapporteur about the issue 
and what was decided by the group :

         Initiating study for CNG under DTX condition
Following the request by the Rapporteur Q.13/16, the meeting agreed to 
start study on the Comfort Noise Generator for the speech codec without 
built-in CNG such as G.711. A target of this work will be an Appendix to 
G.711 that defines the CNG function. The first step was to draft a terms of 
reference to define the CNG algorithm. The meeting formed an ad-hoc group 
with chairman of Mr. Robert Zopf (Lucent Technologies), which proposed a 
draft Performance Requirement s and Objectives in AC-99-46. With respect to 
the quality, the chairman of Q.14/12 (Mr. Mark Parkins, AT&T) kindly 
offered co-operation in defining the quality assessment method for coding 
speech under DTX/CNG operation during the interim period after the 
September meeting by correspondence.
The meeting agreed that the work should be proceeded in the correspondence 
group of chairmanship by Mr. Zopf under the meeting of Q.19/16, with help 
of Q.14/12 for quality issue.  The correspondence group should continue 
following works:
(1)     Complete the Performance Requirement s and Objectives
(2)     Draft preliminary test methodology and ask Q.14/12 for comments
(3)     Complete the Test Methodology
(4)     Collect candidate algorithms for CNG
(5)     Performance assessment for the candidates
(6)     Select a candidate and define the algorithm (Draft Appendix to G.711) .

The time schedule should be established as a part of Terms of Reference 
taking into account that the Appendix is strongly desired by WP2/16 and 
IETF as soon as possible. Expectation for the Appendix may be approval at 
the next SG16 meeting in February 2000.

The issue has been properly addressed within the ITU, and the work is 
following the path laid out at the meeting by the Q19 Rapporteur and the 
WP3 Chairman.

I am sorry to everyone for the long email.  I hope that the work can now 
progress in a timely fashion.

Best Regards,

Rob.