[App_rpt-users] DTMF passthru

Tony kt9ac at ameritech.net
Mon Jan 24 16:42:59 EST 2011

I replied to Cory privately but wanted to share a thought and some 
successes I have with the group.

Jim graciously added MDC1200 support to Asterisk/Allstar last summer. I 
have been using MDC1200 as my primary method of control since. It does 
not mute like DTMF does and therefore could be used for control purposes.

Some reasons:
1) MDC is a fixed-length data packet transmitted within 175mS, has 
built-in error correction and will ignore the packet if the correct 
number of bits are not received (checksum). DTMF is subject to partial 
command interpretation during signal drops.

2) MDC is equally as insecure as DTMF. It is a little harder to recreate 
by a jammer and can mask the real command digits.

3) While mobile, I have my radio programmed with different MDC systems 
(ID's). Changing modes or channels and keying up is enough to send the 
command over to the repeater. Contrast this to holding a mic and pushing 
numbers while driving, which is very prone to error and takes your eyes 
off the road.

Allstar can both encode and decode MDC, so a suggestion instead of the 
propagate_dtmf and its current design would be to craft a series of ID 
codes to be sent between nodes over the air, and have the target side 
map these to DTMF commands and/or macros. I do just this on my systems. 
Some radios have a limitation of 8 unique MDC ID's, but Allstar 
node-to-node should be fine.

Radio Mode 1 - MDC ID = 1234. Allstar decodes and maps to DTMF command 
*32000 (link to node 2000).
Radio Mode 2 - MDC ID = 1235. Allstar decodes and maps to DTMF command 
*12000 (disconnect node 2000).
Radio Mode 3 - MDC ID = 1236. Allstar decodes and maps to DTMF command 
*987 (disconnect ALL nodes).

I1234 = *32000
I1235 = *12000
I1236 = *987

I would be glad to help out with how this could work, or do some testing 
if asked. You'll need to copy the mdc1200.h and .c files from the extras 
directory and uncomment the #include files within app_rpt.c to get it to 
compile in.


On 01/24/2011 11:56 AM, Corey Dean N3FE wrote:
> I am actually wanting things just a little different.  Until I can get 
> internet to each site so I can get asterisk there I would like to use 
> a command that I could enter and anything following it would generate 
> the DTMF.
> Here is my current scenario...  I use one of my UHF machines as the 
> hub (for now) and I have different machines that listen to the hub.  
> At times other repeaters will connect in as well.  DTMF muting is 
> enabled on the local repeater but DTMF is NOT muted on the link side 
> that goes to the hub.  This way I can control the repeaters through 
> the links if I need to until I can get some type of ip network setup.
> Say a cop command is created for this and I make 932 my dtmf for that 
> cop command and I was to issue  1234 to turn on something at a remote 
> site, I would like to enter  *9321234 and have the controller either 
> pass or regenerate the 1234.
> I hope this makes sense.  I know a couple of groups that would like to 
> do this as well and that is the only reason they haven't moved over to 
> app_rpt.  They have seen how powerful it is!  One of the systems has 
> 15 repeaters in it and the only way they would be able to do something 
> would be a piece at a time.  That is why this would be so handy!!!!
> Corey  N3FE
> *From:*app_rpt-users-bounces at ohnosec.org 
> [mailto:app_rpt-users-bounces at ohnosec.org] *On Behalf Of *VE3GIH 
> Gordon Hewit
> *Sent:* Monday, January 24, 2011 12:34 PM
> *To:* app_rpt-users at ohnosec.org
> *Subject:* [App_rpt-users] DTMF passthru
> KE2N Ken suggested using the propagate_dtmf command in the rpt.conf 
> file, as a way to propagate DTMF signals to other nodes.  I need this 
> capacity to allow our members access to the local phone patch.  
> However with all nodes set to duplex=2 (full duplex) and 
>  propagate_dtmf=yes,  I'm still not getting DTMF on the other local 
> repeaters.  The asterisk console sees the DTMF, but Asterisk isn't 
> passing the digits onwards.
> Does anyone have a suggestion about what else I can try?
> VE3GIH Gord
> ______________________________________________
> Date: Sat, 22 Jan 2011 09:42:49 -0500 (EST)
> From: Ken <ke2n at cs.com <mailto:ke2n at cs.com>>
> To: n3fe at repeater.net <mailto:n3fe at repeater.net>, 
> telesistant at hotmail.com <mailto:telesistant at hotmail.com>,
> app_rpt-users at ohnosec.org <mailto:app_rpt-users at ohnosec.org>
> Subject: Re: [App_rpt-users] DTMF Allow
> Cory
> I think there is a setting for this
> propagate_dtmf=     see *MailScanner warning: numerical links are 
> often malicious:*
> <snipped>
> GL
> Ken
> KE2N
> Gordon Hewit
> 289-800-1473  (home)
> -- 
> This message was scanned and is believed to be clean.
> Click here to report this message as spam. 
> <%0d%0ahttp:/simba.repeater.net:8080/cgi-bin/learn-msg.cgi?id=523192F61F.A8CE3%0d%0a> 
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users at ohnosec.org
> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.allstarlink.org/pipermail/app_rpt-users/attachments/20110124/86c0b264/attachment.html>

More information about the App_rpt-users mailing list