[App_rpt] Asterick controller to a CAT controller

Gary gary at tcomeng.com
Fri Dec 8 11:06:25 EST 2006

Thanks Jim! This explains the mysterious in/outxlat feature that I never fully understood.


Jim Duuuude wrote:
> Well here's some documentation that I just whipped up
> (not bad with 2 broken hands). You can tell I was sorta
> getting slap happy near the end (with my dry humor).
> Interfacing Alien Worlds (or linked systems at least)
> When given the task of providing usable communications between
> alien worlds, one first must analyze the similarities and
> differences between them. Then you need to find the most
> efficient way of dealing with the differences.
> One of these 'worlds' is the 'conventional' radio system based
> on controllers that have a 'common link path', that is where
> controllers are linked together thru permanent RF links connected
> to a controllers "link" port(s) and to provide linking between
> repeater systems (connected to "repeater" ports on their associated
> controller(s)), the controller opens an audio and control channel
> between the repeater's port and the link's port.
> In this manner, several repeaters on one controller (each on their
> own repeater ports) and one or more links to other controllers (each on 
> their
> own link ports) a multiple repeater linked network can be created.
> Each node has DTMF commands that it can do. Generally, there is some
> standard for the repeater functions on each node, and therefore some
> standard form (digit-wise) for these commands.
> There is also provided some form of being able to command a node (not
> your local repeater, but another one on the link) that, by its very nature
> differs from the commands for local node use (non-conflicting digit
> sequences, etc).
> One common example of this is to start local commands with an asterisk (*).
> Remote node commands start with a pound (#) plus the node number. Say, for
> example, you wanted to ask you local system what time it is. You might enter
> *98 on your local repeater, but to ask another node (in this example node 
> 123),
> you might enter (#12398). This is a practical example of local/distant 
> control
> differentiation, since by convention, all local commands start with (*) and
> all link (distant) commands start with (#).
>>From a technical standpoint, its also an easy an practical way to implement
> controllers and links. A link port has a DTMF receiver listening for its
> 'addressing' code (like #123, in the example above). When it hears it, it
> listens for the rest of the command, and does the appropriate thing. All 
> link
> ports have a DTMF receiver listening to the same audio (well, they're linked
> together, of course), but only the proper one reacts (based upon the prefix
> code).
> When you have a fixed link (and often single path link) system, this is an
> excellent and time-proven design. Many, if not all of the amateur repeater
> controllers are currently based on this type of archetecture.
> App_rpt (Allstar, etc) definitely walks to the beat of a different drummer.
> First of all, there are no 'hard' or 'permanent' links. Since the linking
> media is TCP/IP, thus allowing connections from basically anywhere to 
> anywhere,
> links are completey dynamic and at will. Any node can theoretically be 
> connected
> to any node in any fashion. Several sets of links (not connected to each 
> other)
> may be operating at any given time. Yes, the software does support the 
> concept
> of 'establish a link and keep putting back up if it goes down'; Even these
> are 'soft' links. Additionally, since the link media is TCP/IP, out-of-band
> data may be sent between link endpoints, thus eliminating the need (or even 
> the
> desire, for that matter) for in-band (such as DTMF) signalling between link
> endpoints.
> There are 2 very serious archetectural differences between app_rpt and
> a 'conventional' system.
> The first one is that all system endpoints including
> repeaters, remote bases, and alien system interfaces, are separate nodes 
> (and have separate
> node numbers assigned to them). Normally, a remote base is part of a repater
> system. Not here. A remote base is a separate independent entity.
> The second one is that you have to essentially 'speak' to a remote node to 
> give
> it commands. Unlike a conventional system where all of the link entities are 
> on
> a common talk path, and all have DTMF receivers decoding all of your digits,
> you have to put your local system into remote command mode (to a particular 
> node),
> then all the DTMF you send will go to the remote node, rather then being 
> interpreted
> by the local system. Thats now app_rpt performs differentiation between 
> local and
> remote commands. All app_rpt commands begin with (*) asterisk. The (#) pound
> is used to exit things, like for example to exit command mode. Obvoiusly, 
> since
> all commands start with (*) and cant contain (#), when youre in local 
> command mode
> it knows what to send to the remote, and when youre done with it.
> So, whether you are controlling another repeater, a remote base, or an alien 
> network,
> you have to invoke command mode to the node that you are intending to 
> control.
> Interface from app_rpt to an alien network is accomplished via a node 
> configured as
> a repeater in duplex mode 0, and the propagate_dtmf and linktolink options 
> both
> enabled.
> Clearly there exists a very serious incompability in the concepts of DTMF 
> command
> format and archetecture.
> First of all, the app_rpt needs to respond as if it were another link node, 
> listening for
> its prefix code, then acting appropriately. This can be accomplished with 
> the inxlat
> configuration directive. First, there needs to be a sequence, which is to be 
> 'turned into'
> a (*) as far as the app_rpt is conerned, and also one that is to be 'turned 
> into'
> a (#) as far as the app_rpt is concerned (you cant use a real * or # since 
> so many
> of the alien's commands have these characters in them). So, you assign it a 
> node number,
> say 456. So the sequence 4561 can represent *, and the 4562 can represent # 
> ( or you can
> assign 2 different prefixes, like 456 and 457 if you want it to be 1 digit 
> less), but in
> any case you put in something like :  inxlat = #456,#457,0123456789ABCD
> That would mean: #456 is like (*), #457 is like (#), and just pass any of 
> the listed digits
> in the 3rd arg, if they are not part of a command.
> Now that we have that settled, the app_rpt node needs to send commands to 
> the rest of
> the link as if it were one of them, meaning prefixed commands. As we already 
> know,
> the normal (app_rpt) commands on the node that is connected to the alien 
> system start
> with (*) and cant contain (#) (thats how we do it in app_rpt). so we need to 
> be able
> to 'create' a way to send a (*) and (#) out the node. So we use outxlat, as 
> follows:
> outxlat = *7,*0,0123456789#ABCD
> This means that *7 get sent out to the alien system as a (*), *0 gets sent 
> out as a (#),
> and pass any of the digits listed in the 3rd arg if not part of a local 
> command.
> So, say the ailen system was on allstar node 123. We then want to command 
> the alien's
> node 765 to do a *98 (like give us its local time).
> On your local node you might enter:
> *4123 (to put you into command node on 123, which is the alien system)
> *076598 (to do the same as if you were entering #76598 on the alien system 
> directly on one
>          of its repeaters)
> #  (to exit command mode on your local node)
> These two pieces of translation allow the systems to communicate with each 
> other
> very nicely and with minimum hassle and/or discomfort for users of either 
> system
> type.
>> From: Will <w4wwm at knology.net>
>> Reply-To: Asterisk Repeater Controler <app_rpt at lists.illiana.net>
>> To: app_rpt at lists.illiana.net
>> Subject: [App_rpt] Asterick controller  to a CAT controller
>> Date: Fri, 08 Dec 2006 02:51:48 -0600
>> MIME-Version: 1.0
>> Received: from lists.illiana.net ([]) by 
>> bay0-mc3-f5.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2444); Fri, 8 
>> Dec 2006 00:52:54 -0800
>> Received: (qmail 22992 invoked from network); 8 Dec 2006 08:51:53 -0000
>> Received: from localhost (HELO ? (  by 0 with SMTP; 8 
>> Dec 2006 08:51:53 -0000
>> Received: (qmail 22966 invoked from network); 8 Dec 2006 08:51:51 -0000
>> Received: from smtp.knology.net ( 0 with SMTP; 8 Dec 2006 
>> 08:51:51 -0000
>> Received: (qmail 4943 invoked by uid 0); 8 Dec 2006 08:51:50 -0000
>> Received: from unknown (HELO ? (w4wwm at 
>> smtp2.knology.net with ESMTPA; 8 Dec 2006 08:51:50 -0000
>> X-Message-Info: txF49lGdW42+DGHr+cvEgbodQNncuZKWcInXLwzD5NI=
>> Return-Path: <w4wwm at knology.net>
>> Delivered-To: mailman-app_rpt at lists.illiana.net
>> User-Agent: Thunderbird (Windows/20061025)
>> X-BeenThere: app_rpt at lists.illiana.net
>> X-Mailman-Version: 2.1.6
>> Precedence: list
>> List-Id: Asterisk Repeater Controler <app_rpt.lists.illiana.net>
>> List-Unsubscribe: 
>> <http://lists.illiana.net/mailman/listinfo/app_rpt>,<mailto:app_rpt-request at lists.illiana.net?subject=unsubscribe>
>> List-Archive: <http://lists.illiana.net/pipermail/app_rpt>
>> List-Post: <mailto:app_rpt at lists.illiana.net>
>> List-Help: <mailto:app_rpt-request at lists.illiana.net?subject=help>
>> List-Subscribe: 
>> <http://lists.illiana.net/mailman/listinfo/app_rpt>,<mailto:app_rpt-request at lists.illiana.net?subject=subscribe>
>> Errors-To: app_rpt-bounces at lists.illiana.net
>> X-OriginalArrivalTime: 08 Dec 2006 08:52:55.0001 (UTC) 
>> FILETIME=[405BF490:01C71AA6]
>>  >>Are you are trying to send DTMF from the asterisk system to the
>> Controller B?
>> Yes,  I need to send DTFM  to controller B.  Asterisk is on controller B
>> wired the repeater port as of the few last e-mail post.  On controller B
>> there are 3 link ports, port 1 is 2 meters, port 2 is IRLP(node4516) and
>> port 3 is the half duplex link (hard wired} to Controller A.  If
>> possible I would like Asterisk to send DTMF to control the links.  I
>> would also have the IRLP program to send DTMF tones back to Asterisk for
>> linkup to any Asterisk nodes, via from Controller A
>> Controller A is bridged or Hardwired by way of port 3 to Controller B
>> port 3. One side of my controls will be coming from Controller A to
>> Controller B and the other from B to C
>>  Anyway if you like you can give me a call on my IRLP node 4516 any
>> time. Thanks
>> Will / W4wwm
>> _______________________________________________
>> App_rpt mailing list
>> App_rpt at lists.illiana.net
>> http://lists.illiana.net/mailman/listinfo/app_rpt
> _______________________________________________
> App_rpt mailing list
> App_rpt at lists.illiana.net
> http://lists.illiana.net/mailman/listinfo/app_rpt

More information about the App_rpt-users mailing list