[Asterisk-Users] Silence suppression on SIP calls generated from Asterisk?

[John Todd]

At 8:34 AM -0400 on 4/5/04, Brian Cuthie wrote:
>  > -----Original Message-----
>  > From: asterisk-users-admin at lists.digium.com
>>  [mailto:asterisk-users-admin at lists.digium.com] On Behalf Of
>>  Olle E. Johansson
>>
>>  Brian Cuthie wrote:
>>  >
>>  > Let's say that I have a call coming in to Asterisk through
>>  a TDM400P
>>  > and going out through SIP to someone on the Internet. Is there any
>>  > configuration option that would allow me to do silence
>>  suppression on
>>  > the RTP stream generated by Asterisk on behalf of the TDM400P
>>  > connected user?  SIP phones allow me to do this easily, but
>>  I'd like
>>  > to be able to conserve upstream bandwidth on calls that
>>  don't emanate
>>  > from a SIP phone here at my location.
>>  Asterisk SIP does not support silence suppression. In fact,
>>  using Silence suppression on an inbound RTP stream will lead
>  > to problems, since Asterisk takes timing from inbound RTP streams.
>
>Yeah, funny thing is I saw this problem just last night while messing around
>with music on hold. I had VAD on the SIP phone on and the MOH would stop
>unless I talked. I thought it was quite weird when it happened; now it makes
>sense.
>
>I've heard that Asterisk derives its timing in strange ways, but I've been
>wondering why it doesn't use the machine's clock (real-time interrupt, not
>wall-clock).
>
>-brian

Interestingly enough, Mark and I talked about this problem very 
briefly at dinner the other night.  My recollection is that he seemed 
to think that taking timing from a Zap driver would be feasible, but 
there were many other things to do ahead of time.  Perhaps others can 
program this or encourage it's development.

Personally, I think VAD is a great service, as well as comfort noise 
generation to disguise when VAD is working.  I'll always encourage 
methods that reduce bandwidth.   Most major developers on Asterisk 
consider these technologies of low concern since their bandwidth is 
"unlimited", as they typically sit in a co-lo somewhere (as many 
programmers of * are providers of service, not consumers.)  The 
reality for most end users is that they are on very restricted pipes 
that are delivered via a WAN technology (especially for outbound, if 
you consider residential) and being able to put more customers into 
expensive bitstreams makes a lot of financial sense.

JT