Calls with same `usage` on different downlinks of the same cell collide

[adryd325]

I'm not sure the specifics of the system I'm monitoring. On occasion, on a single cell (same LA on all downlinks) will have 2 calls with the same usage. A result of this is both GSSIs showing under the same call slot, and audio sputters between both calls becoming unintelligible

I could mitigate this by processing each downlink on a separate telive instance but then I lose SSI information on the non-control-channel downlinks

Is there some other way to possibly mitigate this issue. I'm thinking doing something like usage += (rxid*64) might mitigate the issue but i'm not sure how other parts of telive would behave

[adryd325]

After making some (Very Hacky Do Not Use Them) changes to ensure each downlink's usages aren't shared, there still appears to be some kind of issue where multiple calls share a single usage identifier on a single downlink. I'm unsure if this is my bad code or if this is weird behavior with the system I'm monitoring.

This hacky fix has fixed the issue most of the time.

[sq5bpf]

Hi, it's one of those "this should never happen" things :)
When it happens, try to listen to this downlink only (kill all other receivers) with an unmodified telive and see if you still get this.
The only reason i can think of is that you have multiple osmo-tetra instances running as the same rxid, but i guess you would have found that out.

Offseting usage by rxid*64 is a clever hack, you would have to see it it doesn't overflow anything (i don't think it would).

[adryd325]

i've only ever seen it happen with duplex calls, perhaps that happens when both sides of the duplex call happen to be on the same cell. i think i've seen it happen to group call and duplex call a few times

right now im working on something that decodes using both the channel allocation and usage and that seems to be working better

[adryd325]

Different program I'm working on, duplicate usage identifiers, you can see 2 timeslots in use, both same downlink, both same usage, thus I'm not sure usage identifiers alone are enough to distinguish calls

[romanremus]

Hello ADRYD325 , could you not add to your tetra codes the encryptions of https://github.com/osmocom/osmo-tetra, are they the ones discovered by https://github.com/MidnightBlueLabs/TETRA_crypto? Thanks

[sq5bpf]

Hello ADRYD325 , could you not add to your tetra codes the encryptions of https://github.com/osmocom/osmo-tetra, are they the ones discovered by https://github.com/MidnightBlueLabs/TETRA_crypto? Thanks

i have already replied to you about this: the osmo-tetra code is unstable at the moment. i did port my patch do this codebase only to discover that it will segfault all the time (and same without my patch). Try to set any random key for osmo-tetra and receive a few minutes of traffic with encryption, and it will fail. Only once the original repository is fixed we will be able to port our patches to it (my patch or others). Please don't bug us before that gets fixed.

[sq5bpf]

Different program I'm working on, duplicate usage identifiers, you can see 2 timeslots in use, both same downlink, both same usage, thus I'm not sure usage identifiers alone are enough to distinguish calls

Interesting, i've never seen that.

So basically using usage*4+timeslot instead of the usage identifier should sort of fix your usecase, but i think you will only hear one side of the conversation.

A proper fix would be to find streams from both sides (if you do hear both sides, which is a special case probably) and mix them together. But that requires much more logic.