[asterisk-dev] Silence detection on Dial application (mainly with SIP)

Nir Simionovich nir.simionovich at gmail.com
Tue Jul 14 07:18:47 CDT 2009


Well,

  I agree that the functionality isn't simple, however, I believe its
worthwhile. Many of the various callback services around the world utilize
Asterisk - due to shitty lines and shitty providers, they sometimes over pay
by a factor of 20% due to lenghtened disconnects.

  If Asterisk presents such a functionality, even with the overheads, then I
think its worth it. Think about it this way, a callback scenario whould
usually take also the L() parameter, which will automatically make the Audio
path pass through Asterisk - in other words, in most cases it will already
be there, why not analyze it?

Nir

On Tue, Jul 14, 2009 at 3:07 PM, Alex Balashov <abalashov at evaristesys.com>wrote:

> Nir Simionovich wrote:
>
> >   On callback based systems, I've noticed that their exists an issue
> > with disconnecting the call when
> > there is silence on the line. Asterisk is fairly capable of detecting
> > the absence of RTP on SIP, however,
> > if RTP is still existant between the nodes, Asterisk doesn't disconnect
> > - although the RTP is just silence.
>
> If something like this were implemented, it would not be particular to
> Dial(), but rather a feature of the way RTP streams are processed in
> general--although, perhaps, the feature could be enabled on a given call
> leg by a flag passed to Dial().
>
> This is computationally expensive, since Packet2Packet bridging would
> have to be done away with and a certain sample of waveform would need to
> be reconstructed (and buffered, and saved persistently across multiple
> packets--20 ms packetisation duration won't cut it) by Asterisk, much as
> is done with in-band DTMF detection.  It is also difficult and unlikely
> to work well given the ubiquity of background noise - whether real or a
> figment of something in the transmission path (i.e. static, buzz) - that
> has practically infinite manifestations;  in this respect, AMD would
> seem to be easier from a mathematical perspective.
>
> Then again, people said the same thing about AMD and, instead, it
> sort-of works.
>
> Still, there's a fundamental fallacy in all this for as long as we have
> analog lines and/or crappy variable bit-rate codecs on cell phones
> and/or all the other acoustic artifices of the PSTN.  If every channel
> consisted of pristine, noise-canceled HD voice, it might stand a chance.
>
> When John Sculley (the Pepsi guy, later Apple CEO) was pushing the
> development of the Newton PDA, he failed to appreciate a fact known to
> almost every programmer and computer science student:  Handwriting
> recognition is impossible.  Not "some kind of handwriting recognition,"
> but rather the kind his "vision" aimed for.
>
> -- Alex
>
> --
> Alex Balashov
> Evariste Systems
> Web     : http://www.evaristesys.com/
> Tel     : (+1) (678) 954-0670
> Direct  : (+1) (678) 954-0671
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20090714/cb07a75e/attachment.htm 


More information about the asterisk-dev mailing list