Subject: [MMUSIC] Silence Suppression Attribute

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 2 Apr 2002 16:10:41 -0500

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

Tom Taylor
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)

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

---

From: "Dan Firac" <[email-masked]>
Date: Wed, 3 Apr 2002 09:50:21 +0300

It's a very good ideea.
Anyway, why this attribute was defined for ATM transport type only?
Silence suppression, as you pointed below, is an attribute of a codec
and has nothing to do with transport.

Dan Firac,
Software Engineer,
RedlineCommunications,
Romania.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 03 Apr 2002 18:22:32 -0500

What would be the scenario where the new attribute is used? 
Colin

---

From: "Dan Firac" <[email-masked]>
Date: Thu, 4 Apr 2002 10:37:03 +0300

It's about user preferences.

Scenario:
If the user prefers to DISABLE Silence Suppresion in order to acheive higher
audio quality, then the SDP composed by its phone should express this wish.

Further pros:
1) Silence suppression it's a PARAMETER for many codecs, and
I think it should be present in SDP offers/answers.
2) When the remote end is not well tuned (ex: volumes), the VAD on the
remote end may
brutally cut the speech, so our local user will not know/feel if there were
loses or
the remote user stopped speaking.
3) The same thing happens when the local user has G723 without AnnexA (VAD),
G729 without AnnexB, and would want to force the remote end to use
a codec without silence suppression.

Points 2) and 3) are about gaining some quality.

You are right, RTP assumes silence suppression and all the scenarios
(including the above scenarios) are working without negotiating Silence
Suppression.
But is the obtained quality the best quality that can be acheived?????

I think the user should decide it and the SDP should offer him
a mechanism (at least, optional) to express his preferences.

Best regards,
Dan Firac,
Software Engineer,
RedlineCommunications,
Romania.

----- Original Message -----
From: "Colin Perkins" <[email-masked]>
To: "Dan Firac" <[email-masked]>
Cc: "Tom-PT Taylor" <[email-masked]>; <[email-masked]>
Sent: Thursday, April 04, 2002 2:22 AM
Subject: Re: [MMUSIC] Silence Suppression Attribute

> >> The issue of how to signal silence suppression capability keeps coming
up
> >on

---

From: Colin Perkins <[email-masked]>
Date: Fri, 05 Apr 2002 12:44:54 -0500

Dan,

I think Steve's email mostly answers this. If the codec has parameters to
determine how the silence suppression works, these need to be specified as
part of the payload format.

For just signalling the preference that that suppression not be performed
(and clearly this can only be a preference), a "generic format parameters"
is probably the best way to proceed, rather than a specific attribute for
silence suppression.

Colin

---

From: "Rajesh Kumar" <[email-masked]>
Date: Sun, 7 Apr 2002 22:06:00 -0700

Please comment on
http://search.ietf.org/internet-drafts/draft-rajeshkumar-mmusic-gfmtp-00.txt
. This might fit the "generic format parameters" Colin mentioned.

Rajesh Kumar
Cisco Systems

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Colin Perkins
> Sent: Friday, April 05, 2002 9:45 AM
> To: Dan Firac
> Cc: [email-masked]
> >> >> 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
> >> >> How would people feel about allowing the a=silenceSupp
> parameter to be
> >> >used

---

From: "Dan Firac" <[email-masked]>
Date: Mon, 8 Apr 2002 10:55:37 +0300

Silence suppression can fit "generic format paramters".

As long as nothing is standardized i would like to express my opinions
about this solution.
1) It's very probable that the user would NOT set different values
for the silence suppression attribute of each codec. So, this value
can be transmitted only once as an attibute of media level.
2) (for rajesh) I think inserting 'ecan' in your parameter list is not
a wise thing to do. Because the echo cancelation is NOT a
codec parameter (you won't find the echo cancelation block as
an codec integrated part, but as a separate one !!!). As far as I
know the echo cancelation block operates (at receiver) AFTER
the codec. So, I think 'ecan' may be moved to media level.

Given the above opinions and the fact that the 'gftmp' parameter
values would not differ from codec to codec, I think the 'gfmtp'
can be moved to media level, and any particular parameters
for a certain codec should be expressed with 'ftmp' (This is
the definition o 'fmtp': format SPECIFIC parameters).
Here is a little inconsistency: the above implies
that 'fmtp' include 'gftmp', but these are only sugestions.

Please consider all above as personal opinions,
Dan Firac,
Software Engineer
Redline Communications,
Romania.

----- Original Message -----
From: "Colin Perkins" <[email-masked]>
To: "Dan Firac" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, April 05, 2002 8:44 PM
Subject: Re: [MMUSIC] Silence Suppression Attribute

parameter
> >as
> >> >> defined in draft-ietf-avt-rtp-mime-06.txt.  That draft is specific
to
> >> >> How would people feel about allowing the a=silenceSupp parameter to
be

---

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

Dan,

Regarding your comment on
http://search.ietf.org/internet-drafts/draft-rajeshkumar-mmusic-gfmtp-00.txt

> the codec. So, I think 'ecan' may be moved to media level.

The list of parameters is not complete, nor is it intended to be. Further,
it is for exemplary purposed only.

However, let us look at ECAN further. H.248 and MGCP do allow ECAN to be
indicated per connection, why should SIP offer/answer be precluded from
doing so?  Further, H.248 would use SDP/tags for the MGC to enable/disable
ECAN per connection, since it does not have the equivalent of the  local
connection option in MGCP.

However, your statement that ECAN is not codec-specific is quite right.
Maybe, you need a media-level parameter such as a=ecan, of the kind that you
have in rfc3108.

> values would not differ from codec to codec,

For the 'vbd' parameter, they would. We do need it to be at the codec level.

>I think the 'gfmtp'

'fmtp' refers to those format specific parameters that are part of the MIME
definition. 'gfmtp' refers to those that are not an integral part of the
MIME definition, but can be applied selectively (and optionally) to codecs
at the time of call establishment.

What does the team think?

Rajesh Kumar

---

From: Christian Groves <[email-masked]>
Date: Tue, 09 Apr 2002 13:33:41 +1000

Hello Rajesh,

One of your statements confuses me:
..snip..
> connection option in MGCP.
H.248/Megaco has a package property to indicate Echo Cancellation. This is
listed in the Local Control descriptor not under local and remote. So for H.248
the MGC does not use SDP for Echo cancellation.

Regards, Christian

---

From: "Rajesh Kumar" <[email-masked]>
Date: Tue, 9 Apr 2002 09:43:23 -0700

G'Day Christian,

You are right. However, the need to optionally indicate ECAN remains. In SIP
offer/answer, this will be through SDP, right?  - since there is no other
mechanism. The point I'm making is that ECAN is a valid parameter to
indicate at call/connection/session establishment time. Dan's point that
this is not codec-related is well-taken; perhaps, there is a need for a
media level "a=ecan..." for the VoIP. This exists for VoATM in rfc3108.

Rajesh

> Christian Groves
> Sent: Monday, April 08, 2002 8:34 PM
> To: [email-masked]
> Cc: Dan Firac; Colin Perkins; [email-masked]; [email-masked]
> Subject: Re: [AVT] RE: [MMUSIC] Silence Suppression Attribute
>
>
> Hello Rajesh,
>

---

From: Colin Perkins <[email-masked]>
Date: Thu, 11 Apr 2002 17:03:09 -0400

Rajesh,

I think this is a good start, but it needs a definition of the type of
parameter that can be included in the new attribute (and, depending on
the definition, a more appropriate name for the attribute).

You have two examples: one affects the operation of the playout buffer,
the other affects part of the terminal outside the realm of RTP or the
packet network. I'm not sure it's appropriate to have such different
parameters signalled in a single attribute, but without a definition of 
the attribute, it's difficult to tell what is appropriate.

I also think the discussion of RFC 2198 should not be in this draft.

Colin

---

From: "Rajesh Kumar" <[email-masked]>
Date: Thu, 11 Apr 2002 16:21:00 -0700

> the definition, a more appropriate name for the attribute).

How about the following: Parameters which are meant to qualify specific
payload types, but are not part of the MIME definition. These parameters
would be defined generically i.e. not within a MIME definition. However,
they would be applied to individual payload types, and not the media stream
per se. These parameters would, of necessity, be optional and would provide
value-adds in processing the formats (such as playout buffer optimization).
By definition, they cannot be made mandatory. All mandatory parameters must
be part of the MIME definition.

Is there a problem with this definition? If so, then can the team help me
refine it?

It does provide a definite value add in the voiceband data case. It would be
nice to have a standard, interoperable way of conveying this.

> the attribute, it's difficult to tell what is appropriate.

Per the definition above, the VBD flag would certainly be appropriate. The
ECAN should be dropped since this should apply to the media stream as
opposed to individual payload types. I do not know any other parameter that
needs to be conveyed in this manner. Does anyone else? My original
presentation was limited to VBD. However, there was a suggestion at the
Minneapolis meeting that there might be a need for a broader construct.

> I also think the discussion of RFC 2198 should not be in this draft.

Right. RFC 2198 applies to all RTP formats, and there is no need to state it
here.

Rajesh