Date   

Re: Audio stream of DMR talkgroup.

K3CHB
 

thanks guys!

On Mon, Apr 22, 2019 at 1:08 PM Jeff Lehman, KC8QCH <kc8qch@...> wrote:
You wouldn't even need to setup a public node if you didn't want to to use ASL. Set it up as a private node on your server and then viola.....no one could connect to the ASL node, but you would than have a dedicated audio stream and wouldn't even need to try to reconfigure AB or MMDVM to make it happen.

On Mon, Apr 22, 2019 at 12:47 PM Steve N4IRS <szingman@...> wrote:
See:
https://wiki.allstarlink.org/wiki/Broadcastify



--
Jeff Lehman, KC8QCH
E-mail: kc8qch@...
Hamshack Hotline: 4218

Webmaster
Hamilton County ARPSC
http://www.hamcoarpsc.org
E-mail: hamcoarpsc@...
Phone: 513-452-6480

Multimode System Administrator
World Wide Amateur Radio Guild
https://hamradiohub.com/
E-Mail: kc8qch@...


Re: Audio stream of DMR talkgroup.

Jeff Lehman, N8ACL
 

You wouldn't even need to setup a public node if you didn't want to to use ASL. Set it up as a private node on your server and then viola.....no one could connect to the ASL node, but you would than have a dedicated audio stream and wouldn't even need to try to reconfigure AB or MMDVM to make it happen.


On Mon, Apr 22, 2019 at 12:47 PM Steve N4IRS <szingman@...> wrote:
See:
https://wiki.allstarlink.org/wiki/Broadcastify



--
Jeff Lehman, KC8QCH
E-mail: kc8qch@...
Hamshack Hotline: 4218

Webmaster
Hamilton County ARPSC
http://www.hamcoarpsc.org
E-mail: hamcoarpsc@...
Phone: 513-452-6480

Multimode System Administrator
World Wide Amateur Radio Guild
https://hamradiohub.com/
E-Mail: kc8qch@...


Re: Audio stream of DMR talkgroup.

Steve N4IRS
 


Re: Audio stream of DMR talkgroup.

Steve N4IRS
 

Jimmy,
I do it with MMDVM_Bridge -> Analog_Bridge -> AllStar -> broadcastify.

I don't see why it could not be done with MMDVM_Bridge -> Analog_Bridge -> USRP_Audio -> Broadcastify.
It would be a matter of understanding how the analog audio is process in ASL to send it to Broadcastify:
outstreamcmd = /bin/sh,-c,/usr/bin/lame --preset cbr 16 -r -m m -s 8 --bitwidth 16 - - | /usr/bin/ezstream -qvc /etc/ezstream.xml
it is like this:
MMDVM_Bridge -> Analog_Bridge -> USRP_Audio -> lame -> ezstream -> Broadcastify.

Hope this helps,
73, Steve N4IRS

On 4/22/2019 11:59 AM, Jimmy Capizzi wrote:
Hello, I am trying to set up an audio stream of our DMR talk group for the internet, does anyone have any information on this? 

I am thinking this can be done with Analog_Bridge.

Thanks alot

Jimmy 
K3CHB


Audio stream of DMR talkgroup.

K3CHB
 

Hello, I am trying to set up an audio stream of our DMR talk group for the internet, does anyone have any information on this? 

I am thinking this can be done with Analog_Bridge.

Thanks alot

Jimmy 
K3CHB


Re: OpenBridge Server?

KB5PBM
 

Use iptables to trigger of a source port and route to a destination ip and port.  


Re: OpenBridge Server?

Cort N0MJS <n0mjs@...>
 

OBP does not have any concept of master or peer. Both ends are the same. There’s no difference.

On Apr 21, 2019, at 10:49 AM, Ted Freitas (KE6YJC) via Groups.Io <ted.freitas@...> wrote:

Hi Everyone,

Been using dmrlink, hblink to establish our own standalone system like we used to have when we were on the c-Bridge. I have to say since we got everything setup we are quite happy and it's been fun learning the new scripts / software to make this all possible. I do have a question though. In light of what has happened with the BM DDoS attack's we are trying to break our system apart into public / private services. Our setup consists of a c-Bridge for all our DMR MARC feeds, a IPSC Gateway running HB_Bridge / IPSC_Bridge and a routing gateway that ties the IPSC Network and HBP (MMDVM) networks together. I have been reading in the form how the OBP can pull feeds in from the BM network and see that its function is to push/pull feeds from a server. I was wondering if HBlink can be setup as an OBP master to allow me push our internet network feeds from our routing gateway over to a secondary routing gateway that would only be used for public hotspots?

I know this can be done with multiple HBlink instances but i was looking for a solution to route everything accross and not need to manage a 2nd rules file or another set of config files.

Thanks,
Ted/KE6YJC <msedge_f8VQfKTT0w.jpg>

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206






OpenBridge Server?

 

Hi Everyone,

Been using dmrlink, hblink to establish our own standalone system like we used to have when we were on the c-Bridge. I have to say since we got everything setup we are quite happy and it's been fun learning the new scripts / software to make this all possible. I do have a question though. In light of what has happened with the BM DDoS attack's we are trying to break our system apart into public / private services. Our setup consists of a c-Bridge for all our DMR MARC feeds, a IPSC Gateway running HB_Bridge / IPSC_Bridge and a routing gateway that ties the IPSC Network and HBP (MMDVM) networks together. I have been reading in the form how the OBP can pull feeds in from the BM network and see that its function is to push/pull feeds from a server. I was wondering if HBlink can be setup as an OBP master to allow me push our internet network feeds from our routing gateway over to a secondary routing gateway that would only be used for public hotspots?

I know this can be done with multiple HBlink instances but i was looking for a solution to route everything accross and not need to manage a 2nd rules file or another set of config files.

Thanks,
Ted/KE6YJC


Re: DV Switch Mobile

Phil, G7OEA
 

Hi Mark,

I am running a raspberry pi 3 and the app together. The rpi3 connects to other hubs to access the all-star network. 

If you want help setting up a rpi3 with the app them you can email me. I am listed on QRZ.com

I also run MB7ILV and MB7ALV in the northwest..

73, phil


Re: Bridging a P25Reflector and a YSFReflector?

Steve N4IRS
 

Correct,
One MB and two AB (Transcoder) We are going forward with the change. No timeline yet but since MB is being worked on now it will be added.

Steve N4IRS


Re: The digital side of DVSwitch Mobile

N9UMJ
 

Steve

That sounds like a fantastic platform,  With work and travel I haven't been able to follow the progress of forums, This is something I'm very interested in learning more..Especially with my analog to digital project that I hope to start as soon as I wrap up a few other non-ham projects..Congratulations to you and the DV-Switch team on the progress and all of the time and hard work involved....Now for the important question?

What kind of beer?

Best Regards

Rick n9umj


On Fri, Apr 19, 2019 at 4:06 PM Steve N4IRS <szingman@...> wrote:

So, I am sure you think that we have gone dark on Mobile, but nothing is
further from the truth.  (We are actually on the beach drinking beer
spending the billions of dollars we made on the app so far.) While
development of the Allstar side has not stopped, we are spending quite a
lot of time on the digital side of Mobile.  The best way to think of
Mobile is as a full featured client for all of the DVSwitch portfolio of
applications.  Its job is to let you take DVSwitch with you wherever you
go.  Besides giving you access to the analog side by using Allstar,
Mobile now gives you access to all amateur digital voice modes (DMR,
D-Star, Yaesu Fusion narrow and wide, P25 and NXDN).  By leveraging the
capabilities of Analog_Bridge and MMDVM_Bridge you can roam wherever you
want and have all of your modes with you. The beauty of this is YOU
control the server. YOU setup the modes you want to use. It's YOUR
server. It is easier to list the features in bullet point format, so
here goes:

         •    Digital capabilities
         ⁃    All digital modes are supported for both receive and transmit
         ⁃    Digital Info
         ⁃    Metadata for each mode is displayed on the main “dialer”
screen
         ⁃    Each digital mode is color coded
         ⁃    Mode, TG/Reflector
         ⁃    Callsign and ID
         ⁃    TX/RX elapsed time
         ⁃    Talk group selection with incremental search
         ⁃    Full list of TG/Reflectors are available on the macro menu
         ⁃    Shortcuts to the first 10 are available for press and hold
on dialpad
         ⁃    Shortcut for mode on ‘A’ key
         ⁃    Shortcut for TGs on the ‘B’ key
         ⁃    Last heard list displays the last 50 stations heard
         ⁃    Personalized for your call sign and DMR/CCS7 ID
         •    General
         ⁃    Callsign lookup is done on the server side
         ⁃    Bluetooth and hardware PTT buttons supported (reported
working)
         ⁃    Network radio PTT Android intents (Inrico, Sonim, Hytera,
Senhaix, Radio-Tone, AOC)
         ⁃    Dedicated Bluetooth Microphones (iTalkie ZMIC)
         ⁃    Bluetooth LE (Pryme PTT-Z)
         ⁃    Macros may be invoked from the Mobile client and executed
on the server
         ⁃    Macros can change digital modes
         ⁃    Macros can invoke system functions
         ⁃    Nodes can be set up in the cloud or at your QTH which
includes NAT traversal capabilities for UDP
         ⁃    Bandwidth sipping codecs make it inexpensive to run all
the time
         ⁃    Rodger beep available on EOT
         ⁃    Backup and restore of user settings (soon)
         ⁃    The server has the capabilities to upload a new database
to the client when requested (soon)
         ⁃    Support for phones, tablets and network radio form factors

What do you need to make this cool stuff work?  Steve and I have been
playing with “hotspot builds” both on Intel and ARM and virtual and
physical hardware.  The components we run in these builds are
Analog_Bridge, MMDVM_Bridge, P25Gateway, NXDNGateway and IRCDDBGateway
(DMR and YSF do not need gateways).  In addition, md380-emu or a ThumbDV
is needed. If you go with the md380-emu, D-Star performance will be
severely degraded.  With these components in place, you can then use
DVSwitch Mobile to connect to any digital mode and steer that mode to
any talkgroup or reflector.

The magic happens because of two types of commands that are sent from
Mobile to the server.  First is a mode select command.  This command is
a macro which is interpreted by Analog_Bridge and used to enable the
proper settings within Analog_Bridge and MMDVM_Bridge. The macro
capabilities of Analog_Bridge let you run any script you want, and in
this case we have a script that is executed to change the mode to DMR,
DSTAR, YSF, P25 and NXDN.

The second type of command that Mobile sends is a Dial/Tune command. 
Analog_Bridge will take the command and forward it on to the
MMDVM_Bridge instance that is servicing the digital stream. Each mode
has a unique syntax for tuning.  For example DMR, P25 and NXDN use talk
group numbers to navigate, D-Star uses reflector names and YSF uses
reflector addresses and ports.  Mobile has a database for each mode with
the name of the talk group/reflector and the mode specific syntax to use.

To configure DVSwitch Mobile for digital access you just have to add a
new account to your app.  The account details are as follows:
     •    Protocol - USRP
     •    Hostname - IP address or host where Analog_Bridge is running
     •    Port - port number that matches Analog_Bridge.ini [USRP] TXPort
     •    TX Port - port number that matches Analog_Bridge.ini [USRP] RXPort
     •    Callsign - A valid ham radio callsign
     •    DMR ID - a valid DMR/CCS7 ID
     •    Autoload Node - does not need to be checked
     •    Transmit Level - We suggest you set this to no greater than
50% to start.  Use a Parrot to fine tune
     •    Receive Level - 100% is fine, adjust to taste
     •    Codec Types - Begin with Server Selected (unless on a very
limited network then use ADPCM)

The only setting that warrants additional information is the Port/TX
Port.  For best operation these ports should be equal.  When
Analog_Bridge sees equal port values it transitions into UDP traversal
mode.  This will allow you to set up your “node in the cloud” to be
behind a NAT router.  If behind a NAT, make sure to port forward the
selected port to your host running Analog_Bridge. Analog_Bridge and
Mobile will negotiate the session and keep it alive.






The digital side of DVSwitch Mobile

Steve N4IRS
 

So, I am sure you think that we have gone dark on Mobile, but nothing is further from the truth.  (We are actually on the beach drinking beer spending the billions of dollars we made on the app so far.) While development of the Allstar side has not stopped, we are spending quite a lot of time on the digital side of Mobile.  The best way to think of Mobile is as a full featured client for all of the DVSwitch portfolio of applications.  Its job is to let you take DVSwitch with you wherever you go.  Besides giving you access to the analog side by using Allstar, Mobile now gives you access to all amateur digital voice modes (DMR, D-Star, Yaesu Fusion narrow and wide, P25 and NXDN).  By leveraging the capabilities of Analog_Bridge and MMDVM_Bridge you can roam wherever you want and have all of your modes with you. The beauty of this is YOU control the server. YOU setup the modes you want to use. It's YOUR server. It is easier to list the features in bullet point format, so here goes:

        •    Digital capabilities
        ⁃    All digital modes are supported for both receive and transmit
        ⁃    Digital Info
        ⁃    Metadata for each mode is displayed on the main “dialer” screen
        ⁃    Each digital mode is color coded
        ⁃    Mode, TG/Reflector
        ⁃    Callsign and ID
        ⁃    TX/RX elapsed time
        ⁃    Talk group selection with incremental search
        ⁃    Full list of TG/Reflectors are available on the macro menu
        ⁃    Shortcuts to the first 10 are available for press and hold on dialpad
        ⁃    Shortcut for mode on ‘A’ key
        ⁃    Shortcut for TGs on the ‘B’ key
        ⁃    Last heard list displays the last 50 stations heard
        ⁃    Personalized for your call sign and DMR/CCS7 ID
        •    General
        ⁃    Callsign lookup is done on the server side
        ⁃    Bluetooth and hardware PTT buttons supported (reported working)
        ⁃    Network radio PTT Android intents (Inrico, Sonim, Hytera, Senhaix, Radio-Tone, AOC)
        ⁃    Dedicated Bluetooth Microphones (iTalkie ZMIC)
        ⁃    Bluetooth LE (Pryme PTT-Z)
        ⁃    Macros may be invoked from the Mobile client and executed on the server
        ⁃    Macros can change digital modes
        ⁃    Macros can invoke system functions
        ⁃    Nodes can be set up in the cloud or at your QTH which includes NAT traversal capabilities for UDP
        ⁃    Bandwidth sipping codecs make it inexpensive to run all the time
        ⁃    Rodger beep available on EOT
        ⁃    Backup and restore of user settings (soon)
        ⁃    The server has the capabilities to upload a new database to the client when requested (soon)
        ⁃    Support for phones, tablets and network radio form factors

What do you need to make this cool stuff work?  Steve and I have been playing with “hotspot builds” both on Intel and ARM and virtual and physical hardware.  The components we run in these builds are Analog_Bridge, MMDVM_Bridge, P25Gateway, NXDNGateway and IRCDDBGateway (DMR and YSF do not need gateways).  In addition, md380-emu or a ThumbDV is needed. If you go with the md380-emu, D-Star performance will be severely degraded.  With these components in place, you can then use DVSwitch Mobile to connect to any digital mode and steer that mode to any talkgroup or reflector.

The magic happens because of two types of commands that are sent from Mobile to the server.  First is a mode select command.  This command is a macro which is interpreted by Analog_Bridge and used to enable the proper settings within Analog_Bridge and MMDVM_Bridge. The macro capabilities of Analog_Bridge let you run any script you want, and in this case we have a script that is executed to change the mode to DMR, DSTAR, YSF, P25 and NXDN.

The second type of command that Mobile sends is a Dial/Tune command.  Analog_Bridge will take the command and forward it on to the MMDVM_Bridge instance that is servicing the digital stream. Each mode has a unique syntax for tuning.  For example DMR, P25 and NXDN use talk group numbers to navigate, D-Star uses reflector names and YSF uses reflector addresses and ports.  Mobile has a database for each mode with the name of the talk group/reflector and the mode specific syntax to use.

To configure DVSwitch Mobile for digital access you just have to add a new account to your app.  The account details are as follows:
    •    Protocol - USRP
    •    Hostname - IP address or host where Analog_Bridge is running
    •    Port - port number that matches Analog_Bridge.ini [USRP] TXPort
    •    TX Port - port number that matches Analog_Bridge.ini [USRP] RXPort
    •    Callsign - A valid ham radio callsign
    •    DMR ID - a valid DMR/CCS7 ID
    •    Autoload Node - does not need to be checked
    •    Transmit Level - We suggest you set this to no greater than 50% to start.  Use a Parrot to fine tune
    •    Receive Level - 100% is fine, adjust to taste
    •    Codec Types - Begin with Server Selected (unless on a very limited network then use ADPCM)

The only setting that warrants additional information is the Port/TX Port.  For best operation these ports should be equal.  When Analog_Bridge sees equal port values it transitions into UDP traversal mode.  This will allow you to set up your “node in the cloud” to be behind a NAT router.  If behind a NAT, make sure to port forward the selected port to your host running Analog_Bridge. Analog_Bridge and Mobile will negotiate the session and keep it alive.


Re: Bridging a P25Reflector and a YSFReflector?

2E0ISK
 

This sounds like a great solution. I am assuming this would mean only one instance of MB would be required (as with straight VW) but it would also handle YSFN pipe it via the transcoder and back in?


Re: Amazon Web Services (AWS) usage for reflectors

Tim Porter
 

Mike I would like too. 
Let's get in touch
74 de k4kwq tim

On Thu, Apr 18, 2019, 1:12 PM Mike, KI0IK <stupidfatkid@...> wrote:
John,

Have you considered hosting your reflector(s) in the Azure cloud?  I'm running a small Ubuntu VM in Azure (1 CPU, 1 GB RAM).  It's hosting a P25Reflector and a YSFReflector (they're bridged together with an instance of MMDVM_Bridge).  It's working well.  

Mike


Re: Amazon Web Services (AWS) usage for reflectors

leighton782@...
 

Thanks

However I am a complete Digital Virgin and all seems to be quite complex for an old man like me

Regards

Steve

On 18/04/2019 18:12, Mike, KI0IK wrote:
John,

Have you considered hosting your reflector(s) in the Azure cloud?  I'm running a small Ubuntu VM in Azure (1 CPU, 1 GB RAM).  It's hosting a P25Reflector and a YSFReflector (they're bridged together with an instance of MMDVM_Bridge).  It's working well.  

Mike


Re: Amazon Web Services (AWS) usage for reflectors

Mike, KI0IK
 

John,

Have you considered hosting your reflector(s) in the Azure cloud?  I'm running a small Ubuntu VM in Azure (1 CPU, 1 GB RAM).  It's hosting a P25Reflector and a YSFReflector (they're bridged together with an instance of MMDVM_Bridge).  It's working well.  

Mike


Re: 1 Way Audio (XLX DMR to ASL)

Steve N4IRS
 

This is VERY good info. I wqant to be clear, The work Steve is doing is VERY helpful! While Steve is troubleshooting at his end, Mike and I are working our end to find and fix the issue. All of the work going on together will resolve the issue.

Steve N4IRS

On 4/16/19 8:29 PM, Steve KC1AWV wrote:
DMRGateway is not a requirement to make a path from DVSwitch to XLX.

Let me explain that the reason that I have DMRGateway in a couple revisions of documents and why I mentioned it in the past. It was just for ease of (my) use. At first, I was confused as to how the voice data gets from DVSwitch to an XLX module, since MB logs in correctly, but XLX doesn't assign it to a module initially. In order to make things easier, DMRGateway can take a Module=X (where X is a module letter from A-Z) and once you're all logged in, viola, you're assigned a module. Simple as that, no muss no fuss. DMRGateway is just that, a gateway to a network. Think of the way it works with XLX as it is just choosing the door that you specified for you, once you get to the destination.

Once I took a look at the packet captures and saw that DMRGateway was trashing the call type (private instead of group) I decided that I wanted to get rid of it. I also saw that when making a call through DMRGateway, it wasn't actually selecting a module, but rather making a call to a specific TG - in my case, 4004 to assign module D. That's when the light bulb switched on in my head. If I can just get the call to go through to TG 4004, I won't need to use DMRGateway. Also, there's an opportunity to select whatever TG (read: module) I want by changing the TG on the fly. Well, guess what? AB takes that as an argument in the ini file.

Once I dropped DMRGateway and told AB to use TG 4004, MB connected and then just sat there like it used to. No module, no other indication of it being "ready." Then I decided, what the hell, I'll just make a call anyway - and it clicked. XLX put me into module D. No more DMRGateway needed.

Be aware though, this does not solve the one way audio issue. XLX will send voice data to MB just fine and you'll hear it coming out at you wherever the other end is. But, taking voice data from that end and pushing it back to XLX still doesn't work - XLX drops the stream almost as soon as it starts. No data comes back to MB from XLX to indicate an issue, but that's just the nature of UDP streams. In this case, the Internet is just a big truck, and you're dumping data somewhere and letting the server handle it however it wants.


Re: 1 Way Audio (XLX DMR to ASL)

Steve KC1AWV
 

DMRGateway is not a requirement to make a path from DVSwitch to XLX.

Let me explain that the reason that I have DMRGateway in a couple revisions of documents and why I mentioned it in the past. It was just for ease of (my) use. At first, I was confused as to how the voice data gets from DVSwitch to an XLX module, since MB logs in correctly, but XLX doesn't assign it to a module initially. In order to make things easier, DMRGateway can take a Module=X (where X is a module letter from A-Z) and once you're all logged in, viola, you're assigned a module. Simple as that, no muss no fuss. DMRGateway is just that, a gateway to a network. Think of the way it works with XLX as it is just choosing the door that you specified for you, once you get to the destination.

Once I took a look at the packet captures and saw that DMRGateway was trashing the call type (private instead of group) I decided that I wanted to get rid of it. I also saw that when making a call through DMRGateway, it wasn't actually selecting a module, but rather making a call to a specific TG - in my case, 4004 to assign module D. That's when the light bulb switched on in my head. If I can just get the call to go through to TG 4004, I won't need to use DMRGateway. Also, there's an opportunity to select whatever TG (read: module) I want by changing the TG on the fly. Well, guess what? AB takes that as an argument in the ini file.

Once I dropped DMRGateway and told AB to use TG 4004, MB connected and then just sat there like it used to. No module, no other indication of it being "ready." Then I decided, what the hell, I'll just make a call anyway - and it clicked. XLX put me into module D. No more DMRGateway needed.

Be aware though, this does not solve the one way audio issue. XLX will send voice data to MB just fine and you'll hear it coming out at you wherever the other end is. But, taking voice data from that end and pushing it back to XLX still doesn't work - XLX drops the stream almost as soon as it starts. No data comes back to MB from XLX to indicate an issue, but that's just the nature of UDP streams. In this case, the Internet is just a big truck, and you're dumping data somewhere and letting the server handle it however it wants.


Re: 1 Way Audio (XLX DMR to ASL)

Steve KC1AWV
 

I like to think that I'm doing my part for the greater good. Though I may not understand all the code and programming, I can at least get to a point where I know where the issue lies. From what I can tell, MMDVM_Bridge is doing exactly what it's supposed to do, and it works perfectly on all the systems and networks that I've tried up to this point.

The issue I believe is with xlxd. The path that the whole works takes is like this:

-Repeater Login-
MB sends login init to XLX (RPTL [Repeater ID])
XLX sends an auth challenge back to MB (RPTACK [salt])
MB sends back the auth to XLX (RPTK [Repeater ID] [hash])
XLX sends back auth successful to MB (RPTACK) - MALFORMED because the packet does not contain the Repeater ID
MB sends the repeater configuration to XLX (RPTC [Repeater ID] [MMDVM Conf])
XLX confirms with login successful to MB (RPTACK) - MALFORMED because the packet does not contain the Repeater ID
[TIME PASSES]
MB sends a keep-alive ping to XLX (RPTPING [Repeater ID])
XLX sends back a pong to MB (RPTPONG [Repeater ID]) - This repeater ID is what can only be described as bogus, it's supposed to send back the ID used in MB, but sends back a random number
[TIME PASSES, MORE PING-PONG]

-Voice Data-
MB sends 6 packets with voice header info (DMRD, Sequence, Source ID, Destination ID, Repeater ID, Slot, Call Type, Frame Type, Data Type, Stream ID, DMR Data, BER)
MB sends a voice sync packet (DMRD, Sequence, Source ID, Destination ID, Repeater ID, Slot, Call Type, Frame Type, Voice Sequence, Stream ID, DMR Data, BER)
MB sends 5 packets with voice frame data (DMRD, Sequence, Source ID, Destination ID, Repeater ID, Slot, Call Type, Frame Type, Voice Sequence, Stream ID, DMR Data, BER)
[SYNC AND FRAME REPEATS THROUGH TRANSMISSION]
MB sends voice term packet (DMRD, Sequence, Source ID, Destination ID, Repeater ID, Slot, Call Type, Frame Type, Data Type, Stream ID, DMR Data, BER)
[BACK TO KEEP-ALIVE PING-PONG]

Since this is UDP, there's nothing coming back from XLX during a voice transmission. MB is just shoving the data through the wire to XLX, and it's up to XLX to do with it as it deems fit. Want to hear a UDP joke? I'll tell you, but you might not get it.

Within a second or two (either during the voice header or voice sync, I assume) XLX just closes the connection. The logs from XLX look something like this:

Apr 16 18:06:41 xlx740 xlxd: Opening stream on module D for client KC1AWV  B with sid 11439
Apr 16 18:06:43 xlx740 xlxd: Closing stream of module D

So, really I feel something's wrong on XLX when processing the packets from MB. There's no issue on other DMR networks or with HBlink using MB. My next steps are to grab a pcap of an MMDVMHost connection to XLX and compare notes.

That's probably more than anyone wanted to know about how MB talks to a network, but I do feel that it's important information for people to know, in order to get a broader understanding of how this all works and the steps that I used to come to my conclusions. I don't find it too difficult to grasp these concepts, and I hope other people can learn from what we're all going through here.

Steve KC1AWV

Pardon my verbosity, I tend to ramble.

On Tue, Apr 16, 2019 at 4:39 PM Daniel L. Srebnick via Groups.Io <dan=islenet.com@groups.io> wrote:
Steve KC1AWV, thanks for your flurry of effort here in helping to understand what is going on.

73
_._,_._,


Re: 1 Way Audio (XLX DMR to ASL)

Dan K2IE
 

Steve KC1AWV, thanks for your flurry of effort here in helping to understand what is going on.

73

5761 - 5780 of 9532