Date   

Re: HBLink and DMRLink

Steve N4IRS
 

Here is mine from 2600 test.

[1999]
; USRP from Analog_bridge
rxchannel = USRP/127.0.0.1:34001:32001  ; GNU Radio interface USRP
duplex = 0                              ; 0 = Half duplex with no telemetry tones or hang time.

hangtime = 0                            ; squelch tail hang time 0
althangtime = 0                         ; longer squelch tail hang time 0

holdofftelem = 1                        ; Hold off all telemetry when signal is present on receiver or from connected nodes
                                        ; except when an ID needs to be done and there is a signal coming from a connected node.

telemdefault = 0                        ; 0 = telemetry output off. Don't send Allison to DMR !!!!!!!!!!!!!!!!! Trust me.

telemdynamic = 0                        ; 0 = disallow users to change the local telemetry setting with a COP command,

linktolink = no                         ; disables forcing physical half-duplex operation of main repeater while
                                        ; still keeping half-duplex semantics (optional)

; idrecording = |iWA4XYZ/R              ; id recording or morse string see http://ohnosec.org/drupal/node/87
; idtalkover = |iWA4XYZ                 ; Talkover ID (optional) default is none see http://ohnosec.org/drupal/node/129

[1998]
; EchoLink
rxchannel = dahdi/pseudo              ; No radio (hub)



On 07/01/2017 04:32 PM, Steve Siesel [K4KSA] wrote:

All,

 

I am running Allstar<>Analog_Bridge<>HB_Bridge, as an Analog to DMR Gateway. It is still in the testing phase as I still need to find a solution to keep Allison from talking out on DMR. I have been working with Steve on this, and hope to work it out soon!

 

Steve

K4KSA



HBLink and DMRLink

Steve Siesel [K4KSA]
 

All,

 

I am running Allstar<>Analog_Bridge<>HB_Bridge, as an Analog to DMR Gateway. It is still in the testing phase as I still need to find a solution to keep Allison from talking out on DMR. I have been working with Steve on this, and hope to work it out soon!

 

Steve

K4KSA


HBlink and DMRlink in "production"

Steve N4IRS
 

If you are running any of the code in production, please post a description here. That would be DMRlink, HBlink, Analog_Bridge, HB_Bridge or IPSC_Bridge.

I have been running DMRlink Conference Bridge to connect my 3 Motorola repeaters to DMR-MARC, BM and DCI. It has been running day in and day out for quite some time.  This gives me great control of what TGs are available and keeping unneeded traffic off a repeater if no one is using it. That way 2 different repeaters can be using different TGs on the same TS. Works great.

Today I added HB_Bridge and IPSC_Bridge to the mix. I have 1 MMDVM based repeater that was directly connected to BM. Now with HB_Bridge and IPSC_Bridge, it is now part of the network. This means that Local (TS2 / TG2) on the MMDVM repeater is connected to Local on the Motorola repeaters. I did block DMR-MARC from the MMDVM repeater (for now) Next is to give the locals a place to connect their hot spots. 

Steve N4IRS


Re: Brandmeister

Steve N4IRS
 

Since DMRlink does not speak XCMP, BM wants to treat us a SmartPTT.
See <https://groups.io/g/DVSwitch/wiki/DMRlink-and-BrandMeister>

73, Steve N4IRS

On 07/01/2017 10:28 AM, David Andrzejewski KD8TWG via Groups.Io wrote:
Apparently, because BrandMeister sees dmrlink as SmartPTT, that means that they have to statically configure a talk group for each time slot, and that's all you get.  It would be nifty if we could make BrandMeister see dmrlink as a regular repeater, so we could get all the features that they offer (dashboard, reflectors, etc)...


Re: Brandmeister

David Andrzejewski KD8TWG
 

Apparently, because BrandMeister sees dmrlink as SmartPTT, that means that they have to statically configure a talk group for each time slot, and that's all you get.  It would be nifty if we could make BrandMeister see dmrlink as a regular repeater, so we could get all the features that they offer (dashboard, reflectors, etc)...


Re: Peer list not updating after RDAC connection?

Cort N0MJS <n0mjs@...>
 

No, but I've seen things like this before. Let me know if it last longer than 15 minutes?

Sent from my iPhone

On Jun 30, 2017, at 4:03 PM, David Andrzejewski KD8TWG via Groups.Io <david@...> wrote:

Judging by your response... not long enough ;)

Is there a timeout?


Re: Peer list not updating after RDAC connection?

David Andrzejewski KD8TWG
 

Judging by your response... not long enough ;)

Is there a timeout?


Re: Peer list not updating after RDAC connection?

Cort N0MJS <n0mjs@...>
 

How long have you let it go?

Sent from my iPhone

On Jun 30, 2017, at 12:35 PM, David Andrzejewski KD8TWG via Groups.Io <david@...> wrote:

I've got dmrlink (confbridge.py) connected to my repeater - the repeater is the master.  When I connect RDAC to the repeater, dmrlink gets the updated peer list.  But when I disconnect, it does not appear to receive it.  Perhaps the repeater does not send it?  So after I disconnect RDAC, it's still 'stuck' in the peer list, and dmrlink keeps trying to register with it:

INFO 2017-06-30 17:34:23,424 (REPEATER) Registering with Peer 3139024, 10.8.0.97:50000
INFO 2017-06-30 17:34:38,424 (REPEATER) Registering with Peer 3139024, 10.8.0.97:50000

Seems like restarting the application is the only way to get it to stop.


Peer list not updating after RDAC connection?

David Andrzejewski KD8TWG
 

I've got dmrlink (confbridge.py) connected to my repeater - the repeater is the master.  When I connect RDAC to the repeater, dmrlink gets the updated peer list.  But when I disconnect, it does not appear to receive it.  Perhaps the repeater does not send it?  So after I disconnect RDAC, it's still 'stuck' in the peer list, and dmrlink keeps trying to register with it:

INFO 2017-06-30 17:34:23,424 (REPEATER) Registering with Peer 3139024, 10.8.0.97:50000
INFO 2017-06-30 17:34:38,424 (REPEATER) Registering with Peer 3139024, 10.8.0.97:50000

Seems like restarting the application is the only way to get it to stop.


Re: ACL in routing apps

Peter M0NWI
 

Hi Matthew,


My longer term goal was to be able to say use a web page to add entries, or even an automated algorithm to calculate excessive blocking of TG's and add an entry for a specific time period?


73,

Peter



From: DVSwitch@groups.io <DVSwitch@groups.io> on behalf of Matthew 2E0SIP <groups.io@...>
Sent: 30 June 2017 10:55
To: DVSwitch@groups.io
Subject: Re: [DVSwitch] ACL in routing apps
 
How would you signal it to re-read it? Network socket? Signal to the process?
My personal suggestion would be to explore using a distributed distributed hash table such as memcached or REDIS, so external processes can add/remove the ACLs when required.

A distributed 'database' could also be used in future for ensuring redundancy (Two HB Link servers, with shared states),  'switching' private calls (I.E which DMR ID is behind which HB/IPSC client for efficient routing of calls), and also aid with building a user interface similar to the BM dashboard where a user can assign and unassign talk groups

Maybe I'm getting carried away...


Re: ACL in routing apps

Matthew 2E0SIP
 

How would you signal it to re-read it? Network socket? Signal to the process?
My personal suggestion would be to explore using a distributed distributed hash table such as memcached or REDIS, so external processes can add/remove the ACLs when required.

A distributed 'database' could also be used in future for ensuring redundancy (Two HB Link servers, with shared states),  'switching' private calls (I.E which DMR ID is behind which HB/IPSC client for efficient routing of calls), and also aid with building a user interface similar to the BM dashboard where a user can assign and unassign talk groups

Maybe I'm getting carried away...


Re: IPSC/HB bridges; CC links

Steve N4IRS
 

HB_Bridge has no problem with it. A DMO connection (Hot Spot) is only 1 slot.

On 06/29/2017 06:00 PM, Rob WX1N wrote:
I think the MMDVMHost code allows for each slot to be linked to a different server. If that's correct, would HB behave properly if only one slot were connected to it? Then, for instance, one slot could be connected directly to BM, preserving private calls, text messages, GPS, etc. on that slot.


-------- Original Message --------
From: Cort N0MJS <n0mjs@me.com>
Sent: June 29, 2017 4:52:55 PM EDT
To: DVSwitch@groups.io
Subject: Re: [DVSwitch] IPSC/HB bridges; CC links

Each packet type has it’s own callback function. That’s already in the code… but those callbacks don’t do anything at the moment — effectively the traffic is just dropped.

On Jun 29, 2017, at 3:27 PM, Rob WX1N <rob@nollmail.com> wrote:

It just drops/ignores anything else?

From: DVSwitch@groups.io <mailto:DVSwitch@groups.io> [mailto:DVSwitch@groups.io <mailto:DVSwitch@groups.io>] On Behalf Of Cort N0MJS
Sent: Thursday, June 29, 2017 4:22 PM
To: DVSwitch@groups.io <mailto:DVSwitch@groups.io>
Subject: Re: [DVSwitch] IPSC/HB bridges; CC links

Not as of now — only processing group voice packets at the moment.

On Jun 29, 2017, at 3:18 PM, Rob WX1N <rob@nollmail.com <mailto:rob@nollmail.com>> wrote:

Ok thanks so much to both of you, I think I’ve got it now. If not, you know I’ll be back. We have a couple of MMDVM repeaters set up here, currently on BrandMeister. We enjoy the flexibility and the ability to play around with things like text messages and private calls, but probably 95% of the DMR repeaters in our neck of the woods are DMR-MARC. What I’d eventually like to do is talk to the folks who have the local c-Bridges and see if they would allow us access to the statewide talkgroups.
Speaking of text messages private calls – can either of you tell me, is there a way to instruct hb_confbridge host to route them, or at least to send them all through to one connected network?

From: DVSwitch@groups.io <mailto:DVSwitch@groups.io> [mailto:DVSwitch@groups.io <mailto:DVSwitch@groups.io>] On Behalf Of Cort N0MJS
Sent: Thursday, June 29, 2017 4:12 PM
To: DVSwitch@groups.io <mailto:DVSwitch@groups.io>
Subject: Re: [DVSwitch] IPSC/HB bridges; CC links

You can specify an alternate configuration file on the command line — and that’s how I run them all. Steve likes to make full copies, and that’s probably a great way to do it. I’m a little more old school and run them out of the same location with -c

Cortneys-MacBook-Pro:HBlink cort$ python hb_confbridge.py --help
usage: hb_confbridge.py [-h] [-c CONFIG_FILE] [-l LOG_LEVEL]

optional arguments:
-h, --help show this help message and exit
-c CONFIG_FILE, --config CONFIG_FILE
/full/path/to/config.file (usually hblink.cfg)
-l LOG_LEVEL, --logging LOG_LEVEL
Override config file logging level.
Cortneys-MacBook-Pro:HBlink cort$

MMDVM<->hb_confbridge.py<->HB_Bridge<->IPSC_Bridge<->confbridge.py<->IPSC peers.

Today, I’m running it this way:

MMDVM<->HB_Bridge<->IPSC_Bridge<->confbridge.py<->IPSC peers

Note the thing missing is hb_confbridge.py because I have only 2 MMDVM repeaters, and I let them both carry the same traffic (like peers on a single IPSC system). I pick up all of my “northbound” TGID traffic from confbridge.py (DMRlink) with Brandmeister, DMR-MARC via c-Bridge, etc.

That looks like a crazy string of things running, but they still seem to use a marginal amount of resources….. not sure if this helps or not, Rob…. but the thing definitely, right now, is to put confbridge.py (IPSC) and hb_confbridge.py (HBP) between the actual repeaters and HB_Bridge and IPSC_Bridge respectively.

0x49 DE N0MJS

On Jun 29, 2017, at 2:56 PM, Rob WX1N <rob@nollmail.com <mailto:rob@nollmail.com>> wrote:

Right, I know not to do that – that’s why I’m trying to understand how to avoid it. Right now what I’m trying to do is just get a working example going to get familiar with it. I have a few ideas down the road that I might like to try but I don’t want to pursue them until I have a good working knowledge of what I’m doing on my end.
I’ve gotten as far as the setup you describe, MMDVM<>HB_Bridge<>IPSC_Bridge<>IPSC connection (sort of – you were discussing the BM end of the IPSC connection with me, but it appeared that I had the setup on my end working the way I intended it to, it just wasn’t going anywhere). I’ve also played around with the conference bridges before and have a decent knowledge of how to set them up and configure them. The part that isn’t clear to me is where the conference bridge would come in in the setup described above. For example, taking the example setup above, where in that setup would the HB link conference bridge come in? I assume as a separate instance, but once you set up the configuration file for the conference bridge portion of HB link to connect to an outside network such as BM, wouldn’t that then be picked up by the HB_Bridge portion, and the talkgroups from that connection be routed through to the IPSC side? Or do you need to have duplicate copies of the HB link folder, one to run the Bridge, and connect to a separate copy of the software in another folder, which would accept the bridge’s connection, and then route it’s traffic through the conference bridge? Something like:
MMDVM logs in to HBlink conf bridge (HBlink copy 1)
HBlink conf bridge (HBlink folder 1) logs in to BM, and routes certain TG’s there, and also logs in to HB_Bridge (HBlink folder 2), and routes certain talkgroups there
?

Rob


From: DVSwitch@groups.io <mailto:DVSwitch@groups.io> [mailto:DVSwitch@groups.io <mailto:DVSwitch@groups.io>] On Behalf Of Steve N4IRS
Sent: Thursday, June 29, 2017 3:45 PM
To: DVSwitch@groups.io <mailto:DVSwitch@groups.io>
Subject: Re: [DVSwitch] IPSC/HB bridges; CC links

The current state is intended for actual implementation. In your example, Yes HB_Bridge will use HBlink and the hblink.cfg to create a Server the your MMDVM clients can connect to. When you start IPSC_Bridge it will use DMRlink and dmrlink.cfg to connect to a c-Bridge. Any traffic from MMDVM will pass from HB_Bridge to IPSC_Bridge. You will have MMDVM <---> HB_Bridge <---> IPSC_Bridge <---> c-Bridge.

Yes, in theory, you could connect a client to BM and a Peer to c-Bridge. DO NOT DO IT !!! BM supports CC-CC.

I think what you want to do is provide Talk Groups from both BM and c-Bridge to MMDVM Clients. To do that, you would use conference bridge. The choice of which Conference Bridge and how to build it depends on what you are really trying to do.

Steve

Cort Buffington
785-865-7206


Cort Buffington
785-865-7206

Cort Buffington
785-865-7206



Re: IPSC/HB bridges; CC links

Rob WX1N
 

I think the MMDVMHost code allows for each slot to be linked to a different server. If that's correct, would HB behave properly if only one slot were connected to it? Then, for instance, one slot could be connected directly to BM, preserving private calls, text messages, GPS, etc. on that slot.

-------- Original Message --------
From: Cort N0MJS <n0mjs@me.com>
Sent: June 29, 2017 4:52:55 PM EDT
To: DVSwitch@groups.io
Subject: Re: [DVSwitch] IPSC/HB bridges; CC links

Each packet type has it’s own callback function. That’s already in the code… but those callbacks don’t do anything at the moment — effectively the traffic is just dropped.

On Jun 29, 2017, at 3:27 PM, Rob WX1N <rob@nollmail.com> wrote:

It just drops/ignores anything else?

From: DVSwitch@groups.io <mailto:DVSwitch@groups.io> [mailto:DVSwitch@groups.io <mailto:DVSwitch@groups.io>] On Behalf Of Cort N0MJS
Sent: Thursday, June 29, 2017 4:22 PM
To: DVSwitch@groups.io <mailto:DVSwitch@groups.io>
Subject: Re: [DVSwitch] IPSC/HB bridges; CC links

Not as of now — only processing group voice packets at the moment.

On Jun 29, 2017, at 3:18 PM, Rob WX1N <rob@nollmail.com <mailto:rob@nollmail.com>> wrote:

Ok thanks so much to both of you, I think I’ve got it now. If not, you know I’ll be back. We have a couple of MMDVM repeaters set up here, currently on BrandMeister. We enjoy the flexibility and the ability to play around with things like text messages and private calls, but probably 95% of the DMR repeaters in our neck of the woods are DMR-MARC. What I’d eventually like to do is talk to the folks who have the local c-Bridges and see if they would allow us access to the statewide talkgroups.
Speaking of text messages private calls – can either of you tell me, is there a way to instruct hb_confbridge host to route them, or at least to send them all through to one connected network?

From: DVSwitch@groups.io <mailto:DVSwitch@groups.io> [mailto:DVSwitch@groups.io <mailto:DVSwitch@groups.io>] On Behalf Of Cort N0MJS
Sent: Thursday, June 29, 2017 4:12 PM
To: DVSwitch@groups.io <mailto:DVSwitch@groups.io>
Subject: Re: [DVSwitch] IPSC/HB bridges; CC links

You can specify an alternate configuration file on the command line — and that’s how I run them all. Steve likes to make full copies, and that’s probably a great way to do it. I’m a little more old school and run them out of the same location with -c

Cortneys-MacBook-Pro:HBlink cort$ python hb_confbridge.py --help
usage: hb_confbridge.py [-h] [-c CONFIG_FILE] [-l LOG_LEVEL]

optional arguments:
-h, --help show this help message and exit
-c CONFIG_FILE, --config CONFIG_FILE
/full/path/to/config.file (usually hblink.cfg)
-l LOG_LEVEL, --logging LOG_LEVEL
Override config file logging level.
Cortneys-MacBook-Pro:HBlink cort$

MMDVM<->hb_confbridge.py<->HB_Bridge<->IPSC_Bridge<->confbridge.py<->IPSC peers.

Today, I’m running it this way:

MMDVM<->HB_Bridge<->IPSC_Bridge<->confbridge.py<->IPSC peers

Note the thing missing is hb_confbridge.py because I have only 2 MMDVM repeaters, and I let them both carry the same traffic (like peers on a single IPSC system). I pick up all of my “northbound” TGID traffic from confbridge.py (DMRlink) with Brandmeister, DMR-MARC via c-Bridge, etc.

That looks like a crazy string of things running, but they still seem to use a marginal amount of resources….. not sure if this helps or not, Rob…. but the thing definitely, right now, is to put confbridge.py (IPSC) and hb_confbridge.py (HBP) between the actual repeaters and HB_Bridge and IPSC_Bridge respectively.

0x49 DE N0MJS

On Jun 29, 2017, at 2:56 PM, Rob WX1N <rob@nollmail.com <mailto:rob@nollmail.com>> wrote:

Right, I know not to do that – that’s why I’m trying to understand how to avoid it. Right now what I’m trying to do is just get a working example going to get familiar with it. I have a few ideas down the road that I might like to try but I don’t want to pursue them until I have a good working knowledge of what I’m doing on my end.
I’ve gotten as far as the setup you describe, MMDVM<>HB_Bridge<>IPSC_Bridge<>IPSC connection (sort of – you were discussing the BM end of the IPSC connection with me, but it appeared that I had the setup on my end working the way I intended it to, it just wasn’t going anywhere). I’ve also played around with the conference bridges before and have a decent knowledge of how to set them up and configure them. The part that isn’t clear to me is where the conference bridge would come in in the setup described above. For example, taking the example setup above, where in that setup would the HB link conference bridge come in? I assume as a separate instance, but once you set up the configuration file for the conference bridge portion of HB link to connect to an outside network such as BM, wouldn’t that then be picked up by the HB_Bridge portion, and the talkgroups from that connection be routed through to the IPSC side? Or do you need to have duplicate copies of the HB link folder, one to run the Bridge, and connect to a separate copy of the software in another folder, which would accept the bridge’s connection, and then route it’s traffic through the conference bridge? Something like:
MMDVM logs in to HBlink conf bridge (HBlink copy 1)
HBlink conf bridge (HBlink folder 1) logs in to BM, and routes certain TG’s there, and also logs in to HB_Bridge (HBlink folder 2), and routes certain talkgroups there
?

Rob


From: DVSwitch@groups.io <mailto:DVSwitch@groups.io> [mailto:DVSwitch@groups.io <mailto:DVSwitch@groups.io>] On Behalf Of Steve N4IRS
Sent: Thursday, June 29, 2017 3:45 PM
To: DVSwitch@groups.io <mailto:DVSwitch@groups.io>
Subject: Re: [DVSwitch] IPSC/HB bridges; CC links

The current state is intended for actual implementation. In your example, Yes HB_Bridge will use HBlink and the hblink.cfg to create a Server the your MMDVM clients can connect to. When you start IPSC_Bridge it will use DMRlink and dmrlink.cfg to connect to a c-Bridge. Any traffic from MMDVM will pass from HB_Bridge to IPSC_Bridge. You will have MMDVM <---> HB_Bridge <---> IPSC_Bridge <---> c-Bridge.

Yes, in theory, you could connect a client to BM and a Peer to c-Bridge. DO NOT DO IT !!! BM supports CC-CC.

I think what you want to do is provide Talk Groups from both BM and c-Bridge to MMDVM Clients. To do that, you would use conference bridge. The choice of which Conference Bridge and how to build it depends on what you are really trying to do.

Steve

Cort Buffington
785-865-7206


Cort Buffington
785-865-7206

Cort Buffington
785-865-7206


Re: IPSC/HB bridges; CC links

Rob WX1N
 

That might work if DMRlink were able to be used on both ends. My thought process in asking was that, since as I understand it a cBridge is limited to a certain number of repeaters, and in the use-case scenario I have in mind I would only want a couple talkgroups from the cBridge to use on both our repeaters, that it might have been a more efficient use of resources on the cBridge side to just share the TGs via a CC link rather than tie up two repeater slots. But I guess that's a moot point since it's not a viable option.

-------- Original Message --------
From: Peter M0NWI <peter-martin@outlook.com>
Sent: June 29, 2017 4:50:38 PM EDT
To: DVSwitch@groups.io
Subject: Re: [DVSwitch] IPSC/HB bridges; CC links



Could i add / remind that we do have the DMRlink to DMRlink bridge protocol, that works a bit like those below, but nit compatible of course.

73,
Peter

Sent from Outlook
________________________________
From: DVSwitch@groups.io <DVSwitch@groups.io> on behalf of Steve N4IRS <szingman@msgstor.com>
Sent: 29 June 2017 19:52:50
To: DVSwitch@groups.io
Subject: Re: [DVSwitch] IPSC/HB bridges; CC links

Rob,
No, DMRlink can not act as one end of a CC-CC link. That protocol, like BrandMeisters FastForward is proprietary. We have discussed trying to get together with the c-Bridge and BM people to layout a Open Source server to server protocol. We think this would be great addition to the HAM community in general.

In their basic form, there is no control of what TGs are sent between the two partners. That type of control would be external to the partners. Conference Bridge could be used to control what TGs were passed to "client" repeaters and servers.
As we move forward, DVSwitch Will become part of the mix. Rather then having Partners connect directly together, Partners will connect to DVSwitch and DVSwitch will control the routing data. DVSwitch is in early conceptional form. The questions and comments will help us better design the tool.

73, Steve


Re: Brandmeister

Peter M0NWI
 

You've seen my code (lash up!!) and i think you barfed :)

Sent from Outlook
From: DVSwitch@groups.io <DVSwitch@groups.io> on behalf of Cort N0MJS <n0mjs@...>
Sent: 29 June 2017 21:49:20
To: DVSwitch@groups.io
Subject: Re: [DVSwitch] Brandmeister
 
It could as soon as someone writes code for it :)

I’ve been thinking about this. There’s still a lot about RCM I don’t know very well, but as I get a little better handle on it in reality, could look into having it generate RCM.

On Jun 29, 2017, at 3:47 PM, Peter M0NWI <peter-martin@...> wrote:


Cory,

Can i ask, could DMRlink generate RCM type traffic?  I have a downstream user who hosts their own DMRlink, but as i use rcm_db_log, i don't get any logging from it.

73,
Peter

Sent from Outlook
From: DVSwitch@groups.io <DVSwitch@groups.io> on behalf of Cort N0MJS <n0mjs@...>
Sent: 29 June 2017 18:25:36
To: DVSwitch@groups.io
Subject: Re: [DVSwitch] Brandmeister
 
Well crap… Guess I should have fixed that! I’ll get it in the next general update.

Here’s the real deal with CON_APP.

The connection to DMRmonitor and RCM is that “repeater call monitor” (RCM) messages sent by repeaters to 3rd party console apps are different than the ones sent to non-3rd party console apps (or at least they were back when I first wrote this). If you leave “CON-APP” enabled, you’re telling all of the peers in the IPSC system that you’re not a repeater, but some other piece of software…. disabling it was an attempt to look like a repeater and the default I *personally* ended up using.

Brandmeister already knows DMRlink it’s a Motorola repeater because it doesn’t talk XCMP, and thus thinks DMRlink is SmartPTT anyway… and I don’t think a c-Bridge cares… so it may not matter much in reality.

On Jun 29, 2017, at 12:14 PM, Steve N4IRS <szingman@...> wrote:

They are both set true in the sample config. I set them to false in the IPSC_Bridge branch.
I do remember this in the comments:
# CON_APP:          Third Party Console App - exactly what DMRlink is, should
#                   be set to True, and must be if you intend to process RCM


On 6/29/2017 1:05 PM, Cort N0MJS wrote:
Those tell me Steve is running DMRmonitor also — you should set both to False unless you’re using DMRmonitor also, or know exactly what they do and know you need them.

On Jun 29, 2017, at 11:40 AM, Steve N4IRS <szingman@...> wrote:

RCM: True
CON_APP: True

Cort Buffington
785-865-7206



Cort Buffington
785-865-7206


Cort Buffington
785-865-7206


Re: ACL in routing apps

Peter M0NWI
 


Not thought that through, would be nice to have it detect a hup of some sort, but i suppose i was just thinking of dropping it into the same timespace used by the TG timer flipper, so once a minute?

Sent from Outlook
From: DVSwitch@groups.io <DVSwitch@groups.io> on behalf of Cort N0MJS <n0mjs@...>
Sent: 29 June 2017 21:48:02
To: DVSwitch@groups.io
Subject: Re: [DVSwitch] ACL in routing apps
 
How would you signal it to re-read it? Network socket? Signal to the process?

On Jun 29, 2017, at 3:35 PM, Peter M0NWI <peter-martin@...> wrote:


I think it's great but I would :)

I'd  like a way for it to re-read the file without restarting the bridge though, but I'm hoping to add that, unless its something your on with?

73,
Peter

Sent from Outlook 
From: DVSwitch@groups.io <DVSwitch@groups.io> on behalf of Cort N0MJS <n0mjs@...>
Sent: 29 June 2017 18:07:51
To: DVSwitch@groups.io
Subject: [DVSwitch] ACL in routing apps
 
Guys,

Is anyone using the Access Control List function of bridge, confbridge or proxy?

I have written a much better parser that allows you to use ranges for allowed or denied radio IDs…. but if nobody is using it, why bother, right? If I make the changes, you’ll have to change your ACL file format. So, questions are:

1) you want me to update it?
2) if you have no idea what I’m talking about, should I explain more?

0x49 DE N0MJS

Cort Buffington
785-865-7206





Cort Buffington
785-865-7206


Re: IPSC/HB bridges; CC links

Cort N0MJS <n0mjs@...>
 

Yeah, that’s really just IPSC, but forwards everything without checking for a TS busy… even if I ever got around to setting TGID as 3 for all traffic on inter-DMRlink connections, it’s still just IPSC and not an “open source” protocol, but my version of Motorola’s.

On Jun 29, 2017, at 3:50 PM, Peter M0NWI <peter-martin@...> wrote:



Could i add / remind that we do have the DMRlink to DMRlink bridge protocol, that works a bit like those below, but nit compatible of course.

73,
Peter

Sent from Outlook
From: DVSwitch@groups.io <DVSwitch@groups.io> on behalf of Steve N4IRS <szingman@...>
Sent: 29 June 2017 19:52:50
To: DVSwitch@groups.io
Subject: Re: [DVSwitch] IPSC/HB bridges; CC links
 
Rob,
No, DMRlink can not act as one end of a CC-CC link. That protocol, like BrandMeisters FastForward is proprietary. We have discussed trying to get together with the c-Bridge and BM people to layout a Open Source server to server protocol. We think this would be great addition to the HAM community in general.

In their basic form, there is no control of what TGs are sent between the two partners. That type of control would be external to the partners. Conference Bridge could be used to control what TGs were passed to "client" repeaters and servers.
As we move forward, DVSwitch Will become part of the mix. Rather then having Partners connect directly together, Partners will connect to DVSwitch and DVSwitch will control the routing data. DVSwitch is in early conceptional form. The questions and comments will help us better design the tool.

73, Steve 

Cort Buffington
785-865-7206


Re: IPSC/HB bridges; CC links

Cort N0MJS <n0mjs@...>
 

Each packet type has it’s own callback function. That’s already in the code… but those callbacks don’t do anything at the moment — effectively the traffic is just dropped.

On Jun 29, 2017, at 3:27 PM, Rob WX1N <rob@...> wrote:

It just drops/ignores anything else?
 
From: DVSwitch@groups.io [mailto:DVSwitch@groups.io] On Behalf Of Cort N0MJS
Sent: Thursday, June 29, 2017 4:22 PM
To: DVSwitch@groups.io
Subject: Re: [DVSwitch] IPSC/HB bridges; CC links
 
Not as of now — only processing group voice packets at the moment.
 
On Jun 29, 2017, at 3:18 PM, Rob WX1N <rob@...> wrote:
 
Ok thanks so much to both of you, I think I’ve got it now.  If not, you know I’ll be back.  We have a couple of MMDVM repeaters set up here, currently on BrandMeister.  We enjoy the flexibility and the ability to play around with things like text messages and private calls, but probably 95% of the DMR repeaters in our neck of the woods are DMR-MARC.  What I’d eventually like to do is talk to the folks who have the local c-Bridges and see if they would allow us access to the statewide talkgroups.
Speaking of text messages private calls – can either of you tell me, is there a way to instruct hb_confbridge host to route them, or at least to send them all through to one connected network?
 
From: DVSwitch@groups.io [mailto:DVSwitch@groups.io] On Behalf Of Cort N0MJS
Sent: Thursday, June 29, 2017 4:12 PM
To: DVSwitch@groups.io
Subject: Re: [DVSwitch] IPSC/HB bridges; CC links
 
You can specify an alternate configuration file on the command line — and that’s how I run them all. Steve likes to make full copies, and that’s probably a great way to do it. I’m a little more old school and run them out of the same location with -c
 
Cortneys-MacBook-Pro:HBlink cort$ python hb_confbridge.py --help
usage: hb_confbridge.py [-h] [-c CONFIG_FILE] [-l LOG_LEVEL]
 
optional arguments:
  -h, --help            show this help message and exit
  -c CONFIG_FILE, --config CONFIG_FILE
                        /full/path/to/config.file (usually hblink.cfg)
  -l LOG_LEVEL, --logging LOG_LEVEL
                        Override config file logging level.
Cortneys-MacBook-Pro:HBlink cort$ 
 
MMDVM<->hb_confbridge.py<->HB_Bridge<->IPSC_Bridge<->confbridge.py<->IPSC peers.
 
Today, I’m running it this way:
 
MMDVM<->HB_Bridge<->IPSC_Bridge<->confbridge.py<->IPSC peers
 
Note the thing missing is hb_confbridge.py because I have only 2 MMDVM repeaters, and I let them both carry the same traffic (like peers on a single IPSC system). I pick up all of my “northbound” TGID traffic from confbridge.py (DMRlink) with Brandmeister, DMR-MARC via c-Bridge, etc.
 
That looks like a crazy string of things running, but they still seem to use a marginal amount of resources….. not sure if this helps or not, Rob…. but the thing definitely, right now, is to put confbridge.py (IPSC) and hb_confbridge.py (HBP) between the actual repeaters and HB_Bridge and IPSC_Bridge respectively.
 
0x49 DE N0MJS
 
On Jun 29, 2017, at 2:56 PM, Rob WX1N <rob@...> wrote:
 
Right, I know not to do that – that’s why I’m trying to understand how to avoid it.  Right now what I’m trying to do is just get a working example going to get familiar with it.  I have a few ideas down the road that I might like to try but I don’t want to pursue them until I have a good working knowledge of what I’m doing on my end.
I’ve gotten as far as the setup you describe, MMDVM<>HB_Bridge<>IPSC_Bridge<>IPSC connection (sort of – you were discussing the BM end of the IPSC connection with me, but it appeared that I had the setup on my end working the way I intended it to, it just wasn’t going anywhere).  I’ve also played around with the conference bridges before and have a decent knowledge of how to set them up and configure them.  The part that isn’t clear to me is where the conference bridge would come in in the setup described above.  For example, taking the example setup above, where in that setup would the HB link conference bridge come in?  I assume as a separate instance, but once you set up the configuration file for the conference bridge portion of  HB link to connect to an outside network such as BM, wouldn’t that then be picked up by the HB_Bridge portion, and the talkgroups from that connection be routed through to the IPSC side?  Or do you need to have duplicate copies of the HB link folder, one to run the Bridge, and connect to a separate copy of the software in another folder, which would accept the bridge’s connection, and then route it’s traffic through the conference bridge?  Something like:
MMDVM logs in to HBlink conf bridge (HBlink copy 1)
HBlink conf bridge (HBlink folder 1) logs in to BM, and routes certain TG’s there, and also logs in to HB_Bridge (HBlink folder 2), and routes certain talkgroups there
?
 
Rob
 
 
From: DVSwitch@groups.io [mailto:DVSwitch@groups.io] On Behalf Of Steve N4IRS
Sent: Thursday, June 29, 2017 3:45 PM
To: DVSwitch@groups.io
Subject: Re: [DVSwitch] IPSC/HB bridges; CC links
 
The current state is intended for actual implementation. In your example, Yes HB_Bridge will use HBlink and the hblink.cfg to create a Server the your MMDVM clients can connect to. When you start IPSC_Bridge it will use DMRlink and dmrlink.cfg to connect to a c-Bridge. Any traffic from MMDVM will pass from HB_Bridge to IPSC_Bridge. You will have MMDVM <---> HB_Bridge <---> IPSC_Bridge <---> c-Bridge.

Yes, in theory, you could connect a client to BM and a Peer to c-Bridge. DO NOT DO IT !!! BM supports CC-CC.

I think what you want to do is provide Talk Groups from both BM and c-Bridge to MMDVM Clients. To do that, you would use conference bridge. The choice of which Conference Bridge and how to build it depends on what you are really trying to do.

Steve  
 
Cort Buffington
785-865-7206
 
 
Cort Buffington
785-865-7206
 


Cort Buffington
785-865-7206


Re: IPSC/HB bridges; CC links

Peter M0NWI
 



Could i add / remind that we do have the DMRlink to DMRlink bridge protocol, that works a bit like those below, but nit compatible of course.

73,
Peter

Sent from Outlook
From: DVSwitch@groups.io <DVSwitch@groups.io> on behalf of Steve N4IRS <szingman@...>
Sent: 29 June 2017 19:52:50
To: DVSwitch@groups.io
Subject: Re: [DVSwitch] IPSC/HB bridges; CC links
 
Rob,
No, DMRlink can not act as one end of a CC-CC link. That protocol, like BrandMeisters FastForward is proprietary. We have discussed trying to get together with the c-Bridge and BM people to layout a Open Source server to server protocol. We think this would be great addition to the HAM community in general.

In their basic form, there is no control of what TGs are sent between the two partners. That type of control would be external to the partners. Conference Bridge could be used to control what TGs were passed to "client" repeaters and servers.
As we move forward, DVSwitch Will become part of the mix. Rather then having Partners connect directly together, Partners will connect to DVSwitch and DVSwitch will control the routing data. DVSwitch is in early conceptional form. The questions and comments will help us better design the tool.

73, Steve 


Re: Brandmeister

Cort N0MJS <n0mjs@...>
 

It could as soon as someone writes code for it :)

I’ve been thinking about this. There’s still a lot about RCM I don’t know very well, but as I get a little better handle on it in reality, could look into having it generate RCM.

On Jun 29, 2017, at 3:47 PM, Peter M0NWI <peter-martin@...> wrote:


Cory,

Can i ask, could DMRlink generate RCM type traffic?  I have a downstream user who hosts their own DMRlink, but as i use rcm_db_log, i don't get any logging from it.

73,
Peter

Sent from Outlook
From: DVSwitch@groups.io <DVSwitch@groups.io> on behalf of Cort N0MJS <n0mjs@...>
Sent: 29 June 2017 18:25:36
To: DVSwitch@groups.io
Subject: Re: [DVSwitch] Brandmeister
 
Well crap… Guess I should have fixed that! I’ll get it in the next general update.

Here’s the real deal with CON_APP.

The connection to DMRmonitor and RCM is that “repeater call monitor” (RCM) messages sent by repeaters to 3rd party console apps are different than the ones sent to non-3rd party console apps (or at least they were back when I first wrote this). If you leave “CON-APP” enabled, you’re telling all of the peers in the IPSC system that you’re not a repeater, but some other piece of software…. disabling it was an attempt to look like a repeater and the default I *personally* ended up using.

Brandmeister already knows DMRlink it’s a Motorola repeater because it doesn’t talk XCMP, and thus thinks DMRlink is SmartPTT anyway… and I don’t think a c-Bridge cares… so it may not matter much in reality.

On Jun 29, 2017, at 12:14 PM, Steve N4IRS <szingman@...> wrote:

They are both set true in the sample config. I set them to false in the IPSC_Bridge branch.
I do remember this in the comments:
# CON_APP:          Third Party Console App - exactly what DMRlink is, should
#                   be set to True, and must be if you intend to process RCM


On 6/29/2017 1:05 PM, Cort N0MJS wrote:
Those tell me Steve is running DMRmonitor also — you should set both to False unless you’re using DMRmonitor also, or know exactly what they do and know you need them.

On Jun 29, 2017, at 11:40 AM, Steve N4IRS <szingman@...> wrote:

RCM: True
CON_APP: True

Cort Buffington
785-865-7206



Cort Buffington
785-865-7206


Cort Buffington
785-865-7206

9561 - 9580 of 9801