asterisk users - Feb 2005 - Why Asterisk can't cope with silence suppression?

OK I have to ask.

Why is it that Asterisk can't cope with silence suppression?
All the clients seem to be able to but not Asterisk.
What would be needed to get it to work with silence suppression?
What is the problem?

> OK I have to ask.
> 
> Why is it that Asterisk can't cope with silence suppression?
> All the clients seem to be able to but not Asterisk.
> What would be needed to get it to work with silence suppression?
> What is the problem?
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.

On Wed, 16 Feb 2005, Rob Scott wrote:
> Why is it that Asterisk can't cope with silence suppression?
> All the clients seem to be able to but not Asterisk.
> What would be needed to get it to work with silence suppression?
> What is the problem?
Asterisk clocks outgoing rtp data to a device from the incoming rtp 
stream from the same device. This is a known limitation and there has been 
some talk about implementing an internal clocking system.

In addition, Asterisk should generate comfort noise when the rtp stream is 
quiet due to silence supression (which is signalled with a CN packet). 
Perhaps the new jitter buffer will be able to handle this?

Peter

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

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20050216/ad2a5228/attachment.htm

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

Yes, but you can determine if the packet is missing due to packet loss or if
it is missing due to vad by looking at the RTP sequence numbers and time
stamps.   I agree that the first step to getting this properly working is to
get a better jitter buffer as you have to buffer to a degree to examine the
sequence numbers.   

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20050216/e6d2dcce/attachment.htm