[arm-allstar] Next gen architecture questions
Alessio Sacchi
iz4efn at gmail.com
Thu Jan 9 18:06:50 EST 2020
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
>
More information about the ARM-allstar
mailing list