Date   

IPSC/HB bridges; CC links

Rob WX1N
 

Good morning,

 

Hopefully these aren’t stupid questions…

Can DMR Link act as one end of a link that connects talkgroups between cBridges?  I believe they are called CC-CC links.

When using IPSC_Bridge and HB_Bridge, is there any control over which talkgroups sent between HBlink and DMRlink, are sent out over the networks to which HBlink/DMRlink are connected as a client?  Does running HB_Bridge cause a connection to be made to client networks in hblink.cfg?

 

Thanks for the help and patience,

 

Rob, WX1N


Re: Brandmeister

David Andrzejewski KD8TWG
 

I appreciate that.  Actually I'm more interested in seeing your BM_3108 defintion in dmrlink.cfg!

Thanks!


Re: Brandmeister

Steve N4IRS
 

[BM_3108]
ENABLED: True
RADIO_ID: 3112138
IP:
PORT: 53108
ALIVE_TIMER: 5
MAX_MISSED: 20
PEER_OPER: True
IPSC_MODE: DIGITAL
TS1_LINK: True
TS2_LINK: True
CSBK_CALL: False
RCM: True
CON_APP: True
XNL_CALL: False
XNL_MASTER: False
DATA_CALL: True
VOICE_CALL: True
MASTER_PEER: False
GROUP_HANGTIME: 5
AUTH_ENABLED: False
AUTH_KEY:
MASTER_IP: 3108.repeater.net
MASTER_PORT: 55001


On 6/29/2017 12:39 PM, David Andrzejewski KD8TWG via Groups.Io wrote:
I appreciate that.  Actually I'm more interested in seeing your BM_3108 defintion in dmrlink.cfg!

Thanks!


Re: Brandmeister

Cort N0MJS <n0mjs@...>
 

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


ACL in routing apps

Cort N0MJS <n0mjs@...>
 

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


Re: ACL in routing apps

Steve N4IRS
 

Who are you and why are you e-mail me?
I do not use the ACL. That is not to say I will never. Go ahead and change it.

Steve

On 6/29/2017 1:07 PM, Cort N0MJS wrote:
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



Re: Brandmeister

Steve N4IRS
 

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



Re: ACL in routing apps

Cort N0MJS <n0mjs@...>
 

Oh yeah, and the parsing is MUCH faster in the updated version… with ranges, I’m gonna need that right? Check this out:

time to build ACL: 10.89 seconds
radio IDs in ALC: 6003304
search time 1.90734863281e-06
subscriber 3120201 found in ACL

I had it build a list of about 6 million radio IDs to deny… while that took about 12 seconds for it to build while starting up, searching the list (python type ‘set’ actually - yes, it’s a hashed type) it takes about 2 microseconds to find a match. Now, that’s relative to the machine speed, but based on other per-packet processing actions these programs take, that’s round-off error.



On Jun 29, 2017, at 12:07 PM, Cort N0MJS <n0mjs@...> wrote:

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: Brandmeister

Cort N0MJS <n0mjs@...>
 

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


Re: IPSC/HB bridges; CC links

Steve N4IRS
 

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: IPSC/HB bridges; CC links

Rob WX1N
 

Steve,

 

Thanks so much as always for the helpful and informative response.  I agree that a server to server protocol would be nice but I’m sure that if it’s at all possible, it’s well off in the future.

 

Until  DVSwitch is operational, how would one go about utilizing selected talkgroups from separate external “client” networks, and most importantly, without patching these talkgroups so that they were repeated on the equivalent talkgroup of the other connected “client”?  Or is the current state intended for experimental testing only, and not for actual implementation yet?

 

For example:  we have a couple MMDVM repeaters.  If I run HB_Bridge, this will start a client which I can then connect an MMDVM repeater to.  If I run IPSC_Bridge, it will connect with HB_Bridge.  If I had the DMRlink.cfg file configured to connect to a c-Bridge “client”, and HBlink.cfg configured to connect to a Brandmeister “client”, wouldn’t that effectively bridge any talkgroups from the c-Bridge to Brandmeister, and vice versa?

 

Rob

 

From: DVSwitch@groups.io [mailto:DVSwitch@groups.io] On Behalf Of Steve N4IRS
Sent: Thursday, June 29, 2017 2:53 PM
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: IPSC/HB bridges; CC links

Steve N4IRS
 

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 


Re: IPSC/HB bridges; CC links

Rob WX1N
 

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 


Re: IPSC/HB bridges; CC links

Steve N4IRS
 

Ah,
Sorry, I am used to how we structured DMRlink into directories. I think of HBlink the same way. I will build the same type of script that I built for DMRlink. It creates a directory for each application, parrot, conference bridge etc. It puts copes of the needed files in each directory. That way you can run multiple instances. Each directory would have the configuration files configured as needed.

Steve


Re: IPSC/HB bridges; CC links

Cort N0MJS <n0mjs@...>
 

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


Re: IPSC/HB bridges; CC links

Rob WX1N
 

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

 


Re: IPSC/HB bridges; CC links

Cort N0MJS <n0mjs@...>
 

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


Re: IPSC/HB bridges; CC links

Rob WX1N
 

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

 


Re: ACL in routing apps

Peter M0NWI
 


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





Re: Brandmeister

Peter M0NWI
 


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

201 - 220 of 9882