1. Topics
  2. confbridge.py and TG Bridge state change fun

confbridge.py and TG Bridge state change fun

JJ Cummings
 

I have been playing with DMRLink and HBLink (using IPSC_Bridge and HB_Bridge branches) and have a system up and running that looks like follows:

<HB Repeaters><--> [HB_Bridge] <--> [IPSC_Bridge] <--> [confbridge.py] <--> <CBridge>

This setup is working very well, confbridge.py is of course used to define what TGs are allowed to bridge between the HB and IPSC sides.  Today I decided to try and add some Timeout type bridges and have not had any luck.  Below is an example bridge group:

 
BRIDGES = {
     'BM-COLORADO': [
            {'SYSTEM': 'IPSC_MASTER',    'TS': 1, 'TGID': 3108, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []},
            {'SYSTEM': 'IPSC_BRIDGE_PEER',    'TS': 1, 'TGID': 3108, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'ON', 'ON': [3108,], 'OFF': [], 'RESET': []}
        ]
}
In the above, IPSC_MASTER is the Master that the CBridge connects to and IPSC_BRIDGE_PEER is the peer that connects into the Master listening on the IPSC_BRIDGE instance.  So when a call is initiated on the HB side of the house it will come through the IPSC_Bridge and end up at the IPSC_BRIDGE_PEER.

Having said all of this I have debugged the problem back to a triggering event issue, and I don't know if I have misconfigured something or if it's just a thing that needs to be added.  The CONNECT action for a Bridge triggers when a GROUP VOICE END event occurs (Line 372 in confbridge.py) and when a call initiates from HB -> IPSC there is only a GROUP VOICE START event (and the same is true for IPSC -> HB incidentally)..

Example: (when calling from HB -> IPSC)
Debug from confbridge.py
INFO 2017-11-08 14:20:39,635 (IPSC_BRIDGE_PEER) GROUP VOICE START: CallID: 144 PEER: 54324, SUB: 3108853, TS: 2, TGID: 3108

Debug from HB_Bridge
INFO 2017-11-08 14:20:39,606 Voice Transmission Start on TS 2 and TG BM_COLORADO (3108) from N0PKT
INFO 2017-11-08 14:20:53,457 Voice Transmission End 13.84 seconds loss rate: 0.43% (230/231)

So as you can see from the above the triggering event never actually makes it over to the IPSC side, I'm gonna continue stepping back through the code to see if I can't find what/when/where, but I thought that someone may have a simple answer for me...
JJ Cummings
 

You will see in the log that I posted a different TS than the one listed in the Bridges config, this is simply because I grabbed a log from a different transmission, the problem is still present regardless of TS...

On Wed, Nov 8, 2017 at 2:30 PM, JJ Cummings <cummingsj@...> wrote:
I have been playing with DMRLink and HBLink (using IPSC_Bridge and HB_Bridge branches) and have a system up and running that looks like follows:

<HB Repeaters><--> [HB_Bridge] <--> [IPSC_Bridge] <--> [confbridge.py] <--> <CBridge>

This setup is working very well, confbridge.py is of course used to define what TGs are allowed to bridge between the HB and IPSC sides.  Today I decided to try and add some Timeout type bridges and have not had any luck.  Below is an example bridge group:

 
BRIDGES = {
     'BM-COLORADO': [
            {'SYSTEM': 'IPSC_MASTER',    'TS': 1, 'TGID': 3108, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []},
            {'SYSTEM': 'IPSC_BRIDGE_PEER',    'TS': 1, 'TGID': 3108, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'ON', 'ON': [3108,], 'OFF': [], 'RESET': []}
        ]
}
In the above, IPSC_MASTER is the Master that the CBridge connects to and IPSC_BRIDGE_PEER is the peer that connects into the Master listening on the IPSC_BRIDGE instance.  So when a call is initiated on the HB side of the house it will come through the IPSC_Bridge and end up at the IPSC_BRIDGE_PEER.

Having said all of this I have debugged the problem back to a triggering event issue, and I don't know if I have misconfigured something or if it's just a thing that needs to be added.  The CONNECT action for a Bridge triggers when a GROUP VOICE END event occurs (Line 372 in confbridge.py) and when a call initiates from HB -> IPSC there is only a GROUP VOICE START event (and the same is true for IPSC -> HB incidentally)..

Example: (when calling from HB -> IPSC)
Debug from confbridge.py
INFO 2017-11-08 14:20:39,635 (IPSC_BRIDGE_PEER) GROUP VOICE START: CallID: 144 PEER: 54324, SUB: 3108853, TS: 2, TGID: 3108

Debug from HB_Bridge
INFO 2017-11-08 14:20:39,606 Voice Transmission Start on TS 2 and TG BM_COLORADO (3108) from N0PKT
INFO 2017-11-08 14:20:53,457 Voice Transmission End 13.84 seconds loss rate: 0.43% (230/231)

So as you can see from the above the triggering event never actually makes it over to the IPSC side, I'm gonna continue stepping back through the code to see if I can't find what/when/where, but I thought that someone may have a simple answer for me...


Corey Dean N3FE <n3fe@...>
 

Here is what mine looks like and works if you want a reference...

    'BMUSA': [
            {'SYSTEM': '3102',          'TS': 2, 'TGID': 3160, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [3160,], 'OFF': [10], 'RESET': []},
            {'SYSTEM': 'TEST',         'TS': 1, 'TGID': 3160, 'ACTIVE': True, 'TIMEOUT': 10, 'TO_TYPE': 'ON',  'ON': [3160,], 'OFF': [4000], 'RESET': []},
            {'SYSTEM': 'MASTER',    'TS': 1, 'TGID': 3160, 'ACTIVE': True, 'TIMEOUT': 10, 'TO_TYPE': 'ON',  'ON': [3160,], 'OFF': [4000], 'RESET': []}
        ],


Corey N3FE

Virus-free. www.avast.com

On Wed, Nov 8, 2017 at 4:30 PM, JJ Cummings <cummingsj@...> wrote:
I have been playing with DMRLink and HBLink (using IPSC_Bridge and HB_Bridge branches) and have a system up and running that looks like follows:

<HB Repeaters><--> [HB_Bridge] <--> [IPSC_Bridge] <--> [confbridge.py] <--> <CBridge>

This setup is working very well, confbridge.py is of course used to define what TGs are allowed to bridge between the HB and IPSC sides.  Today I decided to try and add some Timeout type bridges and have not had any luck.  Below is an example bridge group:

 
BRIDGES = {
     'BM-COLORADO': [
            {'SYSTEM': 'IPSC_MASTER',    'TS': 1, 'TGID': 3108, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []},
            {'SYSTEM': 'IPSC_BRIDGE_PEER',    'TS': 1, 'TGID': 3108, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'ON', 'ON': [3108,], 'OFF': [], 'RESET': []}
        ]
}
In the above, IPSC_MASTER is the Master that the CBridge connects to and IPSC_BRIDGE_PEER is the peer that connects into the Master listening on the IPSC_BRIDGE instance.  So when a call is initiated on the HB side of the house it will come through the IPSC_Bridge and end up at the IPSC_BRIDGE_PEER.

Having said all of this I have debugged the problem back to a triggering event issue, and I don't know if I have misconfigured something or if it's just a thing that needs to be added.  The CONNECT action for a Bridge triggers when a GROUP VOICE END event occurs (Line 372 in confbridge.py) and when a call initiates from HB -> IPSC there is only a GROUP VOICE START event (and the same is true for IPSC -> HB incidentally)..

Example: (when calling from HB -> IPSC)
Debug from confbridge.py
INFO 2017-11-08 14:20:39,635 (IPSC_BRIDGE_PEER) GROUP VOICE START: CallID: 144 PEER: 54324, SUB: 3108853, TS: 2, TGID: 3108

Debug from HB_Bridge
INFO 2017-11-08 14:20:39,606 Voice Transmission Start on TS 2 and TG BM_COLORADO (3108) from N0PKT
INFO 2017-11-08 14:20:53,457 Voice Transmission End 13.84 seconds loss rate: 0.43% (230/231)

So as you can see from the above the triggering event never actually makes it over to the IPSC side, I'm gonna continue stepping back through the code to see if I can't find what/when/where, but I thought that someone may have a simple answer for me...


JJ Cummings
 

Corey,

I appreciate the response, but I do not believe that the confbridge_rules have anything to do with this issue... it's a matter of the triggering event not happening across the IPSC_Bridge and HB_Bridge connection.
Mike Zingman - N4IRR
 

You are probably right. The bridge needs to synthesize the end event from the incoming data when it sees the end of stream signal. I will add a fix for this. 

Mike
JJ Cummings
 

Sounds like a plan, if I get the chance today I’ll see what I can do too and submit a pull request.  That said it’s already looking like a busy day of real life instead of radio fun

JJC 

Sent from the iRoad

On Nov 9, 2017, at 05:08, Mike Zingman - N4IRR <mike.zingman@...> wrote:

You are probably right. The bridge needs to synthesize the end event from the incoming data when it sees the end of stream signal. I will add a fix for this. 

Mike

JJ Cummings
 

Of course I have not had the time to get to this, hopefully sometime in the next few weeks I can sit down and look at it unless Mike has already done so?

On Thu, Nov 9, 2017 at 7:31 AM, JJ Cummings <cummingsj@...> wrote:
Sounds like a plan, if I get the chance today I’ll see what I can do too and submit a pull request.  That said it’s already looking like a busy day of real life instead of radio fun

JJC 

Sent from the iRoad

On Nov 9, 2017, at 05:08, Mike Zingman - N4IRR <mike.zingman@...> wrote:

You are probably right. The bridge needs to synthesize the end event from the incoming data when it sees the end of stream signal. I will add a fix for this. 

Mike


1 - 7 of 7