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 <[EMAIL PROTECTED]> _______________________________________________ Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
