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@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@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@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@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 DougWA3DSPhttp://www.crompton.com/hamradio <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 <http://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.

_______________________________________________ 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.