Charles, I'm not aware of any feature like this in GSM. With regard to DSP required, it would probably involve measuring the noise content of a signal. The problem is, that there's no easy way to determine noise from a valid signal when measuring energy and spectrum in band. What this means is you would probably have to get your signal quality from noise outside of the bandwidth of the channel similar to what happens with noise squelch circuits. Also, there is something else I forgot to mention in the issue list under Internet weather. There needs to be a way to adjust the delays dynamically between all of the receive channels so that when the voter switches audio channels, there is no repeated or dropped voice frames. This may not be a trivial exercise. Steve WA6ZFT On Saturday 21 January 2006 09:39, Charles Suprin wrote:
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@rodgers.sdcoxmail.com> To: "Asterisk Repeater Controler" <app_rpt@lists.illiana.net> Cc: <telesistant@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@rodgers.sdcoxmail.com> To: "Asterisk Repeater Controler" <app_rpt@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@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
_______________________________________________ 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
_______________________________________________ App_rpt mailing list App_rpt@lists.illiana.net http://lists.illiana.net/mailman/listinfo/app_rpt