[App_rpt] Voters

Sat Jan 21 04:18:42 UTC 2006

Charles,

Your ideas are workable. When I stated multiple asterisk boxes would be 
required, I assumed you would have an Asterisk box at each remote site, and 
at the hub.

You would have to modify App_rpt to create persistent links at initialization. 
That is, as soon as a remote receiver system boots up, it would place an IAX2 
call to the hub machine. It would have to keep retrying the call if the 
connection fails. As currently configured, App_rpt only retries for a short 
amount of time then gives up.

If you are planning on allowing your users to send DTMF commands to the 
repeater at the hub, you have to keep in mind that the GSM codec will corrupt 
pure tone sequences such as DTMF. All DTMF would have to be decoded at the 
voter remote receiver site, and sent out of band to the hub. We already do 
this when sending DTMF commands to App_rpt remote nodes, so a modification 
would be required to send all DTMF sequences to the to the hub.

If you are replacing an existing analog voter, there would be some dsp code 
required at the hub to "vote on noise", or the remote receivers would have to 
send RSSI information out of band and the hub would have to then make a 
decision. 

"Internet weather" is another issue to consider. If one of your links starts 
losing packets (dropout), packets get sent way out of order (jitter), or the 
connection becomes very laggy (high latency), the voting decision-making code 
in Asterisk should automatically disqualify that link and select the next 
best link from a quieting/RSSI standpoint. Network quality variables are 
available in Asterisk for both the near end and the far end as part of the 
chan_iax2 channel driver.

You would need to also add a control layer to allow you to switch off links 
with persistent issues, or enable backup links on those which fail. At some 
point you could event define which backup links get switched in 
automatically.

All of this could be added to App_rpt as additional functionality while 
retaining all of the linking and repeater controller functions. This is the 
way I'd like to see it done. I really don't understand why a standalone 
repeater controller is necessary when you have all of that functionality
available to you in App_rpt.

Answers to your questions:

Firewalls are not as much a problem with IAX2 as they are with SIP. Only one 
port needs to be opened in the firewall and directed to the Asterisk box. The 
only port which needs to be opened is 4569 for IAX2 and possibly a port for 
SSH.

We have mostly solved the Dynamic IP issue by using DDNS and forward DNS 
lookup at connect time. Most of the systems on the Allstar link have dynamic 
IP addresses, and they are able to connect to each other. The biggest problem 
will be in a system where the hub has a dynamic IP address and that IP 
address changes frequently. In this case, then all of the remote receiver 
sites will not be able to reconnect with the hub until its new IP address can 
be found by doing a forward DNS lookup. The problem with DNS is that there 
can be a server-to-server propagation time which will force the remote sites 
to remain disconnected until the the new DNS record propagates to all the 
necessary places. The prudent thing to do here is to make sure the hub has a 
static IP address so that you don't lose all your remote sites due to  IP 
address changes.

I touched on the unreliable like issue above, and this will be an issue 
which will require some experimentation to minimize.

Steve

WA6ZFT

On Friday 20 January 2006 05:33, Charles Suprin wrote:
> Steve,
>
> I beg to differ with your waste comment. However my knowledge lives more on
> the radio side than the asterisk side. The following ideas show the
> flexibility and perhaps even a cost savings that a Asterisk Voter offers.
> Please share any thoughts on the matter.
>
> As asterisk can interface with telephone lines and radios, from a
> connection aspect, it can drop in to the slot currently held by a voter. 
> This would only require a single asterisk box. All the signals are
> available to that one box and it creates the receive audio internally. This
> configuration does not require multiple Asterisk boxes.
>
> If an internet connection is available at the repeater site, a single
> broadband connection can handle many more IAX2 feeds than the similar price
> in POTS lines.  This reduces monthly operating costs for people using
> leased lines.
>
> Additionally, if only phone lines are available to the site, an asterisk
> box at the site and one at another location, perhaps someone's home, can
> receive audio over the phone line, and send a voted audio stream back over
> the full duplex link.  Once back at the site, the audio can be dumped over
> the radio. This architecture allows more receivers than before and
> correspondingly better coverage.
>
> Hams generally being high tech people, several I know have towers and
> already use Asterisk for telephone.  These folks are now much cheaper to
> turn into receiver sites using asterisk than with either a leased line
> configuration (Recurring cost) or radio link. ( save on the transmitter and
> directional antenna.  Also eliminates the line of sight requirements back
> to the main repeater.)
>
> Furthermore if a receiver site fails and physical access is difficult, for
> weather or any other reason, Asterisk scales more gracefully to handle more
> connections to accept more receivers from less advantageous locations.
> Again, I am assuming that club members or others can host the receiver
> locations.
>
> There do remain issues with these architecures. How well do dynamic IP
> address fit into the architecture? What about firewall configurations? What
> about unreliable links? These are all open questions to me. As I said, I am
> coming at this from the radio side.
>
> I believe the finances really shift depending on whether one is looking at
> a commecial installation, where several of the costs born by club members
> away are real.
>
> Charles
> AA1VS
>
>
> ----- Original Message -----
> From: "Steve Rodgers" <hwstar at rodgers.sdcoxmail.com>
> To: "Asterisk Repeater Controler" <app_rpt at lists.illiana.net>
> Sent: Thursday, January 19, 2006 9:28 PM
> Subject: Re: [App_rpt] Voters
>
> > If you turned off the ID and courtesy tones in rpt.conf it should work.
> > It is
> > somewhat of a waste to do this though as 2 or more asterisk systems are
> > required. Also you will have to initiate the connection some way from
> > each voting receiver on power up.
> >
> > Steve, WA6ZFT
> >
> > On Thursday 19 January 2006 18:00, Charles Suprin wrote:
> >> Howdy,
> >>
> >> Has anyone tried to use asterisk as a voting receiver?  It seems that if
> >> all the receivers are in the same conference bridge then it should work
> >> ok.
> >> Atleast at first.
> >>
> >> There may be some enhancements to be made in terms of passing SNR
> >> measures
> >> either as part of the vocoder stream or as part of the IAX2 metadata to
> >> make it a true voter.
> >>
> >> Charles
> >>
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> App_rpt mailing list
> App_rpt at lists.illiana.net
> http://lists.illiana.net/mailman/listinfo/app_rpt