Add call_num key/value to the Call JSON object.

[gofaster]

As the MQTT call_start and call_end messages contain the call_num key/value, this helps consumers match call events with audio.

Example new audio MQTT message (without encoded audio for brevity):

{
    "type": "audio",
    "call": {
        "audio_wav_base64": "",
        "audio_m4a_base64": "",
        "metadata": {
            "call_num": 145,
            "freq": 460162500,
            "freq_error": -11,
            "signal": -12,
            "noise": -56,
            "source_num": 0,
            "recorder_num": 0,
            "tdma_slot": 0,
            "phase2_tdma": 0,
            "start_time": 1775355557,
            "stop_time": 1775355566,
            "start_time_ms": 1775355557368,
            "stop_time_ms": 1775355566939,
            "emergency": 0,
            "priority": 0,
            "mode": 0,
            "duplex": 0,
            "encrypted": 0,
            "call_length": 10,
            "call_length_ms": 9571,
            "talkgroup": 27,
            "talkgroup_tag": "Town FD Dis",
            "talkgroup_description": "",
            "talkgroup_group_tag": "Fire Dispatch",
            "talkgroup_group": "Town Fire",
            "color_code": -1,
            "audio_type": "analog",
            "short_name": "AnyName",
            "freqList": [
                {
                    "freq": 460162500,
                    "time": 1775355557,
                    "pos": 0.0,
                    "len": 9.571,
                    "error_count": 0,
                    "spike_count": 0
                }
            ],
            "srcList": [
                {
                    "src": 551290,
                    "time": 1775355557,
                    "pos": 0.0,
                    "emergency": 0,
                    "signal_system": "",
                    "tag": "",
                    "tag_ota": ""
                }
            ]
        }
    },
    "timestamp": 1775355574,
    "instance_id": "InstanceA"
}

[taclane]

Seems reasonable.

Considering that call_num is a bare integer that resets each time t-r is restarted, would there be any value in a more unique ID for each call?

Each call could have:

"call_id": "cd953e47-dfbc-4d72-a8a3-7f09099103d5"

or a less UUID-ish combination of unix time, talkgroup, and frequency like we do with the filename.

[gofaster]

Being able to unequivocally correlate a call recording file, MQTT call_start, call_end and audio messages would be great. Would need some more thought and discussion to implement; especially regarding issues for downstream filename parsers.

This PR would at least make it easier to match a call recording file (which by default contains the call_num in the filename) with the above MQTT event msgs. It is a little fuzzy currently since the start/stop times in the messages and the filename doesn’t exactly match up.

[Dygear]

If you're going a pseudo UUID route, I'd highly recommend the time series version of it, with a sha256 to fill out the rest. UUIDv7 is time series based, and is a IETF 4122 proposal. You'd set rand_b to the sha256 of the wav form. That should give you enough uniqueness. Granted you'd be throwing away most of the sha256 bytes.

5.2.UUID Version 7

UUID version 7 features a time-ordered value field derived from the widely implemented and well known Unix Epoch timestamp source, the number of milliseconds seconds since midnight 1 Jan 1970 UTC, leap seconds excluded. As well as improved entropy characteristics over versions 1 or 6.

Implementations SHOULD utilize UUID version 7 over UUID version 1 and 6 if possible.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           unix_ts_ms                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          unix_ts_ms           |  ver  |       rand_a          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|                        rand_b                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            rand_b                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: UUIDv7 Field and Bit Layout

unix_ts_ms:

48 bit big-endian unsigned number of Unix epoch timestamp as per Section 6.1.

ver:

4 bit UUIDv7 version set as per Section 4

rand_a:

12 bits pseudo-random data to provide uniqueness as per Section 6.2 and Section 6.6.

var:

The 2 bit variant defined by Section 4.

rand_b:

The final 62 bits of pseudo-random data to provide uniqueness as per Section 6.2 and Section 6.6.