[App_rpt] Voters

Sat Jan 21 17:39:01 UTC 2006

Steve,

Perhaps my first message was a bit terse. It seems that we are reasonably on 
the same page.

yes you mention the need for some DSP processing to determine the quality of 
the voice.  Some vocoders I have worked with send a quality or SNR number in 
the vocoded packet.  Does anyone on the list know enough about the GSM 
vocoders, or more likely the newer AMR vocoder to say if they include this 
sort of information?  Then the DSP processing is already done for us.  We 
just need to read the bits.

Charles.

----- Original Message ----- 
From: "Steve Rodgers" <hwstar at rodgers.sdcoxmail.com>
To: "Asterisk Repeater Controler" <app_rpt at lists.illiana.net>
Cc: <telesistant at hotmail.com>
Sent: Friday, January 20, 2006 11:18 PM
Subject: Re: [App_rpt] Voters

> 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
> _______________________________________________
> App_rpt mailing list
> App_rpt at lists.illiana.net
> http://lists.illiana.net/mailman/listinfo/app_rpt 