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

[Stephen Casner <casner@packetdesign.com>]

Replies two both responses, inline...

On Tue, 7 Jan 2003, Henning Schulzrinne wrote:

> >    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
>
> 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.

> >    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
>
> 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.


On Tue, 7 Jan 2003, Jonathan Rosenberg wrote:

> >    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.
>
> Since silence suppression is just the absence of packets, its not clear
> what it means to "accept" it.

Right.

> > (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.)
>
> 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.

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!

> 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.

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.)

> >    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.
>
> 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.

> > 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.
>
> 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.

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

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt