
Steve N4IRS
The existing clients are Android any Python. The python client
pretty much runs on any desktop system. As it happens, Mike is
spending a LOT of time making sure the HTML client runs on most
browsers and that includes Safari on IOS.
For the AllStar people among us, The clients will be able to control
the AllStar nodes.
toggle quoted messageShow quoted text
On 12/22/20 7:14 PM, Jeff Lehman, N8ACL
via groups.io wrote:
I’ll be honest, I havn’t looked too closely at the DVSwitch server
because I don’t have an android device. However, This is
incredibly intriguing and very much changing my mind about
dedicating a PI to this. I love the concept of multiple clients,
especially a web based one. Very much looking forward to this…
Jeff
On Dec 22, 2020, at 19:06, Patrick Perdue < patrick@...>
wrote:
Definitely looking forward to this,
especially if you can do something like referencing
the Allstarlink node database and matching to ID's, if
they exist. Of course, there is a lot of room for
error, since the call sign field for ASL nodes is
technically arbitrary, but it would be better than
what exists now for passing metadata to digital modes.
There are way too many people who look at displays and
don't listen.
On 12/22/2020 4:21 PM,
Steve N4IRS wrote:
We have been talking about hUC (HTTP USRP Client)
since about the time we released DVSwitch Server. So,
where is it already? hUC in it's early form did not
really take that long. Thought it connects to DVSwitch
Server differently, It's not much different then pyUC
(python USRP Client) Then we started having our usual
"what if" discussions. Our wives will tell you this
can go on for days. A very big issue with a web based
client is security. If you expose a HTML client to the
internet, people will play with it. This could be
disastrous. We need security to control who can do
what. I sure don't want anybody with access to a
search engine to start talking on DMR TG 91 (with my
call and DMR ID) So, security had to be added.
Now I have this DVSwitch Server in the cloud with a
web interface and at least I can control who has
access. We know DVSwitch Server is single user. It
sure would be nice if I can give my friends access to
my server. Let's face it, I'm not using it all the
time. I can share. Some friends are more responsible
then others. I would like to give Jack the ability to
transmit, but not move the Server to another mode or
talk group (tune). I would like to give Jill the
ability to listen, but no transmit and no tune. OK, we
can do that. Jack and Jill can both listen to traffic
on the server. Jack can transmit. I am the only one
that can tune to another TG or mode. OK, this is
getting good.
We don't want to limit the fun to only web clients.
What about DVSM and pyUC users? Yes, you can assign
the same rights to DVSM and pyUC users. You can have
users from all 3 clients with different rights.
Everybody that can listen will hear not only the
connected Steerable Bridge (SBridge) they will hear
any client with transmit rights. Let me be CLEAR, This
is one SBridge shared among multiple users. This is
NOT DVAAS (Digital Voice as a service)
We did not forget AllStar. You can have one or more
AllStar nodes directly connected to the Server.
AllStar users (by node) can be assigned rights. RX, TX
Tune. It's up to the Server owner how these
connections are controlled. Some Server users use
AllStar to mix audio from multiple modes. This is
usually done by bridging each mode into a seperate
AllStar "private node" This give the Server operator
the ability to connect and disconnect modes into the
main AllStar node. He can also directly connect 2
modes together without connecting those modes to
anything else. AllStar is VERY versatile that way. In
the case of unlike modes DMR (AMBE) to P25 (IMBE) this
works quite well.If you are connecting like modes YSFn
(AMBE) to NXDN (AMBE) this leave something to be
desired. This is transcoding where none is required.
It's up to the Server operator to decide if this is a
disadvantage. No matter if it's like modes or not,
using AllStar to bridge Digital Voice modes has one
downside, You loose the metadata that is transmitted
along with the voice. Some people don't care, the
advantages of mixing in AllStar outweighs the
disadvantages. I can make a case for either choice.
So, how do we give people another option. That option
is called Analog_Reflector. Consider a piece of
software tha t will accept multiple connections from
clients (DVSM, pyUC or hUC) it will also accept
connections from multiple AllStar nodes either on the
same server or a remote server. (via USRP) You can
have multiple bridges connected. These bridges are
fixed by mode and TG (reflector). Last but not lease
is a Steerable Bridge (SBridge) This is the bridge you
can change modes, you can change TGs it's exactly like
the bridge in DVSwitch Server now. Any client (with
the proper rights) can steer the bridge. This includes
The AllStar nodes. One big advantage, no more macros
needed (but still supported) The command path between
AllStar and the reflector is two way. We can send
commands for AllStar to the reflector (and on to the
SBridge) We can also receive commands from a connected
client and send them to AllStar. If you want to
connect your AllStar node to another AllStar node, you
can do it from a connected client. AllStar becomes
"just another mode" accessible from a connected
client. (Think Web tranceiver)
One last point I may have glossed over. EVERYBODY get
the metadata. Client, Bridges, AllStar and SBridges.
Everybody gets the data. Not everybody can do anything
with the metadata (AllStar) but AllStar does send what
little metadata it knows about the connected and
transmitting stations into the reflector.
Over the next few months we are going to build a
demonstration bridge. we will show you how to connect
like modes without transcoding. We will show you how
to send traffic to multiple modes at the same time. An
example of this is DMR to YSF AND P25. We are going to
do this with one instance of MMDVM_Bridge and a
transcoder. Everybody gets the audio, everybody gets
the metadata. Yes, it's all done with UDP ports. It's
all modular. Yes it can get complex. (we have some
thoughts in that area too)
DVSwitch is about giving you control. You control the
mode, you control the destination. You control the
metadata. It's your server. Do what YOU want.. There
is SO much more I did not cover (as Mike will tell me)
There is a admin interface for Analog_Reflector (and a
dashboard) Somebody "sitting on his mike"? Kick him or
mute him. Somebody abusing your server, ban him. I
won't promise you we have thought of everything. That
will come to light as we see tAnalog_Reflector in the
field.
For DVSwitch,
73, Steve N4IRS
|