[App_rpt-users] Echolink_and_app_rpt:_Looking_for_m ore_information_on_permit=-

Wed Nov 12 17:20:22 UTC 2014

Another app_rpt poster just suggested the same thing. I’m trying that out now and it seems to work well. Just have to remember to hit the mute button right away after connecting if you don’t want to transmit immediately.
--
Tim
:wq

> On Nov 12, 2014, at 8:04 AM, Stephen Curtis <steve at m0hoy.com> wrote:
> 
> Hi Tim,
> 
> I too am using Zoiper, I found it easier and more stable to change it to Vox and essentially use the mute button in Zoiper as a PTT. 
> 
> Steve M0HOY
> 
> Sent from my iPhone
> 
> On 12 Nov 2014, at 14:51, Tim Sawyer <tim.sawyer at mac.com <mailto:tim.sawyer at mac.com>> wrote:
> 
>> 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 at bdboyle.com <mailto:bdboyle at 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 at midnighteng.com <mailto:mike at midnighteng.com>> <mike at midnighteng.com <mailto:mike at 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 at midnighteng.com <mailto:mike at midnighteng.com>>
>>>> Date: Wed, November 12, 2014 5:28 am
>>>> To: app_rpt-users at ohnosec.org <mailto:app_rpt-users at ohnosec.org>, "Bob" <kk6ecm at gmail.com <mailto:kk6ecm at 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 at crompton.com <mailto:doug at crompton.com>>
>>>> Date: Wed, November 12, 2014 1:13 am
>>>> To: "app_rpt-users at ohnosec.org <mailto:app_rpt-users at ohnosec.org>" <app_rpt-users at ohnosec.org <mailto:app_rpt-users at 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 at midnighteng.com <mailto:mike at midnighteng.com>
>>>> To: App_rpt-users at ohnosec.org <mailto:App_rpt-users at 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 at gmail.com <mailto:kk6ecm at gmail.com>>
>>>> Date: Tue, November 11, 2014 10:13 pm
>>>> To: <App_rpt-users at ohnosec.org <mailto:App_rpt-users at 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 at ohnosec.org <mailto:App_rpt-users at 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 at ohnosec.org <mailto:App_rpt-users at 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 at ohnosec.org <mailto:App_rpt-users at 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 at ohnosec.org <mailto:App_rpt-users at 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 at ohnosec.org <mailto:App_rpt-users at 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 at ohnosec.org <mailto:App_rpt-users at 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 at ohnosec.org <mailto:App_rpt-users at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/app_rpt-users/attachments/20141112/65148f6b/attachment.html>

[App_rpt-users] Echolink_and_app_rpt:_Looking_for_m ore_information_on_permit=*-*

[App_rpt-users] Echolink_and_app_rpt:_Looking_for_m ore_information_on_permit=-