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


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 


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 


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 


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 


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


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


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

 


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


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

 


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 


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


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


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


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


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