Subject: [Megaco] Re: [MMUSIC] Silence Suppression Attribute

From: Stephen Casner <[email-masked]>
Date: Wed, 3 Apr 2002 18:05:44 -0800 (PST)

This reply is both to this thread in MMUSIC and to one from the Megaco
list titled "Local/Remote descriptors and Permanent terminations" that
Tom cc'd to me.

On Tue, 2 Apr 2002, Tom-PT Taylor wrote:

> The issue of how to signal silence suppression capability keeps coming up on
> the Megaco list.  The situation is fairly complicated:
>  - some codecs come with a pre-defined capability for silence suppression.
> This capability can be invoked by the appropriate MIME type parameter as
> defined in draft-ietf-avt-rtp-mime-06.txt.  That draft is specific to RTP
> transport, arguably over UDP only.
>  - other codecs like G.711 have no such parameter, yet silence suppression
> is possible

As Colin said, for all RTP audio codecs, silence suppression is
assumed to be enabled.  Therefore, we clearly do not need an attribute
to enable silence suppression.  We may or may not need some attribute
to disable silence suppression, but I don't know what scenario
requires that.

A related discussion occurred on the AVT list in November, 2001, with
the subject line "Reg draft-ietf-avt-rtp-mime-05.txt".  At that time,
the sense I got was that some implementations could not handle
receiving an RTP stream with silence suppressed.  My reaction to that
was pretty strong:

    Silence suppression has been a fundamental part of RTP since the
    beginning.  That is why the RTP header carries both a sequence
    number and a timestamp.  Suppressing silence is one of the primary
    reasons for going to packet transmission of voice in the first
    place.  Furthermore, even if the transmitter does not suppress
    silence, the receiver must be prepared to handle the situation
    where there is a frame time for which no packet is present because
    packets may be lost.  Any implementation that has not been
    sufficiently developed to recover reasonably to such a situation
    should be flatly rejected.

Can you explain a situation that is a valid justification for
disabling silence suppression?

>  - RFC 3108 defined an a=silenceSupp attribute, but it applies to ATM
> transport only.
>
> How would people feel about allowing the a=silenceSupp parameter to be used
> independently of the transport type?

It may have been a mistake to include the a=silenceSupp attribute for
ATM without considering the problem more generally.  I suspect that
RFC 3108 did not get much attention in MMUSIC because many of the
participants don't care much about ATM.

On Wed, 3 Apr 2002, Tom-PT Taylor wrote:

> To summarize: we are trying to define how to indicate that silence
> suppression is desired for a given audio flow.

More specifically, to indicate when silence suppression is NOT desired.

>  We could do it through an
> a=silenceSupp attribute, through codec-specific a=fmtp: parameters, or
> implicitly by specifying the Comfort Noise codec as an alternative.

We can't add fmtp parameters to an existing payload format after the
fact without incurring backwards compatibility problems.

It is reasonable to interpret the inclusion of the Comfort Noise codec
as a desire or willingness to suppress silence.  However, it is NOT
reasonable to interpret the omission of the Comfort Noise codec as an
indication that silence will not be suppressed.

> I think it's quite clear that we do NOT want to tie silence suppression to
> the TDM package.

What are the requirements for enabling or disabling silence suppression
when using TDM?  What does silence suppression mean when using TDM?

> The cleanest way would be to ensure that every codec where silence
> suppression might apply has a silence suppression parameter.  For RTP, this
> requires revisiting draft-ietf-avt-rtp-mime-06.txt, which is currently in
> IETF Last Call.

As I said above, adding such a parameter would create backwards
compatibility problems.  It's not just a matter of definition.  The
parameters belong to the payload format specification, not to the MIME
registration.

>  Not sure what we do about ATM: RFC 3108 defines a profile
> that just picks up the RTP mappings, so maybe it would also pick up the
> parameters defined in the MIME type registrations and payload format
> descriptions.  I find this whole area murky because theoretically there
> should be new MIME type registrations for each transport in order to reuse
> the profiles in SDP.

It should only be necessary to revise the MIME registrations for a new
transport if additional parameters, encoding considerations, etc, need
to be defined for that new transport.  Many of the MIME registrations
for RTP encodings only cover RTP transport and not email/http
transport because no file format has been defined for those encodings.

> A second possibility is to define the a=silenceSupp attribute for all
> transports, but specify that it takes second priority to a=fmtp parameters
> where these are defined.  This is probably the most practical route.

At MMUSIC in Minneapolis, the need for a "generic format parameters"
attribute was discussed, triggered by the need for a particular
payload type number to indicate the presence of voiceband data.

This would serve (at least at a syntactical level) as a place to put a
"please do not suppress silence" parameter, but since it is ignorable,
it would not guarantee that silence would not be suppressed.  As I
pointed out above, UDP does not guarantee to deliver a packet for
every frame time in any case.

							-- Steve

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Stephen Casner <[email-masked]>
Date: Wed, 3 Apr 2002 18:05:44 -0800 (PST)

-- Steve

---

From: "Rajesh Kumar" <[email-masked]>
Date: Mon, 8 Apr 2002 18:01:42 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Stephen Casner
> Sent: Wednesday, April 03, 2002 6:06 PM
> To: Tom-PT Taylor
> Cc: [email-masked]; [email-masked]
> Subject: Re: [MMUSIC] Silence Suppression Attribute

<snip>

> participants don't care much about ATM.

Steve,
A little bit of history on why there is a silence suppression attribute for
ATM in RFC3108. Let us look at AAL2 first, and then at AAL1.

If you look at the AAL2 profiles in ITU I.366.2, it is possible to support
PCM or ADPCM without silence suppression. Supporting silence suppression is
not mandatory for all AAL2 connections along the lines of the "strong
requirement" you quoted for silence suppression in the RTP context.

Why would I.366.2 make it optional for AAL2, and not mandatory as you made
it for RTP? Here is a possible justification: The optional nature of silence
suppression might be taken advantage of to reduce DSP costs. PCM without
silence suppression does not need a DSP, ADPCM without silence suppression
can be implemented in a non-DSP hardwired processor.

Now, moving from AAL2 to AAL1: it goes without saying that silence
suppression is completely optional in the AAL1 context. It is rarely used
with PCMU/PCMA on AAL1, however, there is nothing to preclude its use
(except there exists no SID mechanism for AAL1, as there exists for AAL2).

Does the inclusion of this attribute in the ATM context seem more reasonable
in this light now?

Rajesh

---

From: "Rajesh Kumar" <[email-masked]>
Date: Mon, 8 Apr 2002 18:01:42 -0700

<snip>

Steve,

Rajesh