Subject: [AVT] Profile: Silence suppression is allowed by default

From: Stephen Casner <[email-masked]>
Date: Tue, 7 Jan 2003 16:51:02 -0800 (PST)

Over the past year we have had a few discussions on the AVT list
regarding silence suppression and comfort noise for various payload
formats.  Sharma Kanchinadham and Anoop Tripathi asked (separately)
for the optional MIME parameters for G723 and G729 audio to be changed
such that the default for "allow comfort noise frames" was NO.  Sharma
also asked for a similar parameter to be added for PCMU to indicate
whether silence suppression was allowed, and for the default to be NO.

I explained that we could not make these changes because silence
suppression has always been an assumed capability for all of the audio
encodings.  It's one of the fundamental reasons for using packets to
carry voice in the first place.  Changing the default now would create
a backwards incompatibility.  Furthermore, a receiver must always be
prepared to recover gracefully when it receives no data because
packets may be lost.

To make this more explicit, I added the following paragraphs at the
beginning of Section 4.1 in the A/V profile:

   Since the ability to suppress silence is one of the primary
   motivations for using packets to transmit voice, the RTP header
   carries both a sequence number and a timestamp to allow a receiver to
   distinguish between lost packets and periods of time when no data was
   transmitted.  Discontiguous transmission (silence suppression) MAY be
   used with any audio payload format.  Receivers MUST accept silence
   suppression unless its use is restricted by signaling specified
   elsewhere.  (Even if the transmitter does not suppress silence, the
   receiver must be prepared to handle periods when no data is present
   since packets may be lost.)

   Some payload formats define a "silence insertion descriptor" or
   "comfort noise" frame to specify parameters for artificial noise that
   may be generated during a period of silence to approximate the
   background noise at the source.  For other payload formats, a generic
   Comfort Noise (CN) payload format is specified in RFC 3389 [9].  When
   the CN payload format is used with another payload format, different
   values in the RTP payload type field distinguish comfort-noise
   packets from those of the selected payload format.

In addition, I added the following first sentence in the four places
where the sentences similar to the second one appear in G723 and G729*:

   Receivers MUST accept comfort noise frames if restriction of their
   use has not been signaled.  The MIME registration for G729 in
   RFC YYYY [7] specifies a parameter that MAY be used with MIME or SDP
   to restrict the use of comfort noise frames.

Are these acceptable?

                                                        -- Steve

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 07 Jan 2003 23:03:14 -0500

I think this addition is great. I have seen this issue come up all the 
time. Some comments on the wording inline:

Stephen Casner wrote:

>    elsewhere.  

Since silence suppression is just the absence of packets, its not clear 
what it means to "accept" it.

> (Even if the transmitter does not suppress silence, the

This sentence and the previous appear contradictory to me. The previous 
says that you won't need to handle silence suppression if signaling says 
its not in use, but this sentence says you need it anyway.

I would propose the last two sentences be replaced with:

Receivers MUST be prepared to handle the absence of packets for an 
arbitrary period of time in order to accomodate silence suppression at 
the sender. This applies even if silence suppression is not in use 
(which can be known to the receiver through signaling, outside the scope 
of this specification), because packet loss cannot be distinguished from 
silence suppression.

>    packets from those of the selected payload format.

I assume [9] is an informative reference, not normative.

>    to restrict the use of comfort noise frames.

Presumably RFC YYYY [7] will be at proposed. The above text seems to me 
to provide a normative reference to that specification. A draft standard 
cannot have a normative reference to a proposed standard.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Colin Perkins <[email-masked]>
Date: Wed, 08 Jan 2003 09:41:06 -0500

>of this specification), because packet loss cannot be distinguished from 

This is not accurate either, since you can distinguish loss from silence
suppression using the sequence number. We could change the last few words
to "because packet loss may cause arbitrary gaps in reception", or similar?

Colin

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 08 Jan 2003 15:11:02 -0500

Works for me. Good clarification.

>    to restrict the use of comfort noise frames.

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 08 Jan 2003 17:43:30 -0500

inline.

> suppression using the sequence number. 

Not until the point at which you get that next packet. But at that 
point, yes, you are correct.

We could change the last few words
> to "because packet loss may cause arbitrary gaps in reception", or similar?

How about, "because packet loss may cause arbitrary gaps in reception 
which cannot be distinguished from silence suppression until the arrival 
of the next packet."

-Jonathan R.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 08 Jan 2003 17:47:22 -0500

>which cannot be distinguished from silence suppression until the arrival 

Works for me.

Colin

---

From: Stephen Casner <[email-masked]>
Date: Thu, 9 Jan 2003 00:13:38 -0800 (PST)

Replies two both responses, inline...

On Tue, 7 Jan 2003, Henning Schulzrinne wrote:

> I'm not sure what 'accept silence suppression' means, precisely. I would
> say something more concrete and general, as in

You and Jonathan are right that "accept" is not the best word.

> MUST deal gracefully with gaps in the timestamp sequence, i.e., periods
> for which no audio data is available, due to sender silence suppression
> or lost packets.

I don't think we can dictate grace, though.

> Do any in the current profile? If not, may add a half-sentence to
> prevent hunting...

Yes, G.723 and G.729.  I'll add the half-sentence.

> what it means to "accept" it.

Right.

> its not in use, but this sentence says you need it anyway.

Well, I don't see them as contradictory; the second is more of a warning
that even if you come up with some signaling to disallow silence
suppression, it's not going to do you any good because packets might be
lost, so you might as well not bother.  And that's why we made the
default be that silence suppression is allowed.  So there!

> of this specification), because packet loss cannot be distinguished from

Sorry, I don't really like this approach because it conflicts with
what I said in the first sentence.  Here's how I would like to revise
the paragraph:

    Since the ability to suppress silence is one of the primary
    motivations for using packets to transmit voice, the RTP header
    carries both a sequence number and a timestamp to allow a receiver
    to distinguish between lost packets and periods of time when no data
    was transmitted.  Discontiguous transmission (silence suppression)
    MAY be used with any audio payload format.  Receivers MUST assume
    that senders may suppress silence unless its use is restricted by
    signaling specified elsewhere.  (Even if the transmitter does not
    suppress silence, the receiver must be prepared to handle periods
    when no data is present since packets may be lost.)

> I assume [9] is an informative reference, not normative.

Yes.  You'll be able to tell by its position in the references
section. :-)  This is the same as for all the other payload format RFCs
that are referenced.  I address this in the Introduction section:

   This document also defines a set of encodings and payload formats for
   audio and video.  These payload format descriptions are included here
   only as a matter of convenience since they are too small to warrant
   separate documents.  Use of these payload formats is NOT REQUIRED to
   use this profile.  Only the binding of some of the payload formats to
   static payload type numbers in Tables 4 and 5 is normative.

Since the profile has been approved, the IESG must have agreed with this
assessment.

> cannot have a normative reference to a proposed standard.

Indeed, the reason we put the MIME definitions into the separate RFC was
to allow the profile to go to Draft Standard while the MIME definitions
were new material at Proposed.  The idea is that the use of MIME or SDP
is not required (you can use any other method of signaling instead),
therefore the reference is not normative.  Again, the second sentence is
in the document as already approved.

                                                        -- Steve

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 09 Jan 2003 17:12:24 -0500

>     when no data is present since packets may be lost.)

OK.

-Jonathan R.