Date   

Re: Where the heck is hUC?

Jeff Lehman, N8ACL
 

Oops… sorry….. yes iOS...

On Dec 22, 2020, at 19:24, Steve N4IRS <szingman@...> wrote:

I can try Firefox on what IOS or ???

On 12/22/20 7:22 PM, Jeff Lehman, N8ACL via groups.io wrote:
Now you have sold me…. What about other mobile browsers like Firefox? I mean I totally get that there are so many browsers out there, it would be almost impossible to check them all. But still Safari works for me for this….. Love it!

Jeff

On Dec 22, 2020, at 19:18, Steve N4IRS <szingman@...> wrote:

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.

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  






Re: Where the heck is hUC?

Steve N4IRS
 

I can try Firefox on what IOS or ???

On 12/22/20 7:22 PM, Jeff Lehman, N8ACL via groups.io wrote:
Now you have sold me…. What about other mobile browsers like Firefox? I mean I totally get that there are so many browsers out there, it would be almost impossible to check them all. But still Safari works for me for this….. Love it!

Jeff

On Dec 22, 2020, at 19:18, Steve N4IRS <szingman@...> wrote:

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.

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  





Re: Where the heck is hUC?

Jeff Lehman, N8ACL
 

Now you have sold me…. What about other mobile browsers like Firefox? I mean I totally get that there are so many browsers out there, it would be almost impossible to check them all. But still Safari works for me for this….. Love it!

Jeff

On Dec 22, 2020, at 19:18, Steve N4IRS <szingman@...> wrote:

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.

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  




Re: Where the heck is hUC?

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.

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  



Re: Where the heck is hUC?

Jeff Lehman, N8ACL
 

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  


Re: Where the heck is hUC?

Patrick Perdue
 

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  


Where the heck is hUC?

Steve N4IRS
 

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  


Soft Keyboard

Sean Burton
 

Just an enquiry on a minor issue. I use DVSwitch Mobile on an Android device with no keyboard and a quite small screen. I am unable to enter Talkgroup numbers or commands as the on screen keyboard is absent, despite enabling it in the configuration tab. I can get around this by editing the macros under configuration but I am not able to access the star key with a long press to enter advanced settings (for changing DMR master etc). Is there a fix please?


Re: Confused hblink and MMDVM bridge.

G4WXN@...
 

OK I think I have this now.

I have created MB ini files for each network, the scripts copy this over the MB ini file and then restarts the MB service.

This works fine for BM and TGIF, however I still cannot get DMR+ to work.

What master do I use for DMR+?

I tried using the one that is in the tune string 78.129.135.43 but again it fails.

--
Derek

G4WXN


Re: Adding P25 to existing YSF and DMR bridge

Gary, KE8O
 

Steve,

I changed the YSF2DMR to a different DRM ID. I will arrange another test and provide feedback. 


Re: Adding P25 to existing YSF and DMR bridge

Steve N4IRS
 

That's what I expected. Both bridges are logging into TGIF with the same DMR ID (139360) I can see where TGIF might be unhappy. Try 2 different IDs.

Steve


On 12/20/20 5:16 PM, Gary, KE8O wrote:
Steve,

Here's the two INI files.


Re: Adding P25 to existing YSF and DMR bridge

Gary, KE8O
 

Steve,

Here's the two INI files.


Re: Adding P25 to existing YSF and DMR bridge

Steve N4IRS
 

Gary,
I see no port conflicts. Please send the two MMDVM_Bridge.ini files.

On 12/20/20 2:35 PM, Gary, KE8O wrote:
Hi Steve,

Sorry for the delay. My repeater decided to go belly up this weekend. But its working again.

Attached are the two UDP captures with only one bridge running at a time. 




Re: Adding P25 to existing YSF and DMR bridge

Gary, KE8O
 

Hi Steve,

Sorry for the delay. My repeater decided to go belly up this weekend. But its working again.

Attached are the two UDP captures with only one bridge running at a time. 



Re: DVSwitch Dashboard Web Port

EA4GAX - Sergio
 

Ok, excelent.
Thank yor


Re: DVSwitch Dashboard Web Port

Steve N4IRS
 

Sergio,
The port number can be changed.

edit /lib/systemd/system/webproxy.service
See this line:
ExecStart=/usr/bin/node /opt/Web_Proxy/proxy.js 8080 2222

edit to taste and reboot.

73, Steve N4IRS

On 12/20/20 6:38 AM, EA4GAX - Sergio wrote:
Hi Steve and all, Is possible change port 8080? This port is to use for the other machine.
Thank you.


Re: DVSwitch Dashboard Web Port

EA4GAX - Sergio
 

Hi Steve and all, Is possible change port 8080? This port is to use for the other machine.
Thank you.


Re: ASL <-> D-Star <-> xlxd

 

On 20/12/20 4:23 am, Steve N4IRS wrote:

[Edited Message Follows]

So,
I was playing around this morning. I'll preface this as I can't even
spell xlxd.
I find xlxd listens on a number of UDP ports, some of which conflict
with ircDDBGateway.
This is a systemctl status after starting xlxd on a DVSwitch Server
Yes, that's correct, because both ircDDBGateway and xlxd are able to
listen for incoming traffic on the same protocols.  You need to bind
them to separate IPs, or run them on separate servers.  I now do the
latter, where I run xlxd alongside AllStar, YSFReflector and
P25Reflector on one server, while DVSwitch itself runs on another
server.  I was able to have all of the reflectors, except for xlxd on
the same server (using different ports for YSFReflector and xlxd's YSF
support), plus AllStar on the one server, but separated out DVSwitch
when the new version came out for ease of maintenance, and not wanting
to conflict with old code.

And yes, 127.0.0.1 would be for ambed, which I'm not running here, as my
xlxd currently does no transcoding. 

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com


Re: ASL <-> D-Star <-> xlxd

 

On 20/12/20 1:56 pm, Steve N4IRS wrote:
As I found, without 127.0.0.1 xlxd is not listening on any UDP ports.
I did not think xlxd HAD to be used with a vocoder if all it was to do
is be a D-Star reflector.
Not high on my list of things to care about, I was just playing and or
bringing up a test D-Star or DMR or YSF reflector.
You are correct, xlxd doesn't need the AMBE chip or server, unless you
actually want to transcode.  I'm running an xlxd reflector without the
AMBE transcoder.  I am using primarily two modules.  One is for D-STAR
on my multimode gateway (XLX432 D) and another is a YSF reflector.  
Other than the YSF channel, the rest are available for D-STAR use.

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com


Re: ASL <-> D-Star <-> xlxd

Steve N4IRS
 

As I found, without 127.0.0.1 xlxd is not listening on any UDP ports. I did not think xlxd HAD to be used with a vocoder if all it was to do is be a D-Star reflector.
Not high on my list of things to care about, I was just playing and or bringing up a test D-Star or DMR or YSF reflector.

Steve

On 12/19/20 9:52 PM, Charles Wiant via groups.io wrote:

If I am not mistaken the 127.0.0.1 is supposed to be ambed.

 

From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> On Behalf Of Steve N4IRS
Sent: Saturday, December 19, 2020 11:23 AM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] ASL <-> D-Star <-> xlxd

 

[Edited Message Follows]

So,
I was playing around this morning. I'll preface this as I can't even spell xlxd.
I find xlxd listens on a number of UDP ports, some of which conflict with ircDDBGateway.
This is a systemctl status after starting xlxd on a DVSwitch Server


Dec 19 12:07:27 new xlxd[1337]: Read 162240 DMR ids from xlxapi.rlx.lu database

Dec 19 12:07:28 new xlxd[1337]: Read 6004 YSF nodes from xlxapi.rlx.lu database

Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP30001 on ip 44.103.34.85

Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP30051 on ip 44.103.34.85

Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP42000 on ip 44.103.34.85

Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP40000 on ip 44.103.34.85

Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP12346 on ip 44.103.34.85

Dec 19 12:07:28 new xlxd[1337]: Error opening socket on port UDP12345 on ip 44.103.34.85

Dec 19 12:07:28 new xlxd[1337]: Error opening raw socket for ICMP

Dec 19 12:07:28 new xlxd[1337]: Error starting reflector

 
It seems the default startup for xlxd is: xlxd XLX999 192.168.178.212 127.0.0.1
Question, what is xlxd listening to 127.0.0.1 for?
If I start xlxd without the 127.0.0.1 address, the daemon starts with no error.

AH! if I start xlxd without 127.0.0.1 it starts, but is not listening to any UDP ports...

Comments?


2021 - 2040 of 9925