Subject: CNG

From: Robert Zopf <[email-masked]>
Date: Wed, 03 Nov 1999 11:29:29 -0500

Dear Colleagues,

The main concerns regarding a new CNG scheme have been the following:
* the creation of a variant of G.711 would reduce the interoperability of 
different implementations, both within H.323 and within other applications.
* a CNG scheme that remains generic for use with any codec would be more 
useful than if it is specific to G.711.
* the implications of breaking the existing CNG mechanism and proposing a 
new one should be carefully considered before moving forward.
* defining a CNG scheme may in some way limit the flexibility of the design 
of VAD/DTX systems that it would operate with.
* due ITU procedures should be in place and enough time should be given for 
interested parties to advance their proposals.
* the IETF is currently advancing the draft RTP Profile to Draft Standard 
at the meeting next week in Washington, DC.

The main objective of this CNG work proposed by Lucent is to define a means 
for H.323 to provide an acceptable level of quality using Comfort Noise in 
an interoperable fashion for codecs (especially G.711) without built-in 
CNG.  In VoIP, the 3 main codecs being deployed are G.711, G.723.1, and 
G.729A.  For sessions using G.723.1, or G.729A, the built-in CNG provides 
an acceptable level of quality during DTX operation.  However, for G.711, 
there is no built-in CNG, and the mechanism within RTP must be used to 
signal DTX and describe the background noise.  In this case, currently only 
the energy is available, and as a result, a predictable, reliable, 
acceptable level of quality across different background noise conditions is 
not possible, especially between different vendors equipment.  Of course 
this problem also exists for other codecs without built-in CNG, such as 
G.722, G.726, G.727, G.728, etc.

In light of all  of the above, our proposal is to define an extension to 
the current "energy only" scheme.  This extended definition may be used to 
further describe the background noise.  However, it's full or partial use 
is up to the implementation.  The first byte would represent the energy in 
exactly the same manner it is now in RTP.  The presence of additional bytes 
would signal additional information, the meaning of which and decoding of 
its parameters we would define.  Ideally, this additional information would 
not be codec or sampling rate specific so that the scheme could continue to 
be used as flexibly as it is now.  The current method of signalling DTX and 
updating the CN information would remain the same as it is now (that is, 
the first CN packet identifies the start of the inactive segment, and the 
update rate of this information after this is implementation specific).

Interested parties would propose bit-stream formats (and part of this would 
be to define how to properly encode/decode the bit-stream to and from the 
parameter set), and a "preferred" means of analysis and synthesis.  This 
preferred means would be tested against the requirements set out in the ToR 
to verify that at least one implementation exists that meets the ToR.  We 
will obtain guidance from SG12 on how to best test the CNG.  Based on the 
results, the working party group would select the best candidate, and the 
bit-stream format and preferred implementation would make up an appendix 
that could be referenced for use in protocols such as RTP.  Ideally, the 
Audio/Video Transport Working Group of the IETF could adopt the 
"extended"  CN in the future.

Please provide any comments by the end of the week.  If this is an 
acceptable means of moving forward, we will send out a draft ToR reflecting 
this approach.

Best Regards,

Rob.

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

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

---

From: Robert Wood <[email-masked]>
Date: Wed, 03 Nov 1999 12:08:58 -0500

Colleagues,

 	The beauty of the G.711 is that almost no processing
	is required and packetization delay can be minimized 
	if desired. 

	My issue with any further complication of VAD/CNG
	operation in G.711 is the increased complexity 
	required to implement.

mailto:[email-masked]

---

From: Gerard Aguilar <[email-masked]>
Date: Wed, 03 Nov 1999 13:07:56 -0500

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.

Gerard

---

From: Stephen Casner <[email-masked]>
Date: Wed, 3 Nov 1999 11:39:23 -0800 (Pacific Standard Time)

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: Stephen Casner <[email-masked]>
Date: Wed, 3 Nov 1999 11:49:09 -0800 (Pacific Standard Time)

> 	operation in G.711 is the increased complexity 

Note that the "MBone tools" vat and RAT have implemented PCMU (G.711)
encoding for a long time without any comfort noise mechanism at all.
Silence suppression is still possible -- the receiver does not require
an indicator at the start of silence, it just runs out of data.

With the definition of the CN payload format or an enhanced CNG
payload format, it is still possible for simple systems to just
process the PCMU payload format packets and ignore the CN packets if
that level of performance is acceptable.  This high level of
interoperability is an advantage of keeping the existing audio
encoding payload formats separate from CN.

> 4% - 10% of the complexity required to run an actual G.711 Channel.

Please note that RFC 1890 did not define any comfort noise scheme,
only the simple silence suppression I described above.

							-- Steve

---

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

>it.  This notion is well accepted within IETF.

The target is to have an appendix in February, but the schedule needs to be 
worked out.  It may take longer.

Rob.