<div dir="ltr">Thanks for that acknowledgement David.<div>I would put my money where my mouth is if I knew the difference between winding my butt or scratching my watch when it comes to software development.</div><div>What I can do is apply the all powerful rule of "Light but Consistent pressure" against stodginess and beg software folks like yourself to help put ammo in my bullet box to fight it.</div><div><br></div><div>Rob Conklin</div><div><b><font size="4"><a href="http://qrz.com/db/N4WGY">N4WGY</a></font></b></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 27, 2015 at 8:57 PM, David McGough <span dir="ltr"><<a href="mailto:kb4fxc@inttek.net" target="_blank">kb4fxc@inttek.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Rob, *sigh* ...Yes, you are correct!<br>
<span class=""><br>
On Sun, 27 Dec 2015, Robert Conklin wrote:<br>
<br>
> Thanks everyone for your thoughtful and informative inputs, excellent stuff.<br>
><br>
> As reliable and agile as the AllStar system may for repeater control, there<br>
> is a multitude of legacy hardware based systems out there that are are<br>
> owned by municipalities and large repeater associations. These systems are<br>
> not going to be replaced anytime soon with more modern systems, regardless<br>
> of the validity of any argument that could be brought up to do so.<br>
><br>
> The reasons for this stodginess are fodder for much debate, perhaps in<br>
> another thread.<br>
><br>
> During that interim it would powerful to be able to propagate dtmf thru<br>
> allstar to control the behaviors of those legacy controllers. The agility<br>
> to work reliably alongside and with legacy repeater controllers would make<br>
> a real and present argument to eventually replace those older controllers<br>
> with these more reliable and agile tools.<br>
><br>
> Rob Conklin<br>
</span>> *N4WGY* <<a href="http://qrz.com/db/N4WGY" rel="noreferrer" target="_blank">http://qrz.com/db/N4WGY</a>><br>
<span class="im HOEnZb">><br>
> On Sun, Dec 27, 2015 at 4:49 PM, David McGough <<a href="mailto:kb4fxc@inttek.net">kb4fxc@inttek.net</a>> wrote:<br>
><br>
> ><br>
> > Hi Everyone,<br>
> ><br>
> > Ah. DTMF propagation. Hum. Well, there are a some areas of AllStar that<br>
> > are weak in performance when compared to typical analog controllers, and<br>
> > IMO, this is one of them.  I agree with Willem's and Rob's comments about<br>
> > propagate_dtmf and related functionality--I've had less than satisfactory<br>
> > results as well, for several reasons (that I won't elaborate on just now).<br>
> ><br>
> > My solution has been to add several hacks to the app_rpt source code, but,<br>
> > even this still has rough edges, partly due to imperfect muting of the<br>
> > source DTMF signaling.<br>
> ><br>
> > Another possibility might be to add DTMF generation macros in the dialplan<br>
> > (extensions.conf file).<br>
> ><br>
> > I'll investigate this further. It has been been on my to-do list a long<br>
> > time.  I've got an SCOM 7330 and Link-Comm club sitting on the shelf I can<br>
> > experiment with--both of these controllers got replaced by AllStar<br>
> > controllers and honestly, I've never looked back!<br>
> ><br>
> ><br>
> > 73, David KB4FXC<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
<br>
arm-allstar mailing list<br>
<a href="mailto:arm-allstar@hamvoip.org">arm-allstar@hamvoip.org</a><br>
<a href="http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar" rel="noreferrer" target="_blank">http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar</a><br>
<br>
Visit the BBB and RPi2 web page - <a href="http://hamvoip.org" rel="noreferrer" target="_blank">http://hamvoip.org</a><br>
</div></div></blockquote></div><br></div>