[arm-allstar] Next gen architecture questions

Alessio Sacchi iz4efn at gmail.com
Fri Jan 10 03:22:30 EST 2020 

Thank you Doug - when that time comes let me know if I can of help. Feature
documentation, testing, etc.

Alessio

On Fri, Jan 10, 2020 at 2:39 AM "Doug Crompton via ARM-allstar" <
arm-allstar at hamvoip.org> wrote:

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

More information about the ARM-allstar mailing list