Thanks Jim! This explains the mysterious in/outxlat feature that I never fully understood. Gary 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.
JIM - WB6NIL
From: Will <w4wwm@knology.net> Reply-To: Asterisk Repeater Controler <app_rpt@lists.illiana.net> To: app_rpt@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 ([64.212.212.35]) 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 ?127.0.0.1?) (127.0.0.1) 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 (24.214.63.101)by 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 ?192.168.1.101?) (w4wwm@69.1.11.66)by smtp2.knology.net with ESMTPA; 8 Dec 2006 08:51:50 -0000 X-Message-Info: txF49lGdW42+DGHr+cvEgbodQNncuZKWcInXLwzD5NI= Return-Path: <w4wwm@knology.net> Delivered-To: mailman-app_rpt@lists.illiana.net User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) X-BeenThere: app_rpt@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@lists.illiana.net?subject=unsubscribe> List-Archive: <http://lists.illiana.net/pipermail/app_rpt> List-Post: <mailto:app_rpt@lists.illiana.net> List-Help: <mailto:app_rpt-request@lists.illiana.net?subject=help> List-Subscribe: <http://lists.illiana.net/mailman/listinfo/app_rpt>,<mailto:app_rpt-request@lists.illiana.net?subject=subscribe> Errors-To: app_rpt-bounces@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@lists.illiana.net http://lists.illiana.net/mailman/listinfo/app_rpt
_______________________________________________ App_rpt mailing list App_rpt@lists.illiana.net http://lists.illiana.net/mailman/listinfo/app_rpt