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…
toggle quoted messageShow quoted text
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
|