[Asterisk-Users] Re: Why Asterisk can't cope with silence suppression?
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 cant * just play comfort noise when it doesnt see any rtp packets in a particular bearer channel? Unless I am missing something fundamental this doesnt seem to be a huge architectural change. Id have to agree that a lack of proper vad support is a major shortcoming. ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Re: Why Asterisk can't cope with silence suppression?
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 cant * just play comfort noise when it doesnt see any rtp packets in a particular bearer channel? Unless I am missing something fundamental this doesnt seem to be a huge architectural change. Id 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. ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Re: Why Asterisk can't cope with silence suppression?
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 cant * just play comfort noise when it doesnt see any rtp packets in a particular bearer channel? Unless I am missing something fundamental this doesnt seem to be a huge architectural change. Id 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 [EMAIL PROTECTED] ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] Re: Why Asterisk can't cope with silence suppression?
In article [EMAIL PROTECTED], Steven Critchfield [EMAIL PROTECTED] wrote: 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. I thought Asterisk *always* used the incoming RTP stream to clock the outgoing. Are you saying that Asterisk can now handle silence suppression on RTP streams if a Zaptel timing source is available? Cheers Tony -- Tony Mountifield Work: [EMAIL PROTECTED] - http://www.softins.co.uk Play: [EMAIL PROTECTED] - http://tony.mountifield.org ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Re: Why Asterisk can't cope with silence suppression?
On Wed, 2005-02-16 at 21:59 +, Tony Mountifield wrote: In article [EMAIL PROTECTED], Steven Critchfield [EMAIL PROTECTED] wrote: 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. I thought Asterisk *always* used the incoming RTP stream to clock the outgoing. Are you saying that Asterisk can now handle silence suppression on RTP streams if a Zaptel timing source is available? Maybe I am confused about the audio coming from a zaptel device for which there would always be audio coming in to be transmitted. -- Steven Critchfield [EMAIL PROTECTED] ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Re: Why Asterisk can't cope with silence suppression?
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 cant * just play comfort noise when it doesnt see any rtp packets in a particular bearer channel? Unless I am missing something fundamental this doesnt seem to be a huge architectural change. Id 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. Personal opinion (and everyone's got one) is that vad does not produce the savings that one might expect. People are use to constantly talking (in many cases full-duplex-style), room background noise, dog barking, etc, etc, which reducees the impact. Vad may have some small value for residential voip users where their bandwidth is a little on the too- small side, but asterisk was not designed with the intent of putting a pbx in every home. ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] Re: Why Asterisk can't cope with silence suppression?
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. ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
