From aa1vs at arrl.net Fri Jan 20 02:00:53 2006 From: aa1vs at arrl.net (Charles Suprin) Date: Thu, 19 Jan 2006 21:00:53 -0500 Subject: [App_rpt] Voters Message-ID: <006601c61d65$5b934b80$6401a8c0@CHARLESS> 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 From hwstar at rodgers.sdcoxmail.com Fri Jan 20 02:28:28 2006 From: hwstar at rodgers.sdcoxmail.com (Steve Rodgers) Date: Thu, 19 Jan 2006 18:28:28 -0800 Subject: [App_rpt] Voters In-Reply-To: <006601c61d65$5b934b80$6401a8c0@CHARLESS> References: <006601c61d65$5b934b80$6401a8c0@CHARLESS> Message-ID: <200601191828.29081.hwstar@rodgers.sdcoxmail.com> 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 From aa1vs at arrl.net Fri Jan 20 13:33:39 2006 From: aa1vs at arrl.net (Charles Suprin) Date: Fri, 20 Jan 2006 08:33:39 -0500 Subject: [App_rpt] Voters References: <006601c61d65$5b934b80$6401a8c0@CHARLESS> <200601191828.29081.hwstar@rodgers.sdcoxmail.com> Message-ID: <00b601c61dc6$23220500$6401a8c0@CHARLESS> 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" To: "Asterisk Repeater Controler" 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 From hwstar at rodgers.sdcoxmail.com Sat Jan 21 04:18:42 2006 From: hwstar at rodgers.sdcoxmail.com (Steve Rodgers) Date: Fri, 20 Jan 2006 20:18:42 -0800 Subject: [App_rpt] Voters In-Reply-To: <00b601c61dc6$23220500$6401a8c0@CHARLESS> References: <006601c61d65$5b934b80$6401a8c0@CHARLESS> <200601191828.29081.hwstar@rodgers.sdcoxmail.com> <00b601c61dc6$23220500$6401a8c0@CHARLESS> Message-ID: <200601202018.43002.hwstar@rodgers.sdcoxmail.com> 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" > To: "Asterisk Repeater Controler" > 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 From aa1vs at arrl.net Sat Jan 21 17:39:01 2006 From: aa1vs at arrl.net (Charles Suprin) Date: Sat, 21 Jan 2006 12:39:01 -0500 Subject: [App_rpt] Voters References: <006601c61d65$5b934b80$6401a8c0@CHARLESS> <200601191828.29081.hwstar@rodgers.sdcoxmail.com> <00b601c61dc6$23220500$6401a8c0@CHARLESS> <200601202018.43002.hwstar@rodgers.sdcoxmail.com> Message-ID: <00a701c61eb1$91f5af40$6401a8c0@CHARLESS> 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" To: "Asterisk Repeater Controler" Cc: 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" >> To: "Asterisk Repeater Controler" >> 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 From hwstar at rodgers.sdcoxmail.com Sun Jan 22 03:57:48 2006 From: hwstar at rodgers.sdcoxmail.com (Steve Rodgers) Date: Sat, 21 Jan 2006 19:57:48 -0800 Subject: [App_rpt] Voters In-Reply-To: <00a701c61eb1$91f5af40$6401a8c0@CHARLESS> References: <006601c61d65$5b934b80$6401a8c0@CHARLESS> <200601202018.43002.hwstar@rodgers.sdcoxmail.com> <00a701c61eb1$91f5af40$6401a8c0@CHARLESS> Message-ID: <200601211957.48344.hwstar@rodgers.sdcoxmail.com> 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" > To: "Asterisk Repeater Controler" > Cc: > 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" > >> To: "Asterisk Repeater Controler" > >> 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 > > _______________________________________________ > App_rpt mailing list > App_rpt at lists.illiana.net > http://lists.illiana.net/mailman/listinfo/app_rpt From hwstar at rodgers.sdcoxmail.com Mon Jan 30 02:28:03 2006 From: hwstar at rodgers.sdcoxmail.com (Steve Rodgers) Date: Sun, 29 Jan 2006 18:28:03 -0800 Subject: [App_rpt] Test version 0.41 of app_rpt.c Message-ID: <200601291828.03689.hwstar@rodgers.sdcoxmail.com> There is a test version of app_rpt.c available at http://allstarlink.org/app_rpt.c . If no issues are reported, this version will be committed to the zaptel main trunk in one week's time. Changes from 0.40 to 0.41: 1. A fix a subtle telemetry lock failure which caused a stuck transmitter. 2. Command macro support. 3. The polite ID now occurs after hangtime (in the same place as tail messages) 4. iaxrpt audio is now muted when there is no keying. 5. Enhanced debug support for finding future locking issues. 6. Rpt variable dump can mow be done from the command line. Steve WA6ZFT