You probably can. The reason for the creation of confbridge was that bridge was HARD to write rules for, and nobody actually used anything “asymmetric” that it could do and confbridge couldn’t.
Thanks for you're answer, even if it's not what I wanted 😊
Do you believe I can replicate what I have now under Confbridge, if so I'll start to do that work, it's just been, ain't broke, don't fix it territory!!
Peter (and group),
* None of my code EVER plays favorites with a TGID based on some designator assigned by one of the “networks”. That would go completely against what I stand for with these projects.
* Bridge.py is a retired application. It hasn’t been developed for some time and is not supported.
The goal of the contention handler routines was to keep something like this from happening. I suspect one of two scenarios – the contention handler is outright failing and sending the wrong traffic, or it’s failing not quite outright and sending BOTH streams to the repeater, which is picking the “other” stream.
I’d really like to figure out which of those things is happening. In IPSC, Motorola has some kind of convoluted (to me) method of determining who gets access to the channel. I’m sure it makes sense to them, but when you’re reverse engineering…. I really am not entirely sure how they make the choice, but it appears significantly more complicated than “who got here first”.
Can anyone duplicate this behavior with confbridge.py? If so, then I’ll dig into it for sure. If it’s just bridge.py…. then I think the best answer I have is to move to confbridge, then we’ll deal with it if it comes back. I know that’s not the answer Peter wants to hear… but it’s the one I have.
0x49 DE N0MJS
As you know I've got a fairly stable DMRLink bridge, this hosts 8 repeaters. I was asked by one keeper to link the local S2TG9 from repeater A, to repeater B S1TG9, I added both way rules to the bridge.py files, and it seemed to be OK, when user on A keys, output is send to the repeater B no problem.
Then I got reports that while listening on repeater B (connected to bridge Master B), to the stream from repeater A (bridge Master A), if another stream arrived into repeater B, same slot, different TG, say a National or International group from Master C in the same bridge, repeater B would drop the TG9 stream and play out the new Master C stream.
I thought that as the repeater B (Master B) was already outputting network traffic, it would ignore further traffic until the first stream finished, and a hang time had expired.
Wonder if because they are streaming from different Masters in the same bridge, that that scenario hasn't been considered, and so hold off is not invoked?
Is there a priority that can/has been set within the streams, which is allow the national groups to take precedence over the local traffic?