Subject: Re: CNG

From: [email-masked]
Date: Thu, 4 Nov 1999 14:50:11 -0500

Richard:

Perhaps I didn't do a good enough job in the first part of my email.  The
"CN" type, as it exists in RTP/RTCP is ill-conceived - not the notion of
comfort noise.
As far as DCME, you are perhaps more aware of how much this equipment is
used anymore; my impression is that it is not.  And - since the
implementations are proprietary and each end of the equipment is designed
by the same people, the notion of specifying it in a standard, doesn't
apply.

Kevin

Richard V Cox <[email-masked]> on 11/04/99 11:49:45 AM

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

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

[email-masked] wrote:

> 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