<div dir="ltr"><div><div>Asterisk's "dsp.c" (even the old version in the app_rpt fork, I believe) does indeed already decode them at no additional cost, so I too would have expected them to just come along for the ride.  Does some other part of the system filter them out?<br>

<br></div><div>Who cares why -- although I can think of a dozen use cases without even trying hard.  Besides, it costs absolutely nothing when you're already doing the other digits.  Let the man have his tones, I say.<br>

</div><br>$0.02,<br></div>Eric<br>K5BFC<br><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 14, 2014 at 7:29 AM, Bryan Fields <span dir="ltr"><<a href="mailto:Bryan@bryanfields.net" target="_blank">Bryan@bryanfields.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 8/14/14, 9:24 AM, Bryan D. Boyle wrote:<br>
> The issue is *why* is it so danged important to have the A-D keys decoded?<br>
>  security through obscurity?  Because they are there on ham mics?<br>
><br>
> No one has really described a use case for why this artifact of the whole dtmf<br>
> protocol is really needed.   especially when, with the asterisk system, there<br>
> is almost an unlimited functionality with using just the 10 digits bracketed<br>
> by the star and octothorpe.<br></div></blockquote></div></div></div></div></div>