Trying to avoid to reinvent the wheel, so I found some KISS sources:

• https://github.com/EnhancedRadioDevices/HamShield_KISS : C code, depends on AFSK
• https://github.com/markqvist/OpenModem : C code, depends on AFSK and on AX.25
• https://github.com/mobilinkd/tnc1/blob/master/mobilinkd-tnc1/ : C code, depends on BeRTOS and AFSK, adds non-standard escape codes for some reason.  Using the ExitKiss-command instead might have been the preferable option.
  
• https://github.com/mobilinkd/NucleoTNC/tree/master/TNC and https://github.com/mobilinkd/tnc3-firmware/blob/master/TNC : real C++ code

A lot of time and effort has been put in these firmwares, but...  For implementing a KISS interface, shouldn't the code be KISS as well?  These source codes are not simple (relying on AFSK and/or AX.25) makes the class complicated and hard to port to other platforms or tool chains.  The firmwares are not for the stupid either.  The Mobilinkd C++ code may be beautifully written, but it's hard to read for novice C++ programmers.

So I'll need to write my own code based on the PacketSerial and HamShield_KISS libraries while adhering as much as possible to the KISS-"standard".

Android

As mentioned elsewhere, instead of implementing all functionality in a single device, I'll offload functionality to an Android device.  These apps are already there, so why not use them?  Why would I decode Codec2 samples in the ESP32 when there's already an Android app that can do that for me?

The only thing needed is a KISS-TNC interface and a Bluetooth serial port to talk to these Android apps.  This is not so hard to do.

Codec2 Talkie

I have tested my KISS-TNC code with the sh123 android app to send and receive Codec2 speech samples.  Codec2 samples sent by the ESP32 were correctly decoded and output on the Android app.  I've also off-line decoded Codec2 samples that the ESP32 received from the Android app.

Aprsdroid

Sending voice with Codec2 Talkie is one thing, but it would be nice to have a messenger application with the added bonus of sharing location info.  That is what Aprsdroid can do for us.

I'll mention Ripple Messenger (and LoRa Qwerty Messenger) here as an alternative, but that application looks like a single person project.

APRS uses only a subset of the AX.25-framework.  And Aprsdroid in its turn only uses a subset of the APRS-protocol.  So we can suffice by only implementing a very limited set of the AX.25-framework.
Moreover, the data we receive over the KISS-interface doesn't carry flags, has no checksum and isn't bit-stuffed either.  This also saves us a considerable amount of work.

Unfortunately, the APRS-protocol is a real mess.  It seems like the standard has been written after the fact, trying to match the standard to different applications already seeing field use.

Location reports

AX.25-frame, received as Data Frame by our KISS-TNC :

0x82 0xa0 0x88 0xa4 0x62 0x6c 0xe0 0x9c 0x60 0x86 0x82 0x98 0x98 0x61 0x03 0xf0 0x3d 0x30 0x31 0x30 0x30 0x2e 0x30 0x30 0x4e 0x5c 0x30 0x30 0x32 0x30 0x30 0x2e 0x30 0x30 0x45 0x29 0x20 0x68 0x74 0x74 0x70 0x73 0x3a 0x2f 0x2f 0x61 0x70 0x72 0x73 0x64 0x72 0x6f 0x69 0x64 0x2e 0x6f 0x72 0x67 0x2f 

Decoded by AX.25 Frame Generator :

Source & SSID: N0CALL-0
Destination & SSID: APDR16-0
PID : 0xF0 (no layer3 protocol)
CONTROL : 0x03 (UI Frame)
Payload: =0100.00N\00200.00E) https://aprsdroid.org/

We can also send our own location reports to Aprsdroid:

Text message

More info can be found in the APRS-specification, chapter 14.  Aprsdroid expects messages to be acknowledged, hence the '{' followed by a number at the end of the message.

AX.25-frame, received as Data Frame by our KISS-TNC :

0x82 0xa0 0x88 0xa4 0x62 0x6c 0xe0 0x9c 0x60 0x86 0x82 0x98 0x98 0x61 0x03 0xf0 0x3a 0x4e 0x31 0x43 0x41 0x4c 0x4c 0x20 0x20 0x20 0x3a 0x48 0x65 0x6c 0x6c 0x6f 0x20 0x77 0x6f 0x72 0x6c 0x64 0x7b 0x35 

Decoded by AX.25 Frame Generator :

Source & SSID: N0CALL-0
Destination & SSID: APDR16-0
PID : 0xF0 (no layer3 protocol)
CONTROL : 0x03 (UI Frame)
Payload: :N1CALL   :Hello world{5

AX.25 References

• AX.25 Frame Generator : the KISS data frames received by our KISS-TNC can be pasted into the AX.25-Text frame on that web page to decode them.
  • AX.25 frame = Address + Control + Info fields from HDLC standard, before bit-stuffing.
  • HDLC frame = AX.25 frame with flags, FCS (=checksum) and the bit-stuffing.
• RadioLib : only TX, no RX of AX.25
• LibAPRS : APRS-packet library : decoding and encoding of AX.25, APRS encoding only
• APRS-Specification 1.0.1