[Asterisk-Users] Re: Why Asterisk can't cope with silence suppression?

[Steven Critchfield]

On Wed, 2005-02-16 at 14:13 -0600, Chris Wade wrote:
> Keith O'Brien wrote:
> >  
> > 
> >> >>Essentially its because * has been architected to send an rtp packet 
> > "after" receiving a packet. If * never "see's" and >>>incoming rtp 
> > packet, then it won't send an rtp packet (which usually contains some 
> > amount of audio). Thus choppy audio >>>in one direction.
> > 
> > So why can’t * just play comfort noise when it doesn’t see any rtp 
> > packets in a particular bearer channel?   Unless I am missing something 
> > fundamental this doesn’t seem to be a huge architectural change.  I’d 
> > have to agree that a lack of proper vad support is a major shortcoming.
> 
> It's more than that, from what I know a *missing* RTP packet could be 
> 'silence' (vad) or it could be 'network related' (jitter).  * not seeing 
> a packet doesn't always mean it was vad, it might mean your network had 
> a split second (subsecond) hiccup that caused the packet to disappear - 
> both 'look the same' to *.  This is why someone had already mentioned 
> the idea that the new jitter-buffer might handle this better/correctly.
> 
> -Chris
> 
> PS: I may be completely wrong - a guru's statement (although already 
> listed in the archives multiple times) would be appreciated.

Simple answer would be to just get a proper timing source. Barring
timing from a piece of hardware, asterisk falls back to triggering sends
because something was received.
-- 
Steven Critchfield <critch at basesys.com>