Re: [App_rpt-users] Echolink_and_app_rpt:_Looking_for_m ore_information_on_permit=*-*
simple solution, considering the clueless majority of users in the Echolink world, the lousy audio codecs, and the ancient technology that has not kept pace with either praxis or software advances: turn the damn thing off. You won't miss the drive-bys, distorted computer audio, fumble-fingered operators, and bandwidth usage. It's just so not worth the effort to maintain, worry about the software and technology use conditions, or anything else surrounding it. It's just amateur radio, not the launch codes. </grump> -- Bryan Sent from my iPhone 5...No electrons were harmed in the sending of this message.
On Nov 12, 2014, at 06:36, <mike@midnighteng.com> <mike@midnighteng.com> wrote:
Additional info (as if the first was not enough)...
I went to their (echolink) website looking for a rule...
Here it is...
Item #4 Stations operating in Sysop mode may interconnect EchoLink only with equipment operating on Amateur frequencies. EchoLink does not permit use of the system with other services such as GMRS, FRS, or MARS. For security reasons, it is also not permitted to interconnect EchoLink with other VoIP systems that support direct access from a computer.
found on their access policy page at...
echolink.org/access_policies.htm
There is no mention of other systems interconnect, just the VoIP via computer direct. I take the meaning of direct to mean "unverified" or unrestricted. This is consistent with the way I have been reading the poorly written emails some of you get from echolink.
...mike/kb8jnm
-------- Original Message -------- Subject: Re: [App_rpt-users] Echolink_and_app_rpt:_Looking_for_m ore_information_on_permit=*-* From: <mike@midnighteng.com> Date: Wed, November 12, 2014 5:28 am To: app_rpt-users@ohnosec.org, "Bob" <kk6ecm@gmail.com>
Bob, Doug and all,
I fully understand why you would think that. It is so poorly written. And as I have watched this conversation get out of hand at least 2 times as you have Doug.
This is the first time I thought I would clarify how I was reading their email statement before anyone gets elevated on it again.
other VoIP connections not Radio Sourced RoIP connections and only if you can't verify the VoIP.
They are saying VOIP connections from non-radio sources...ie phone and web portal without a security check. I have many non-experimental phone and web ports but nobody knows what it is so it is not a open port. I don't provide links to it from a web page or post a phone number and it "does" have multilevel security checks. Even if folks stumbled on it by accident or not, they would not have open access.
There are a lot of folks experimenting with asterisk side of the set-up. Many of us that have been using asterisk for many years know that we can port just about any kind of streaming audio or other services to asterisk and thereby app_rpt. Hard to tell what interfaces/ports are open on them and to where they go. Because some folks don't think about the implications of their actions, things happen. We all know that even from the radio side of the equation.
Problems can also occur if a unauthorized station/system is connected to others who are connected to you and there is no way to track that on the echolink side.
They are asking that when "you" have a open port like that (unverified VoIP), to disable the echolink port while it is active so a unverified user does not get access to echolink through VoIP, not RoIP or Radio. And I'm sure we feel the same way about that through allstar.
By the way some of you guys are interpreting this, the iPhone and Android apps and/or repeater to repeater echolink connects and PC to PC echolink connects would not be legal to them.
Has anyone ever asked them to clarify the statement? Please tell us/me "exactly" what they said !
If nobody answers that, perhaps one of us needs to ask them so we can set the record straight as most of us use it on our systems and left unanswered definitively, this will come up many more times.
And perhaps a text of a definitive rule could be included as a default comment in the echolink.conf so there is no ignorance of what they expect if you use it.
Bob (kk6ecm), you win the prize since you asked the question from the email you received.
Would you Send them a message/reply to clarify the type of connections "by example" they do not want and ask they not use the text from the email that you do not understand ? or what type of VoIP connections they are speaking of exactly.
Sure would put a end to the silliness of it time and time again.
I think what leads folks to get one of those emails is basically a list report of connected systems when a breach has been noticed. Problem is, they have a security problem with some of the proxies on their system. I have seen many a connect through a echo-proxy without an ID (callsign) and more. I don't think anyone could ever know it's true source. Hence the poorly worded generic email notice to all connected systems and obviously, they are not familiar with the other systems to word it correctly.
Sorry to be long winded, but I don't want to this get elevated again without good reason.
...mike/kb8jnm
-------- Original Message -------- Subject: Re: [App_rpt-users] Echolink and app_rpt: Looking for more information on permit=*-* From: Doug Crompton <doug@crompton.com> Date: Wed, November 12, 2014 1:13 am To: "app_rpt-users@ohnosec.org" <app_rpt-users@ohnosec.org>
Mike,
I am going to break my own rule and respond here! I don't think you are interpreting there statement correctly...
They say....
"If you are running Asterisk with app_rpt and an EchoLink channel, be sure it is configured not to allow other VoIP connections when an EchoLink station is connected."
They go on to specifically prohibit connections to Allstar, Wires, and many others is not to be connected to Echolink. Bottom line is they think their validation process is better than ours or others. I say we police it just fine. A non ham popping up would stick out like a sore thumb.
Bottom line they don't want us connected. In other words they want it like IRLP with echolink. You can either connect to a echolink station or an IRLP node, NOT both at the same time.
My assertion still stands, ignore it but on the other hand like any good ham make sure you police the activity on your nodes. There is no way to practically isolate echolink from Allstar unless you somehow disconnect all allstar nodes when an echolink call comes in and this would be crazy to do.
73 Doug WA3DSP http://www.crompton.com/hamradio
From: mike@midnighteng.com To: App_rpt-users@ohnosec.org Date: Tue, 11 Nov 2014 21:15:26 -0700 Subject: Re: [App_rpt-users] Echolink and app_rpt: Looking for more information on permit=*-*
Like many times before you, you don't seem to understand their statement. So nobody needs to go off on a tangent again.
You only need to be concerned if you do something like "have a web portal to your system that has no limitation to who uses it" (as in non-hams).
If you do then they have the possibility to use the echolink system through your system and that is what they do not want.
Neither do we with allstar or via radio. I'm sure there are a few bad actors out there somewhere allowing access. just make sure it is not you.
They could use better wording to keep the confusion/fuss down.
As far as permit or deny... permit= a list that only allows calls you place in the list to connect. deny= a list of calls that can not connect. See the drupal site for info.
...mike/kb8jnm -------- Original Message -------- Subject: [App_rpt-users] Echolink and app_rpt: Looking for more information on permit=*-* From: "Bob" <kk6ecm@gmail.com> Date: Tue, November 11, 2014 10:13 pm To: <App_rpt-users@ohnosec.org>
OK... Echolink quality aside, I’m looking for some clarification how app_rpt works with Echolink.
Attempting to understand the statement from Echolink, “If you are running Asterisk with app_rpt and an EchoLink channel, be sure it is configured not to allow other VoIP connections when an EchoLink station is connected. If this isn't practical, please disable the EchoLink channel.” It seems that “other VoIP” means non-Echolink nodes; not sure how Allstar can do this.
How does permit=*-* (“prohibit computer-based connections”) work with an incoming Echolink computer based node, or with an app_rpt hosted Echolink node in an Echolink to Echolink configuration. When the user enters *33 to connect, is it actually Echolink nodes connecting, or is there a difference?
I think I get their point they don’t want an Allstar node with Echolink node, to simultaneously connect to another Allstar node that does not support Echolink, but not sure why... still licensed amateurs involved.
I am dismayed with Echolink’s assertion that the use of a copy of a paper license is more official than the FCC recognized ULS site, which it appears Allstarlink.org uses to validate the users license.
Thanks, Bob kk6ecm _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
I removed EchoLink. In it’s place we need some smart mobile developer to write a iPhone/Android IAX client with PTT. Anyone???? For now we’re using Zoiper. It’s a bit clunky as you have to do *99 to make PTT and # to unkey. The lack of PTT indication is disconcerting and problematic but it works. The audio is 3,000 times better than EchoLink. And you have control of who connects. Here’s how you set up the node. In iax.conf add this stanza. Change UserID and UserPassword. [UserID] username=UserID type=friend context=hams host=dynamic auth=md5 secret=UserPassword disallow=all allow=ulaw allow=g726aal2 allow=gsm codecpriority=host transfer=no In extensions.conf add this stanza. This requires a caller ID or it will not connect. I have my users put their call sign in the caller ID. That way the status pages (including Allmon) shows who is connected with a -P appended. [hams] exten => _X!,1,Ringing exten => _X!,n,NoOp(${CALLERID(name)}) exten => _X!,n,NoOp(${CALLERID(number)}) exten => _X!,n,Set(CALLSIGN=${CALLERID(name)}) exten => _X!,n,GotoIf($[${LEN(${CALLSIGN})} = 0]?hangit) exten => _X!,n,Wait(3) exten => _X!,n,Answer exten => _X!,n,Playback(connecting) exten => _X!,n,rpt(${EXTEN}|P|${CALLSIGN}-P) exten => _X!,n(hangit),Answer exten => _X!,n(hangit),Playback(connection-failed) exten => _X!,n(hangit),Wait(1) exten => _X!,n(hangit),Hangup -- Tim WD6AWP
On Nov 12, 2014, at 5:46 AM, Bryan D. Boyle <bdboyle@bdboyle.com> wrote:
simple solution, considering the clueless majority of users in the Echolink world, the lousy audio codecs, and the ancient technology that has not kept pace with either praxis or software advances: turn the damn thing off.
You won't miss the drive-bys, distorted computer audio, fumble-fingered operators, and bandwidth usage.
It's just so not worth the effort to maintain, worry about the software and technology use conditions, or anything else surrounding it. It's just amateur radio, not the launch codes.
</grump>
-- Bryan Sent from my iPhone 5...No electrons were harmed in the sending of this message.
On Nov 12, 2014, at 06:36, <mike@midnighteng.com <mailto:mike@midnighteng.com>> <mike@midnighteng.com <mailto:mike@midnighteng.com>> wrote:
Additional info (as if the first was not enough)...
I went to their (echolink) website looking for a rule...
Here it is...
Item #4 Stations operating in Sysop mode may interconnect EchoLink only with equipment operating on Amateur frequencies. EchoLink does not permit use of the system with other services such as GMRS, FRS, or MARS. For security reasons, it is also not permitted to interconnect EchoLink with other VoIP systems that support direct access from a computer.
found on their access policy page at...
echolink.org/access_policies.htm <http://echolink.org/access_policies.htm>
There is no mention of other systems interconnect, just the VoIP via computer direct. I take the meaning of direct to mean "unverified" or unrestricted. This is consistent with the way I have been reading the poorly written emails some of you get from echolink.
...mike/kb8jnm
-------- Original Message -------- Subject: Re: [App_rpt-users] Echolink_and_app_rpt:_Looking_for_m ore_information_on_permit=*-* From: <mike@midnighteng.com <mailto:mike@midnighteng.com>> Date: Wed, November 12, 2014 5:28 am To: app_rpt-users@ohnosec.org <mailto:app_rpt-users@ohnosec.org>, "Bob" <kk6ecm@gmail.com <mailto:kk6ecm@gmail.com>>
Bob, Doug and all,
I fully understand why you would think that. It is so poorly written. And as I have watched this conversation get out of hand at least 2 times as you have Doug.
This is the first time I thought I would clarify how I was reading their email statement before anyone gets elevated on it again.
other VoIP connections not Radio Sourced RoIP connections and only if you can't verify the VoIP.
They are saying VOIP connections from non-radio sources...ie phone and web portal without a security check. I have many non-experimental phone and web ports but nobody knows what it is so it is not a open port. I don't provide links to it from a web page or post a phone number and it "does" have multilevel security checks. Even if folks stumbled on it by accident or not, they would not have open access.
There are a lot of folks experimenting with asterisk side of the set-up. Many of us that have been using asterisk for many years know that we can port just about any kind of streaming audio or other services to asterisk and thereby app_rpt. Hard to tell what interfaces/ports are open on them and to where they go. Because some folks don't think about the implications of their actions, things happen. We all know that even from the radio side of the equation.
Problems can also occur if a unauthorized station/system is connected to others who are connected to you and there is no way to track that on the echolink side.
They are asking that when "you" have a open port like that (unverified VoIP), to disable the echolink port while it is active so a unverified user does not get access to echolink through VoIP, not RoIP or Radio. And I'm sure we feel the same way about that through allstar.
By the way some of you guys are interpreting this, the iPhone and Android apps and/or repeater to repeater echolink connects and PC to PC echolink connects would not be legal to them.
Has anyone ever asked them to clarify the statement? Please tell us/me "exactly" what they said !
If nobody answers that, perhaps one of us needs to ask them so we can set the record straight as most of us use it on our systems and left unanswered definitively, this will come up many more times.
And perhaps a text of a definitive rule could be included as a default comment in the echolink.conf so there is no ignorance of what they expect if you use it.
Bob (kk6ecm), you win the prize since you asked the question from the email you received.
Would you Send them a message/reply to clarify the type of connections "by example" they do not want and ask they not use the text from the email that you do not understand ? or what type of VoIP connections they are speaking of exactly.
Sure would put a end to the silliness of it time and time again.
I think what leads folks to get one of those emails is basically a list report of connected systems when a breach has been noticed. Problem is, they have a security problem with some of the proxies on their system. I have seen many a connect through a echo-proxy without an ID (callsign) and more. I don't think anyone could ever know it's true source. Hence the poorly worded generic email notice to all connected systems and obviously, they are not familiar with the other systems to word it correctly.
Sorry to be long winded, but I don't want to this get elevated again without good reason.
...mike/kb8jnm
-------- Original Message -------- Subject: Re: [App_rpt-users] Echolink and app_rpt: Looking for more information on permit=*-* From: Doug Crompton <doug@crompton.com <mailto:doug@crompton.com>> Date: Wed, November 12, 2014 1:13 am To: "app_rpt-users@ohnosec.org <mailto:app_rpt-users@ohnosec.org>" <app_rpt-users@ohnosec.org <mailto:app_rpt-users@ohnosec.org>>
Mike,
I am going to break my own rule and respond here! I don't think you are interpreting there statement correctly...
They say....
"If you are running Asterisk with app_rpt and an EchoLink channel, be sure it is configured not to allow other VoIP connections when an EchoLink station is connected."
They go on to specifically prohibit connections to Allstar, Wires, and many others is not to be connected to Echolink. Bottom line is they think their validation process is better than ours or others. I say we police it just fine. A non ham popping up would stick out like a sore thumb.
Bottom line they don't want us connected. In other words they want it like IRLP with echolink. You can either connect to a echolink station or an IRLP node, NOT both at the same time.
My assertion still stands, ignore it but on the other hand like any good ham make sure you police the activity on your nodes. There is no way to practically isolate echolink from Allstar unless you somehow disconnect all allstar nodes when an echolink call comes in and this would be crazy to do.
73 Doug WA3DSP http://www.crompton.com/hamradio <http://www.crompton.com/hamradio>
From: mike@midnighteng.com <mailto:mike@midnighteng.com> To: App_rpt-users@ohnosec.org <mailto:App_rpt-users@ohnosec.org> Date: Tue, 11 Nov 2014 21:15:26 -0700 Subject: Re: [App_rpt-users] Echolink and app_rpt: Looking for more information on permit=*-*
Like many times before you, you don't seem to understand their statement. So nobody needs to go off on a tangent again.
You only need to be concerned if you do something like "have a web portal to your system that has no limitation to who uses it" (as in non-hams).
If you do then they have the possibility to use the echolink system through your system and that is what they do not want.
Neither do we with allstar or via radio. I'm sure there are a few bad actors out there somewhere allowing access. just make sure it is not you.
They could use better wording to keep the confusion/fuss down.
As far as permit or deny... permit= a list that only allows calls you place in the list to connect. deny= a list of calls that can not connect. See the drupal site for info.
...mike/kb8jnm -------- Original Message -------- Subject: [App_rpt-users] Echolink and app_rpt: Looking for more information on permit=*-* From: "Bob" <kk6ecm@gmail.com <mailto:kk6ecm@gmail.com>> Date: Tue, November 11, 2014 10:13 pm To: <App_rpt-users@ohnosec.org <mailto:App_rpt-users@ohnosec.org>>
OK... Echolink quality aside, I’m looking for some clarification how app_rpt works with Echolink.
Attempting to understand the statement from Echolink, “If you are running Asterisk with app_rpt and an EchoLink channel, be sure it is configured not to allow other VoIP connections when an EchoLink station is connected. If this isn't practical, please disable the EchoLink channel.” It seems that “other VoIP” means non-Echolink nodes; not sure how Allstar can do this.
How does permit=*-* (“prohibit computer-based connections”) work with an incoming Echolink computer based node, or with an app_rpt hosted Echolink node in an Echolink to Echolink configuration. When the user enters *33 to connect, is it actually Echolink nodes connecting, or is there a difference?
I think I get their point they don’t want an Allstar node with Echolink node, to simultaneously connect to another Allstar node that does not support Echolink, but not sure why... still licensed amateurs involved.
I am dismayed with Echolink’s assertion that the use of a copy of a paper license is more official than the FCC recognized ULS site, which it appears Allstarlink.org <http://allstarlink.org/> uses to validate the users license.
Thanks, Bob kk6ecm _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org <mailto:App_rpt-users@ohnosec.org> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users <http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users>
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users <http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users> and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org <mailto:App_rpt-users@ohnosec.org> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users <http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users> To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users <http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users> and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org <mailto:App_rpt-users@ohnosec.org> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users <http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users>
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users <http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users> and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org <mailto:App_rpt-users@ohnosec.org> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users <http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users>
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users <http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users> and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org <mailto:App_rpt-users@ohnosec.org> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users <http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users>
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users <http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users> and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org <mailto:App_rpt-users@ohnosec.org> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users <http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users>
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users <http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users> and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
Hey guys, I’m not a programmer, and I didn’t stay at a HI Express last night, so I have to ask: are the volume buttons on smart phones hard wired to that function? Or can one be made to be a PTT function? Just set volume at max smoke, or make the other button step/cycle thru 8 preset volume levels? I really envy you guys who can write this stuff. Most I ever did was a HF remote controller using 6502 assembler. GeorgeC George J Csahanin W2DB Cedar Park, TX 512-401-2630 home 401-338-0568 cel From: Tim Sawyer Sent: Wednesday, November 12, 2014 8:51 AM To: Bryan D. Boyle Cc: app_rpt mailing list Subject: Re: [App_rpt-users] Echolink_and_app_rpt:_Looking_for_m ore_information_on_permit=*-* I removed EchoLink. In it’s place we need some smart mobile developer to write a iPhone/Android IAX client with PTT. Anyone???? For now we’re using Zoiper. It’s a bit clunky as you have to do *99 to make PTT and # to unkey. The lack of PTT indication is disconcerting and problematic but it works. The audio is 3,000 times better than EchoLink. And you have control of who connects. Here’s how you set up the node. In iax.conf add this stanza. Change UserID and UserPassword. [UserID] username=UserID type=friend context=hams host=dynamic auth=md5 secret=UserPassword disallow=all allow=ulaw allow=g726aal2 allow=gsm codecpriority=host transfer=no In extensions.conf add this stanza. This requires a caller ID or it will not connect. I have my users put their call sign in the caller ID. That way the status pages (including Allmon) shows who is connected with a -P appended. [hams] exten => _X!,1,Ringing exten => _X!,n,NoOp(${CALLERID(name)}) exten => _X!,n,NoOp(${CALLERID(number)}) exten => _X!,n,Set(CALLSIGN=${CALLERID(name)}) exten => _X!,n,GotoIf($[${LEN(${CALLSIGN})} = 0]?hangit) exten => _X!,n,Wait(3) exten => _X!,n,Answer exten => _X!,n,Playback(connecting) exten => _X!,n,rpt(${EXTEN}|P|${CALLSIGN}-P) exten => _X!,n(hangit),Answer exten => _X!,n(hangit),Playback(connection-failed) exten => _X!,n(hangit),Wait(1) exten => _X!,n(hangit),Hangup -- Tim WD6AWP On Nov 12, 2014, at 5:46 AM, Bryan D. Boyle <bdboyle@bdboyle.com> wrote: simple solution, considering the clueless majority of users in the Echolink world, the lousy audio codecs, and the ancient technology that has not kept pace with either praxis or software advances: turn the damn thing off. You won't miss the drive-bys, distorted computer audio, fumble-fingered operators, and bandwidth usage. It's just so not worth the effort to maintain, worry about the software and technology use conditions, or anything else surrounding it. It's just amateur radio, not the launch codes. </grump> -- Bryan Sent from my iPhone 5...No electrons were harmed in the sending of this message. On Nov 12, 2014, at 06:36, <mike@midnighteng.com> <mike@midnighteng.com> wrote: Additional info (as if the first was not enough)... I went to their (echolink) website looking for a rule... Here it is... Item #4 Stations operating in Sysop mode may interconnect EchoLink only with equipment operating on Amateur frequencies. EchoLink does not permit use of the system with other services such as GMRS, FRS, or MARS. For security reasons, it is also not permitted to interconnect EchoLink with other VoIP systems that support direct access from a computer. found on their access policy page at... echolink.org/access_policies.htm There is no mention of other systems interconnect, just the VoIP via computer direct. I take the meaning of direct to mean "unverified" or unrestricted. This is consistent with the way I have been reading the poorly written emails some of you get from echolink. ...mike/kb8jnm -------- Original Message -------- Subject: Re: [App_rpt-users] Echolink_and_app_rpt:_Looking_for_m ore_information_on_permit=*-* From: <mike@midnighteng.com> Date: Wed, November 12, 2014 5:28 am To: app_rpt-users@ohnosec.org, "Bob" <kk6ecm@gmail.com> Bob, Doug and all, I fully understand why you would think that. It is so poorly written. And as I have watched this conversation get out of hand at least 2 times as you have Doug. This is the first time I thought I would clarify how I was reading their email statement before anyone gets elevated on it again. other VoIP connections not Radio Sourced RoIP connections and only if you can't verify the VoIP. They are saying VOIP connections from non-radio sources...ie phone and web portal without a security check. I have many non-experimental phone and web ports but nobody knows what it is so it is not a open port. I don't provide links to it from a web page or post a phone number and it "does" have multilevel security checks. Even if folks stumbled on it by accident or not, they would not have open access. There are a lot of folks experimenting with asterisk side of the set-up. Many of us that have been using asterisk for many years know that we can port just about any kind of streaming audio or other services to asterisk and thereby app_rpt. Hard to tell what interfaces/ports are open on them and to where they go. Because some folks don't think about the implications of their actions, things happen. We all know that even from the radio side of the equation. Problems can also occur if a unauthorized station/system is connected to others who are connected to you and there is no way to track that on the echolink side. They are asking that when "you" have a open port like that (unverified VoIP), to disable the echolink port while it is active so a unverified user does not get access to echolink through VoIP, not RoIP or Radio. And I'm sure we feel the same way about that through allstar. By the way some of you guys are interpreting this, the iPhone and Android apps and/or repeater to repeater echolink connects and PC to PC echolink connects would not be legal to them. Has anyone ever asked them to clarify the statement? Please tell us/me "exactly" what they said ! If nobody answers that, perhaps one of us needs to ask them so we can set the record straight as most of us use it on our systems and left unanswered definitively, this will come up many more times. And perhaps a text of a definitive rule could be included as a default comment in the echolink.conf so there is no ignorance of what they expect if you use it. Bob (kk6ecm), you win the prize since you asked the question from the email you received. Would you Send them a message/reply to clarify the type of connections "by example" they do not want and ask they not use the text from the email that you do not understand ? or what type of VoIP connections they are speaking of exactly. Sure would put a end to the silliness of it time and time again. I think what leads folks to get one of those emails is basically a list report of connected systems when a breach has been noticed. Problem is, they have a security problem with some of the proxies on their system. I have seen many a connect through a echo-proxy without an ID (callsign) and more. I don't think anyone could ever know it's true source. Hence the poorly worded generic email notice to all connected systems and obviously, they are not familiar with the other systems to word it correctly. Sorry to be long winded, but I don't want to this get elevated again without good reason. ...mike/kb8jnm -------- Original Message -------- Subject: Re: [App_rpt-users] Echolink and app_rpt: Looking for more information on permit=*-* From: Doug Crompton <doug@crompton.com> Date: Wed, November 12, 2014 1:13 am To: "app_rpt-users@ohnosec.org" <app_rpt-users@ohnosec.org> Mike, I am going to break my own rule and respond here! I don't think you are interpreting there statement correctly... They say.... "If you are running Asterisk with app_rpt and an EchoLink channel, be sure it is configured not to allow other VoIP connections when an EchoLink station is connected." They go on to specifically prohibit connections to Allstar, Wires, and many others is not to be connected to Echolink. Bottom line is they think their validation process is better than ours or others. I say we police it just fine. A non ham popping up would stick out like a sore thumb. Bottom line they don't want us connected. In other words they want it like IRLP with echolink. You can either connect to a echolink station or an IRLP node, NOT both at the same time. My assertion still stands, ignore it but on the other hand like any good ham make sure you police the activity on your nodes. There is no way to practically isolate echolink from Allstar unless you somehow disconnect all allstar nodes when an echolink call comes in and this would be crazy to do. 73 Doug WA3DSP http://www.crompton.com/hamradio ------------------------------------------------------------------------ From: mike@midnighteng.com To: App_rpt-users@ohnosec.org Date: Tue, 11 Nov 2014 21:15:26 -0700 Subject: Re: [App_rpt-users] Echolink and app_rpt: Looking for more information on permit=*-* Like many times before you, you don't seem to understand their statement. So nobody needs to go off on a tangent again. You only need to be concerned if you do something like "have a web portal to your system that has no limitation to who uses it" (as in non-hams). If you do then they have the possibility to use the echolink system through your system and that is what they do not want. Neither do we with allstar or via radio. I'm sure there are a few bad actors out there somewhere allowing access. just make sure it is not you. They could use better wording to keep the confusion/fuss down. As far as permit or deny... permit= a list that only allows calls you place in the list to connect. deny= a list of calls that can not connect. See the drupal site for info. ...mike/kb8jnm -------- Original Message -------- Subject: [App_rpt-users] Echolink and app_rpt: Looking for more information on permit=*-* From: "Bob" <kk6ecm@gmail.com> Date: Tue, November 11, 2014 10:13 pm To: <App_rpt-users@ohnosec.org> OK... Echolink quality aside, I’m looking for some clarification how app_rpt works with Echolink. Attempting to understand the statement from Echolink, “If you are running Asterisk with app_rpt and an EchoLink channel, be sure it is configured not to allow other VoIP connections when an EchoLink station is connected. If this isn't practical, please disable the EchoLink channel.” It seems that “other VoIP” means non-Echolink nodes; not sure how Allstar can do this. How does permit=*-* (“prohibit computer-based connections”) work with an incoming Echolink computer based node, or with an app_rpt hosted Echolink node in an Echolink to Echolink configuration. When the user enters *33 to connect, is it actually Echolink nodes connecting, or is there a difference? I think I get their point they don’t want an Allstar node with Echolink node, to simultaneously connect to another Allstar node that does not support Echolink, but not sure why... still licensed amateurs involved. I am dismayed with Echolink’s assertion that the use of a copy of a paper license is more official than the FCC recognized ULS site, which it appears Allstarlink.org uses to validate the users license. Thanks, Bob kk6ecm ---------------------------------------------------------------------- _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. ------------------------------------------------------------------------ _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. -------------------------------------------------------------------------- _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
The iPhone has the use of the volume button as a camera, i don't know of any apple approved apps that would do that but a jailbreak cydia tweak may be something to look into.
On Nov 12, 2014, at 6:46 PM, George Csahanin <george@dyb.com> wrote:
Hey guys, I’m not a programmer, and I didn’t stay at a HI Express last night, so I have to ask: are the volume buttons on smart phones hard wired to that function? Or can one be made to be a PTT function? Just set volume at max smoke, or make the other button step/cycle thru 8 preset volume levels? I really envy you guys who can write this stuff. Most I ever did was a HF remote controller using 6502 assembler.
GeorgeC
George J Csahanin W2DB Cedar Park, TX 512-401-2630 home 401-338-0568 cel
From: Tim Sawyer Sent: Wednesday, November 12, 2014 8:51 AM To: Bryan D. Boyle Cc: app_rpt mailing list Subject: Re: [App_rpt-users] Echolink_and_app_rpt:_Looking_for_m ore_information_on_permit=*-*
I removed EchoLink. In it’s place we need some smart mobile developer to write a iPhone/Android IAX client with PTT. Anyone????
For now we’re using Zoiper. It’s a bit clunky as you have to do *99 to make PTT and # to unkey. The lack of PTT indication is disconcerting and problematic but it works. The audio is 3,000 times better than EchoLink. And you have control of who connects. Here’s how you set up the node.
In iax.conf add this stanza. Change UserID and UserPassword.
[UserID] username=UserID type=friend context=hams host=dynamic auth=md5 secret=UserPassword disallow=all allow=ulaw allow=g726aal2 allow=gsm codecpriority=host transfer=no
In extensions.conf add this stanza. This requires a caller ID or it will not connect. I have my users put their call sign in the caller ID. That way the status pages (including Allmon) shows who is connected with a -P appended.
[hams] exten => _X!,1,Ringing exten => _X!,n,NoOp(${CALLERID(name)}) exten => _X!,n,NoOp(${CALLERID(number)}) exten => _X!,n,Set(CALLSIGN=${CALLERID(name)}) exten => _X!,n,GotoIf($[${LEN(${CALLSIGN})} = 0]?hangit) exten => _X!,n,Wait(3) exten => _X!,n,Answer exten => _X!,n,Playback(connecting) exten => _X!,n,rpt(${EXTEN}|P|${CALLSIGN}-P) exten => _X!,n(hangit),Answer exten => _X!,n(hangit),Playback(connection-failed) exten => _X!,n(hangit),Wait(1) exten => _X!,n(hangit),Hangup
-- Tim WD6AWP
On Nov 12, 2014, at 5:46 AM, Bryan D. Boyle <bdboyle@bdboyle.com> wrote:
simple solution, considering the clueless majority of users in the Echolink world, the lousy audio codecs, and the ancient technology that has not kept pace with either praxis or software advances: turn the damn thing off.
You won't miss the drive-bys, distorted computer audio, fumble-fingered operators, and bandwidth usage.
It's just so not worth the effort to maintain, worry about the software and technology use conditions, or anything else surrounding it. It's just amateur radio, not the launch codes.
</grump>
-- Bryan Sent from my iPhone 5...No electrons were harmed in the sending of this message.
On Nov 12, 2014, at 06:36, <mike@midnighteng.com> <mike@midnighteng.com> wrote:
Additional info (as if the first was not enough)...
I went to their (echolink) website looking for a rule...
Here it is...
Item #4 Stations operating in Sysop mode may interconnect EchoLink only with equipment operating on Amateur frequencies. EchoLink does not permit use of the system with other services such as GMRS, FRS, or MARS. For security reasons, it is also not permitted to interconnect EchoLink with other VoIP systems that support direct access from a computer.
found on their access policy page at...
echolink.org/access_policies.htm
There is no mention of other systems interconnect, just the VoIP via computer direct. I take the meaning of direct to mean "unverified" or unrestricted. This is consistent with the way I have been reading the poorly written emails some of you get from echolink.
...mike/kb8jnm
-------- Original Message -------- Subject: Re: [App_rpt-users] Echolink_and_app_rpt:_Looking_for_m ore_information_on_permit=*-* From: <mike@midnighteng.com> Date: Wed, November 12, 2014 5:28 am To: app_rpt-users@ohnosec.org, "Bob" <kk6ecm@gmail.com>
Bob, Doug and all,
I fully understand why you would think that. It is so poorly written. And as I have watched this conversation get out of hand at least 2 times as you have Doug.
This is the first time I thought I would clarify how I was reading their email statement before anyone gets elevated on it again.
other VoIP connections not Radio Sourced RoIP connections and only if you can't verify the VoIP.
They are saying VOIP connections from non-radio sources...ie phone and web portal without a security check. I have many non-experimental phone and web ports but nobody knows what it is so it is not a open port. I don't provide links to it from a web page or post a phone number and it "does" have multilevel security checks. Even if folks stumbled on it by accident or not, they would not have open access.
There are a lot of folks experimenting with asterisk side of the set-up. Many of us that have been using asterisk for many years know that we can port just about any kind of streaming audio or other services to asterisk and thereby app_rpt. Hard to tell what interfaces/ports are open on them and to where they go. Because some folks don't think about the implications of their actions, things happen. We all know that even from the radio side of the equation.
Problems can also occur if a unauthorized station/system is connected to others who are connected to you and there is no way to track that on the echolink side.
They are asking that when "you" have a open port like that (unverified VoIP), to disable the echolink port while it is active so a unverified user does not get access to echolink through VoIP, not RoIP or Radio. And I'm sure we feel the same way about that through allstar.
By the way some of you guys are interpreting this, the iPhone and Android apps and/or repeater to repeater echolink connects and PC to PC echolink connects would not be legal to them.
Has anyone ever asked them to clarify the statement? Please tell us/me "exactly" what they said !
If nobody answers that, perhaps one of us needs to ask them so we can set the record straight as most of us use it on our systems and left unanswered definitively, this will come up many more times.
And perhaps a text of a definitive rule could be included as a default comment in the echolink.conf so there is no ignorance of what they expect if you use it.
Bob (kk6ecm), you win the prize since you asked the question from the email you received.
Would you Send them a message/reply to clarify the type of connections "by example" they do not want and ask they not use the text from the email that you do not understand ? or what type of VoIP connections they are speaking of exactly.
Sure would put a end to the silliness of it time and time again.
I think what leads folks to get one of those emails is basically a list report of connected systems when a breach has been noticed. Problem is, they have a security problem with some of the proxies on their system. I have seen many a connect through a echo-proxy without an ID (callsign) and more. I don't think anyone could ever know it's true source. Hence the poorly worded generic email notice to all connected systems and obviously, they are not familiar with the other systems to word it correctly.
Sorry to be long winded, but I don't want to this get elevated again without good reason.
...mike/kb8jnm
-------- Original Message -------- Subject: Re: [App_rpt-users] Echolink and app_rpt: Looking for more information on permit=*-* From: Doug Crompton <doug@crompton.com> Date: Wed, November 12, 2014 1:13 am To: "app_rpt-users@ohnosec.org" <app_rpt-users@ohnosec.org>
Mike,
I am going to break my own rule and respond here! I don't think you are interpreting there statement correctly...
They say....
"If you are running Asterisk with app_rpt and an EchoLink channel, be sure it is configured not to allow other VoIP connections when an EchoLink station is connected."
They go on to specifically prohibit connections to Allstar, Wires, and many others is not to be connected to Echolink. Bottom line is they think their validation process is better than ours or others. I say we police it just fine. A non ham popping up would stick out like a sore thumb.
Bottom line they don't want us connected. In other words they want it like IRLP with echolink. You can either connect to a echolink station or an IRLP node, NOT both at the same time.
My assertion still stands, ignore it but on the other hand like any good ham make sure you police the activity on your nodes. There is no way to practically isolate echolink from Allstar unless you somehow disconnect all allstar nodes when an echolink call comes in and this would be crazy to do.
73 Doug WA3DSP http://www.crompton.com/hamradio
From: mike@midnighteng.com To: App_rpt-users@ohnosec.org Date: Tue, 11 Nov 2014 21:15:26 -0700 Subject: Re: [App_rpt-users] Echolink and app_rpt: Looking for more information on permit=*-*
Like many times before you, you don't seem to understand their statement. So nobody needs to go off on a tangent again.
You only need to be concerned if you do something like "have a web portal to your system that has no limitation to who uses it" (as in non-hams).
If you do then they have the possibility to use the echolink system through your system and that is what they do not want.
Neither do we with allstar or via radio. I'm sure there are a few bad actors out there somewhere allowing access. just make sure it is not you.
They could use better wording to keep the confusion/fuss down.
As far as permit or deny... permit= a list that only allows calls you place in the list to connect. deny= a list of calls that can not connect. See the drupal site for info.
...mike/kb8jnm -------- Original Message -------- Subject: [App_rpt-users] Echolink and app_rpt: Looking for more information on permit=*-* From: "Bob" <kk6ecm@gmail.com> Date: Tue, November 11, 2014 10:13 pm To: <App_rpt-users@ohnosec.org>
OK... Echolink quality aside, I’m looking for some clarification how app_rpt works with Echolink.
Attempting to understand the statement from Echolink, “If you are running Asterisk with app_rpt and an EchoLink channel, be sure it is configured not to allow other VoIP connections when an EchoLink station is connected. If this isn't practical, please disable the EchoLink channel.” It seems that “other VoIP” means non-Echolink nodes; not sure how Allstar can do this.
How does permit=*-* (“prohibit computer-based connections”) work with an incoming Echolink computer based node, or with an app_rpt hosted Echolink node in an Echolink to Echolink configuration. When the user enters *33 to connect, is it actually Echolink nodes connecting, or is there a difference?
I think I get their point they don’t want an Allstar node with Echolink node, to simultaneously connect to another Allstar node that does not support Echolink, but not sure why... still licensed amateurs involved.
I am dismayed with Echolink’s assertion that the use of a copy of a paper license is more official than the FCC recognized ULS site, which it appears Allstarlink.org uses to validate the users license.
Thanks, Bob kk6ecm _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
Why does every link hate each other? IRLP hates Allstar, just because it can go through a phone and they want to keep the radio to it. Echolink now taken Allstar off its policy because of some "security issues" Allstar users dislike echolink because of the poor audio quality Isn't ham radio just for two way communication, whatever the most effecient way you can contact someone during an emergency should be prioritized. As time progresses, more and more Allstar nodes are becoming private in my area, and I can't connect to some places I used to have great friends on the systems. Can't we just get along? If a friend built an IRLP node far away, why can't someone talk to him, just because they have a system with more linking capabilities? During a disaster, an IRLP node on one side of the state should be able to connect to an Allstar node on another if communications are mandatory. The same goes toward Allstar users, people who come in through echolink and troll around will do just the same through something like the web transceiver if echolink gets shut off. And who says someone without a liscense can't buy a cheap BAOFENG on amazon for 40 bucks and troll around on any link system near them? We're radio amateurs, we know nothing is perfect, can't we work as a team to try to enhance two way communication as best as possible? HF is not limited by the brand radio you have. Skyler kd0whb
Skyler, You are absolutely right, there is no reason for the turf wars other than politics and peoples egos. I don't think that Allstar has a policy against anything other than abiding by legal amateur radio practices and I think we police our networks well. You often hear the echolink audio quality statements on Allstar and in most cases it is true. Echolink originating on PC's with all kinds of crazy microphone arrangements often leads to bizarre and distorted audio. I have found that iphones, ipads, and other phones seems to work well and produce some of the best echolink audio. Even though we complain about it we still have an open policy on our end and welcome any and all (FCC) legal experimentation on our networks with any other digital format. The reason Allstar is more open is because it is open source software not owned by anyone and for the most part not controlled but a private individual or group. Yes there are databases, webpage, software repsoitory maintained by individuals that freely give their time to do that but if one wanted to setup their own database and start another network they could. I am certainly not advocating that just using it as an example. Of course you could start another completely different amateur VOIP network also. That is how all these were born in the first place. Someone had an idea and ran with it. As for people going "private" on Allstar well that is their prerogative. Often it is done because it is a link or specific repeater system. That is the beauty of Allstar, you can configure it, add to it, change it, use it any way you like. I think there are more individual Allstar nodes recently coming online with the advent of the BBB and most are not private. Both IRLP and Echolink are not open source and the code and networks are tightly controlled although they have very different philosophies. Echolink claims to have superior control of keeping non-hams off the network. I really think this is a non-issue because I have not seen this problem on any network and when it does happen it is quickly taken care of. Echolink is probably 75% or more computer to computer. Echolink is really more like an amateur radio only Teamviewer or Skype although both of them have better audio quality. To me IRLP is just bizarre in how it works and although I did use it I quickly realized it was not for me. It is run by one individual who (I guess) makes money on it as you have to buy a board from him before he assigns you a node number. It also has the policy of NO non-radio connections thus the beef with Allstar, although I think there was probably more to that though than the radio only issue. IRLP also is half duplex and only allows one connection at a time. They do have what they call reflectors that are special servers setup with the permission of Mr. IRLP which allow multiple connections. These reflectors become like repeaters, often very political with a single administrator that sets the rules, how long you can talk, who can connect, etc. Totally unlike Allstar's operation or philosophy. Today, in the real world these systems are often interconnected even though IRLP and now Echolink claim to be autonomous networks. The Alaska Morning net which is on for 2 hours 6 days a week is a prime example where Allstar, IRLP, and Echolink are interconnected and there are many others. And again I will repeat, as long as we are responsible, FCC rule abiding hams I don't think these interconnections are a problem and I am sure they will go on. This issue could be discussed to death and like politics and religion there will never be a consensus. These interconnection problems are not unique to amateur radio as everytime we have a disaster you always hear about one government agency not being able to talk to another because of radio systems not being compatible and it often boils down to a political (people) problem rather than an equipment problem. I think it is called life, why can't we all get along! 73 Doug WA3DSP http://www.crompton.com/hamradio
From: electricity440@gmail.com Date: Thu, 13 Nov 2014 22:20:03 -0700 To: app_rpt-users@ohnosec.org Subject: Re: [App_rpt-users] Echolink_and_app_rpt:_Looking_for_m ore_information_on_permit=*-*
Why does every link hate each other?
IRLP hates Allstar, just because it can go through a phone and they want to keep the radio to it.
Echolink now taken Allstar off its policy because of some "security issues"
Allstar users dislike echolink because of the poor audio quality
Isn't ham radio just for two way communication, whatever the most effecient way you can contact someone during an emergency should be prioritized.
As time progresses, more and more Allstar nodes are becoming private in my area, and I can't connect to some places I used to have great friends on the systems.
Can't we just get along? If a friend built an IRLP node far away, why can't someone talk to him, just because they have a system with more linking capabilities?
During a disaster, an IRLP node on one side of the state should be able to connect to an Allstar node on another if communications are mandatory.
The same goes toward Allstar users, people who come in through echolink and troll around will do just the same through something like the web transceiver if echolink gets shut off. And who says someone without a liscense can't buy a cheap BAOFENG on amazon for 40 bucks and troll around on any link system near them?
We're radio amateurs, we know nothing is perfect, can't we work as a team to try to enhance two way communication as best as possible?
HF is not limited by the brand radio you have.
Skyler kd0whb
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
participants (6)
-
Bryan D. Boyle -
Doug Crompton -
George Csahanin -
mike＠midnighteng.com -
Skyler Fennell -
Tim Sawyer