[App_rpt-users] Echolink_and_app_rpt:_Looking_for_m ore_information_on_permit=-

Wed Nov 12 17:37:26 UTC 2014

We change the (*99) to * only for TX  and use the( #) to RX.

* to TX
# to RX

Hang up to disconnect.

Work good last long time,

--
Thanks in Advance

   Bob Brown, WØNQX

   Kansas City Metro Area

   http://drsm0ke.net

   http://byrg.net

   http://sm0kenet.net

   http://kcdstar.byrg.net

Quis custodiet ipsos custodes?

--

On Wed, Nov 12, 2014 at 11:20 AM, Tim Sawyer <tim.sawyer at mac.com> wrote:

> 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> 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> 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> <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
>
> 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>
> Date: Wed, November 12, 2014 5:28 am
> To: app_rpt-users at ohnosec.org, "Bob" <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>
> Date: Wed, November 12, 2014 1:13 am
> To: "app_rpt-users at ohnosec.org" <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 DougWA3DSPhttp://www.crompton.com/hamradio
> <http://www.crompton.com/hamradio>*
>
>
> ------------------------------
> From: mike at midnighteng.com
> To: 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>
> Date: Tue, November 11, 2014 10:13 pm
> To: <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
> 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/app_rpt-users/attachments/20141112/011f89a8/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=-