[arm-allstar] Next gen architecture questions

Thu Jan 9 20:39:36 EST 2020

Alessio,

   Under the current system, as you pointed out, nodes do not propagate
information beyond one node hop. So for instance people connected to a hub
only see the hub as transmitting no matter what node transmits into the
hub. Therefor and as you know distinctive courtesy tone would not work in
that situation as it would only see the hub to all connected nodes. This is
a limitation of the current system and unless the status information system
is revised it would not be possible. There has been talk of fixing this
inadequacy but it would require a complete rework that would not be
compatible with the current system. It is not currently high on the to-do
list but is certainly an added feature that could bring many more benefits
and will be on the thought list for future development.

*73 Doug*

*WA3DSP*

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

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

> Hi Doug, I think I brought you off track. Sorry about that. This was not a
> request for help on bridging nor using Hamvoip out of an ham radio scope.
> It was more a FYI on the big picture I had in mind for my community as I
> design my next gen architecture.
>
> My question really was with regards to courtesy tones. As per howto:* While
> this is useful in multi-connect situations the Allstar status system
> currently only nests one deep. That is if node A is connected to node B and
> node B is connected to node C. When node A keys node C sees it as coming
> from node B. Likewise if node C keys node A also sees it as coming from
> node B. So if you are connected to a hub which has many others connected
> you will only see the hub keyup regardless of who it is. In this case the
> distinctive courtesy tone would not be as useful. *
>
> Any chance it would be possible to review this limitation/feature in the
> future? A couple of thoughts
> - It probably doesn't make sense for courtesy tones to propagate to other
> Allstar/Hamvoip nodes with numbers >2000 (this is what I call "public"
> nodes) as it may get very messy. But for private nodes (<2000) I think it
> could be a very interesting capability in some setups like mine for
> instance, where I have a "private" hub that ensures all local nodes are
> always connected, and one node facing the public so that the entire system
> can be addressed via Allstar/Hamvoip publicly.
> - Assuming it is technically possible to nest more then one deep - is that
> really an issue for how hamvoip works? I mean: for each node in a stanza,
> you have to specify the courtesy tone for each other nodes and a default
> one. If a node gets connected to another node for which a courtesy tone is
> not configured in the stanza, the default one will be used. Isn't this the
> same behavior you would expect when tones propagate only one deep?
>
> Thank you
>
> Alessio
>
> On Thu, Jan 9, 2020 at 7:58 PM "Doug Crompton via ARM-allstar" <
> arm-allstar at hamvoip.org> wrote:
>
> > 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
> > _______________________________________________
> >
> > 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
>