Duplicate calls in feed

[lynchy135]

I am not sure who to talk to about this, but the system that I provide a node for is getting duplicate calls that seem to be roughly three seconds off in timestamp. I validated my system that it is using NTP along with being the correct time, so I suspect that the other node is not using NTP. I am not really sure if someone can get into contact with the other node provide to fix the issue.

Obviously you'll need more info from me. Let not sure if this is more of a DM situation or a forums post.

 

[HarryWilly]

I am having an adjacent issue where my calls get rejected because they are in fact duplicate calls, but that returns an error on the API. It would be preferred if it could be a status 0 so that I don't have a bunch of recording piling up. I have all the recording performed in memory in a TempFS to prevent disk IO on an SD card, but when the server rejects stating "duplicate call" it causes trunk recorder to hold it. I don't care that it gets rejected, but I would prefer the API reports that it accepts it on the back end handles duplicates.

 

[lynchy135]

You may want to look at doing that via an upload script. Its a pretty good idea though.

That being said, that not my issue. My issue is whoever is the remote server's time is off, so Broadcastify sees them as two separate calls even though the audio is the same.

 

[Reconrider]

That's odd that it rejects them. Bcalls is recommended to have dupes in case someone gets digital distortion.

 

[lynchy135]

I was under the impression that its not supposed to have duplicate calls. I am hoping an admin will clarify that.

 

[Reconrider]

I was under the impression that its not supposed to have duplicate calls. I am hoping an admin will clarify that.

I forget where I seen it at. But the thread was something like this one. @blantonl said that unlike streaming, bcalls is suggested to have double feed in case something happens to the other guy.

 

[kslager]

I am not sure who to talk to about this, but...

I experience this as well from time to time. I run the Broadcastify pi image, so I would assume the timing is good on those? I've also noticed some calls ingesters are very choppy. I don't see any way to alert ingesters of potential issues as of right now.

 

[kslager]

This node is not too far from me. The platform ingesting is at least 35+ seconds ahead of true time as shown. When units are roaming, or units are using a statewide propagated talk group, multiple ingest platforms will pickup the transmission, causing duplicate calls in the system. Maybe in the future, the system can bounce the call being ingested against the server time, and send out of friendly email if it suspects the timing might be off - it should be at least equal to or after the server time. I don't see anyway to notify the platform operator of this, or any other issues that may arise, such as a garbled/choppy transmissions.

 

[blantonl]

I'm aware of some of these timing issues and duplicate calls. We're working on some approaches and fixes to the problems. Stay tuned.

 

[lynchy135]

As far as I'm aware, (and this is why I was hoping for some clarification from the Admins), Calls is built to discard duplicate calls. I believe it does so based on the time, frequency, talkgroup, and source ID of the call.

My trunk-recorder logs have Broadcastify Metadata Upload Error: SKIPPED---ALREADY-RECEIVED-THIS-CALL a far bit. The issue is when someone's system is not correctly synced to the time. It's on the providers to make sure that their system is correctly configured.

Edit: I typed this before I saw @blantonl posted his.

 

[lynchy135]

@blantonl One thing I was looking through is the Trunk-Recorder wiki page. There is no information about what Calls wants for `callTimeout`. Having a unified timeout amongst all nodes may help duplicates.

That being said, your backend may be looking at unit numbers already to determine if a call from one node that is 10 seconds long matches the info from two calls that were 5 seconds long in the same time range.