I was thinking local-only behavior (and just for telemetry/CW); not for the link. Probably should have specified that…
As a general comment, one reason there is a lot of confusion and complexity with ASL is because there are various config parameters with very little documentation, and now a cop,58 command (which apparently is a command only with no corresponding config parameter)… If anyone was to go through the conf files and manual and try to figure out which parameters affected PL in which possible different states (ie. Tx keyed with audio, courtesy tone delay, hang time, ID, autopatch on, linktolink active …) and in which of these states and configurations telemetry audio, DTMF, hang time would be propagated to the network, you’d probably have to spend days looking through the app_rpt and Asterisk C code and doing tests to be sure.
This is not a new problem and it plagues many other legacy systems. A way around that in a new more modern approach is to abstract the configuration away from individual details and make it more general. This can be done first enumerating the possible states of the various system modules (Bruce it sounds like you have already done that) and then defining a table that maps input states and events to output states and actions. This requires moving past the ancient paradigm of text based config files and fortunately &-ASL has already done that and uses a web configuration interface. Thus that interface could just show a table of checkboxes (or text/select boxes with numeric values) that enables users to instantly see eg. what states PL or DCS is active or not active and to change that to whatever they need simply by checking the appropriate boxes in that row. This would be far clearer and more intuitive I think than having to figure out which random config parameters and cop commands might do what’s needed in various circumstances.
It’s a bit misleading, because it also sends CTCSS on input from linked nodes, not just the local receiver.
This week I was working on two things:
- The repeater/timing logic which has already been discussed at length on this thread. The current logic (taking into account the suggestions) is documented here.
- Separately, I did some research on the VOTER system and experimented with a way to simplify the hardware by eliminating the need for GPS clock synchronization for the voting scenario (not simulcast). The findings are summarized here if you are really into VOTER mechanics.
The project has been trying to solicit some web developers for 2 years to help develop a web-based configuration interface for simple/standard configurations. We've also ask people to help with documentation with limited success. We've not received any interest to date and the other developers are still working heavily on the core roadmap. If anyone is interested in contributing to the project either with a web UI or documentation, we'd love to have serious volunteers.
Hi. I'm still here and working hard on this project. The past few months have been spent in firmware development and I've now got some good microcontroller-based devices on the network. I love LINUX administration as much as anyone, but it can be nice to get on AllStar without hassling around with this stuff.
Since several people have asked about it, I'm doing work on private node support. This is an area I know little about. Is there someone who is familiar with the ins/outs of running private nodes on the AllStar network who would be willing to review my design and documentation? If so, I would greatly appreciate the help. Please reach out directly using the e-mail in QRZ. Thanks!
I kinda doubt that as you have to be 'PUBLIC' to be able to connect to/from ASL network.
You can permit your own private node to your own public node within your server.
Thanks Mike.
What I'm working on is allowing AllStar nodes that aren't registered in the public ASL directory to connect to each other. This would include nodes that are on a private network, or perhaps just nodes that people don't want available to the general public for whatever reason. From what I understand of the convention, these nodes would have numbers <=1999. I don't think I'm breaking any new ground here - just making sure it works right.
It sounds like maybe you don't consider these nodes to be part of the "AllStar Network?" Hopefully I'm not completely missing the point of your comment.
Anyhow, either way I had some folks who were operating non-registered/private nodes reach out to me and provide comments about my implementation of this case. So I think I'm all set.
The key thing is that the IAX2 RFC defines an address format (technically a URI) that allows you to specify all of the parameters of a connection using something that looks like this:
iax:kc1fsz@10.0.0.12:4568/1998,secret
As long as the implementation puts all of those parameters into the right place in the IAX2 NEW message, and as long as the called node has the credentials of the calling node setup in a local repository, the connection is negotiated without any use of the public registry.
As as aside, I've also been testing a public-key authentication scheme that allows you to post a public key in the ampr.org domain (44net) so that called nodes can authenticate you without having to maintain any local credentials. That's kind of mid-way between a public node and a private node. It seems safe because the 44net people do a license check before granting you a ampr.org domain.
73s, Bruce KC1FSZ
Private nodes are just that 'PRIVATE'.
They are not connectable from the public network system.
What I consider them is not relevant. It is not an opinion.
Registered node numbers are public nodes. But you can block all traffic with exception to what you want to allow to connect. It is still considered a Public node as registered.
This is to say you are responsible for traffic from that private node(s) as no other vetting has been preformed by ASL.
Public registered nodes are in a list distributed to all public nodes. If the connectee and connector are not both in the list, no connection across the ASL network is possible.
It sounds like you are trying to create a new registration system/network. You can.
Know the few rules described above still hold true. And that you would be responsible for un-vetted traffic on the ASL network that is bridged through a public node you use.
Private nodes can have any number of private connections with other private nodes, or within your own registration network. But not ASL. Only registered public nodes connect across the ASL network.
To provide some clarity here, this part of the conversation is casually mixing AllStarLink Network with the actual software app_rpt module. By name of the corporation, project, trademark, branding, etc. "AllStarLink" and all related terms is referring collectively to the integrated system of app_rpt and its channel drivers, the node registration system, and all of the ancillary services and tools. That is "AllStarLink", the "AllStarLink Network", etc.
Things not provided and maintained by AllStarLink, Inc. is not "AllStarLink" however. Many others use app_rpt in private nodes or private networks. Others provide commercial products that connect to AllStarLink, are "AllStarLink Compatible", "AllStarLink Clients", etc. All of this is welcome and supported when we can in software, etc. However those are not properly "AllStarLink" or "Allstar" (which has become a conventional shorthand).
If you are going to create a parallel registration process - and I really really wish you wouldn't for a variety of reasons - that it not "AllStarLink" or the "Allstar Network".
Thanks Mike and Jason. OK, I think I see my confusion now. Sorry to be dense. I have misunderstood the branding. I was being careful in my previous messages to use the term "AllStar" instead of "AllStarLink." My thinking (wrong) was that "AllStar" means "a ham linking technology based on the IAX2 protocol" and "AllStarLink" means the "AllStar + the official implementation + the public registry + the corporation."
But from your explanation, it sounds like AllStar and AllStarLink both refer to the network formed via the public registry. I know these definitions are important. Going forward, I won't use the term "AllStar" to refer to the linking of nodes that aren't in the public registry.
I think Mike's note also implies a technical "block" that prevents nodes that accept private connections from linking to other public nodes (i.e. no mixing allowed). I wasn't aware of that mechanism and I'll work on an implementation for it. This does raise the question about how private nodes are any different from, say, DMR stations or EchoLink stations that bridge across to the AllStar network, but I'm sure that's been considered already.
In any event, there seems to be value in allowing nodes that aren't part of AllStar to connect to each other (off-network) using IAX2-compatible software and I've been doing the technical work to make sure that works for those who want it. I will put a statement in my documentation that makes it clear that these nodes shouldn't be called AllStar.
Thanks for your patience, I'm not that bright.
Hi Jason:
To make one thing clear, what I've been playing with is an alternate authentication process - not a parallel registration process. My implementation still requires the calling node to be setup in the legit AllStarLink registration system because that's how the association between the ASL node number and callsign is established. You've explained to me a few times why a competing registration database is a bad idea and I agree.
All I'm doing is experimenting with ways to authenticate nodes without needing to rely on a source IP address check since that has advantages for mobile stations and for stations that have been off the network long enough to "time out" the IP address mapping.
Understood. The biggest thing we need to avoid as a community is a fragmentation of the "directory" and "numbering". See all the confusing number of DMR networks as an example...
There is no 'BLOCK', just conditional 'ALLOW'
Meet the criteria and be allowed.
When a user allows DMR or etc through 'their' Public node, they are responsible for it.
Whatever comes from your public node, you are liable for is perhaps a better way to frame it.
You can't force someone to take unsavory connections or ones they may disagree with. You possibly could find your public node blacklisted with other public nodes. And I am not saying they are or would be, but an example of things that can happen.
Reference my several posts above again as you learn more about how it works. It will make more sense.
The integrity of the network is foremost on everyone's mind as it always has been.This was properly designed in the first place with all of that.
I fail to see a need to allow some other path to the network.
It's not like it is difficult to sign-up for a public node number.