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