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