[App_rpt] Asterick controller to a CAT controller
Gary
gary at tcomeng.com
Fri Dec 8 16:06:25 UTC 2006
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 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 ([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 at 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 at knology.net>
>> Delivered-To: mailman-app_rpt at lists.illiana.net
>> User-Agent: Thunderbird 1.5.0.8 (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