[arm-allstar] Next gen architecture questions

[Doug Crompton]

Alessio,

   Hamvoip while primarily an amateur radio system can also be used
privately. The only requirements are that EACH end knows the IP address and
IAX port of the other end. This is stored in the [nodes] stanza of
rpt.conf. We do not support commercial use but many private systems exist
and used privately there is no need to have a radio licence if no
transmissions are via RF. As far as bridging to other services is concerned
this is up to the individual. Both Echolink and IRLP bridging are currently
used as well as DMR experimentally. Bridging of services should always be
with the permission of whomever you are connecting to. Some nodes or hubs
frown on the connection of certain modes.

Our primary goal is the improvement of the Allstar mode. While we may make
bridges possible to other modes the development of those modes and the
connection to those nodes is up to others. We are not in the Echolink,
IRLP, DMR, Dstar, etc. business.

So the bottom line is you can do as you wish with the software, public,
private, bridges, etc.


*73 Doug*

*WA3DSP*

*http://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*

On Thu, Jan 9, 2020 at 9:28 AM "Alessio Sacchi via ARM-allstar" <
arm-allstar at hamvoip.org> wrote:

> Thanks Doug, let me provide some context to qualify my questions better.
> Maybe of interests to many here.
>
> Attached is the draft architecture I am planning on. Regardless of hamvoip
> or DMR systems, the reason for the private cloud is due to the fact all of
> my remote locations will be soon connected together over a private fiber
> backbone provided by the State. So that network will always be up and I
> should better plan on having my HUBs (for hamvoip and for DMR) over that
> same network instead of the public cloud. Similarly, Echolink and AIX ports
> can stay in the public cloud as users would be locked out anyways if my
> private cloud loses internet access - this also helps keeping unnecessary
> load away.
>
> Regarding distinctive courtesy tones, I am using them today at SITE 1. They
> work perfectly as the two simplex ports are connected to the duplex 70cm
> port which is the main one where radio users are. I understand these tones
> don't propagate via Allstar network, but the limitation seems to be with
> the number of nodes to propagate through, not the type of node. Let me
> explain.
> My nodes are all private to Allstar network. As per my schema, what I would
> like to do is to have a distinct tone (I use EL in CW today on SITE 1 where
> the Echolink port is also locally connected) when an Echolink user unlinks
> from the Echolink port in the public cloud which is connected to my radio
> ports via a HUB in the private cloud. This would be a 2 step jump: Echolink
> port to HUB to Radio Port.
>
> So my question is: this would not work today as courtesy tones only
> propagate for 1 step - even if my nodes are all private, correct?
>
> I would love to help with the PI farm testing when you are ready. I have a
> real use case I want to deliver to my users - concern is latency as I guess
> you would start with a hosting location in the US which may add several ms
> from Europe. Worth doing some tests.
> Also, back to my diagram... I foresee users on this type of public clouds
> for our scope will most likely need to setup other machines other then just
> hamvoip - DVSWITCH, HBlink, etc. I guess you are considering that.
>
> Thank you
> Alessio
>
> On Thu, Jan 9, 2020 at 3:17 AM "Doug Crompton via ARM-allstar" <
> arm-allstar at hamvoip.org> wrote:
>
> > Alessio,
> >
> >   Courtesy tones are local only. They do not propagate the Allstar
> network.
> > Hamvoip instituted a distinct courtesy tone capability where you can
> assign
> > different courtesy tones for different nodes. See the howto on distinct
> > courtesy tones at hamvoip.org. Courtesy tones can be tones, CW, or
> actual
> > sound files. Of course you would not want it to be long in duration.
> >
> > Things have changed greatly in the last few years and as long as you have
> > Internet availability and bandwidth the Pi, especially the Pi4 in turbo
> > mode should handle anything you throw at it. There is a PC version in
> alpha
> > but I would not count on it being released any time soon or at all. There
> > is also a "Pi farm" in the works which would allow users to lease a Pi4
> on
> > a high bandwidth connection remotely with Hamvoip SW installed. This
> would
> > primarily be for users who do not have the Internet available or who have
> > limited bandwidth access.
> >
> >
> > *73 Doug*
> >
> > *WA3DSP*
> >
> > *http://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*
> >
> > On Wed, Jan 8, 2020 at 9:07 PM "Alessio Sacchi via ARM-allstar" <
> > arm-allstar at hamvoip.org> wrote:
> >
> > > Hi - working on the next gen architecture for my nodes at the moment.
> Two
> > > questions
> > >
> > > - Currently, courtesy tones only propagate for 1 hop. Any plan or
> > > technical impediments for multi-hop courtesy tones? Use case: multiple
> > > nodes connected though a central hub.
> > >
> > > - I may have to run a hub in the public cloud. Any non RPi software
> > > available/planned?
> > >
> > > Thank you
> > > Alessio IZ4EFN
> > > _______________________________________________
> > >
> > > ARM-allstar mailing list
> > > ARM-allstar at hamvoip.org
> > > http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
> > >
> > > Visit the BBB and RPi2/3/4 web page - http://hamvoip.org
> > >
> > _______________________________________________
> >
> > ARM-allstar mailing list
> > ARM-allstar at hamvoip.org
> > http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
> >
> > Visit the BBB and RPi2/3/4 web page - http://hamvoip.org
> >
> _______________________________________________
>
> ARM-allstar mailing list
> ARM-allstar at hamvoip.org
> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>
> Visit the BBB and RPi2/3/4 web page - http://hamvoip.org