Subject: RE: silence suppression in SDP

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 30 Nov 2000 03:21:07 -0500

I believe the reason this is absent from SDP is the origins of SDP as an
mbone session description. In the mbone, with large conferences, silence
suppression was a given; you cannot have multi-party conferences with
hundreds of people if all the listeners were always sending dead silence. As
a result, it didn't need to be signaled since it was mandatory to support.

Its unfortunate, I guess, that we have many implementations of systems today
that don't do silence suppression (or at least can't handle receiving no
data and treating it as silence). Sad as that may be, I suppose since they
exist we need to support the ability to indicate receipt of silence or not.

I looked at the silence suppression support in draft-ietf-mmusic-sdp-atm,
and think it is overkill. I fail to understand why most of that information
needs to be conveyed at all. I prefer a simpler approach. Silence can be
conveyed in actual RTP packets; indeed, there is an RTP payload format for
comfort noise. As such, this is handled by listing the comfort noise payload
type on the m line. Basically, we can also consider 'no RTP' as another
payload type, and list it as well. Thus:

m=audio 3048 RTP/AVP 0 89
a=rtpmap:89 silence

This indicates I can receive PCMU and silence. In fact, payload type 89
would never be sent at all. But, it provides the same structure as the case
where a real comfort codec was being used:

m=audio 3048 RTP/AVP 0 89
a=rtpmap:89 CN

-Jonathan R.

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

> -----Original Message-----
> From: Terry L Anderson [mailto:[email-masked]]
> Sent: Wednesday, November 22, 2000 3:06 PM
> To: mmusic
> Subject: silence suppression in SDP
> 
> 
> We are working on implementations of H.248 (MEGACO) and one need is to
> control silence suppression on RTP connnections for some 
> codecs.  H.245
> carries this along with other media parameters during media channel
> negotiation.  It would seem that H.248
> (text mode) and SIP that use SDP for media channel 
> specifications would
> need the same feature, but RFC 2327 for SDP does not have such a
> parameter.
> 
> draft-ietf-mmusic-sdp-atm-02.txt introduces such a feature for ATM
> bearer connections but there appears to be no such feature for RTP
> bearer connections.
> 
> Am I missing something?  Has this been discussed in the past? 
>  Is there
> another way this should be done or is it common belief that 
> this should
> be outside SDP?
> 
> I notice that there is a new I-D on SDP.  I assume that this indicates
> the beginning of work on a new version.  Would it be 
> appropriate to add
> support for silence suppression similar to the sdp-atm 
> specification to
> the new SDP?
> 
> 
> --
> ------------------------------------------------------------
> Terry L Anderson              mailto:[email-masked]
> Tel:908.582.7013   Fax:908.582.6729
> Pager:800.759.8352 pin 1704572   [email-masked]
> Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp
> Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
> 
>

---

From: Terry L Anderson <[email-masked]>
Date: Mon, 11 Dec 2000 13:43:12 -0500

Jonathan -

Thanks for your reply.  I didn't respond immediately because I had to do a
little research, but I think that there are several reasons the method you
suggest does not solve the complete problem.

Some codecs (e.g., G.723.1 Annex A) have an option to support silence
suppression.  So one must indicate whether you support the option.  I suppose
that one could define different payload types for G.723.1 with silence
suppression and G.723.1 without silence suppression, but it is really NOT an
additional payload type when included as a codec option.  Silence may be simply
an absence of packets for some codecs.  (I realize that there are also schemes
for transmitting silence and comfort noice as additional payload types).  H.245
uses booleans to indicate codec options such as silence suppression and high and
low bitrate choices in G.723.

Also some systems may have a difficulty in supporting multiple payload types.
Although H.248 allows this, some systems will avoid it if they use H.245
elsewhere in the system, since H.245 does NOT permit multiple payload types in a
single logical channel.

So while your scheme may serve some cases, I think that there is still the need
for a boolean value to be transmitted in an a= parameter for some codecs.
Whether all the other data is needed or not, I do not have as strong a
position.  I do believe that comfort noise type is useful for cases where noise
is simply generated at the far end and no payload packages are transmitted.

I also think that it is useful to have a consistent scheme.  I see no reason
that this is any different with ATM or RTP bearer channels so it would be nice
to have it outside the atm bearer specification or at least modify it in the
same way that is adopted for RTP.