* add P25 telephone interconnect TSBKs (TELE_INT_VCH_GRANT, TELE_INT_PSTN_REQ, TELE_INT_ANS) and decode them in TSBKFactory;
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* add telephoneInterconnect control channel option; forward P25 telephone interconnect PSTN requests, answer responses and interconnect cancels to the network, and only transmit network answer requests for units registered to the site;
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* add contributor copyright for P25 telephone interconnect control channel changes;
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* add telephone interconnect gateway peer flag (peer list, REST API, peered); route P25 telephone interconnect voice and signalling only between gateway peers and the peer the unit is registered to, and validate interconnect calls against the RID ACL instead of talkgroup rules;
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* route gateway telephone interconnect traffic to the voice channel peers of the site the unit is registered to;
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* add P25 telephone interconnect channel grants; grant interconnect calls on network grant demand, hold the grant for the whole call (message trunking) with grant demand keepalives, release it on the terminating TDULC or a unit cancel, and deny on network grant denial;
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* handle P25 telephone interconnect calls on voice channels; decode the TEL_INT_VCH_USER address as the call dstId and encode dstId as the address, correct the TEL_INT_VCH_USER LC and TDULC encoders, hold telephone interconnect permits through TG hang, and attribute talkgroup-less HDUs to the permitted unit;
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* add the explicit channel form of the P25 telephone interconnect channel grant (MBT_OSP_TELE_INT_VCH_GRANT, AMBT); grant telephone interconnect calls on explicit channel sites with the AMBT grant instead of refusing them;
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The Enc Sync content warning only printed algId/kId, but its trigger
condition also fires on an MI-only change (memcmp against LDULC),
making the log show no apparent difference when only the MI changed.
* fix(p25): guard mid-call LDU1 identity against marginal FEC miscorrection
RS634717::decode241213/decode24169 already computed a corrected-symbol
count and threw it away, so a decode() call taking the RS(24,12,13)
LDU1 LC field to the edge of its correction guarantee (miscorrection
of a still-CRC-valid-looking codeword) was as trusted as a clean
decode. Voice::process() also never re-checked a mid-call LDU1's
srcId/dstId against anything once a call was established.
Thread the RS error count up through LC::decodeLDU1/decodeLDU2
(LC::FECErrs), and in Voice::process() treat a mid-call LDU1 as
suspect if either:
- it required RS correction and disagrees with the call's last
known-good LDU1, or
- its dstId disagrees with the dstId from this call's HDU, which is
far more strongly protected (Golay(18,6,8)+RS(36,20,17)) and
fixed for the life of the call, regardless of the LDU1 decode's
own error count.
On either, keep the established identity for that frame instead of
adopting the new one; audio is untouched. Neither check runs at call
grant/establishment, so this doesn't affect ACL or ad hoc/unregistered
srcIds originating a call -- it only stops an already-established
call's identity from being silently redirected mid-transmission.
* fix(modem): use RS-corrected LC content instead of pre-correction DFSI bytes
In ModemV24's DFSI parsing (both convertToAirV24 and convertToAirTIA,
LDU1 and LDU2), srcId/dstId/lco/mfId and algId/kId/MI were latched
directly from the raw wire bytes as they arrived, before the RS
decode of that same data (m_rs.decode241213/decode24169 on
m_rxCall->LDULC) ran. When the decoder found and corrected symbol
errors, the correction was computed and discarded -- the pre-
correction, still-wrong raw values were what actually got used to
build the outgoing frame. Only a hard decode failure (ret == false)
triggered any recovery.
Thread the RS decoder's corrected-error count out via the errs
out-param added to RS634717::decode241213/decode24169, and on a
successful decode with errs > 0, re-derive the affected fields from
the now-corrected LDULC buffer: LDU1 via the existing LC::decodeLC(),
LDU2 via inline extraction matching LC::decodeLDU2()'s own algId/kId/MI
handling. Logs only when the correction actually changed one of these
fields.
Scoped entirely to ModemV24.cpp (the DFSI/V.24 route); LC.cpp,
RS634717.*, Voice.cpp, and Modem.cpp (the direct RF "air" route) are
unchanged.
* Update FEC Waring Log Message
Include LC content for better indication of what changed.
* Revert Control.cpp and test files to match upstream r05a06_dev exactly per review
Bryan Biedenkapp
majmongoose
Tim WD6AWP