Non-voice transmissions (currently control messages and chat messages, eventually to include general data) are handled at lower priority than voice. This works fine as long as each such message fits into a single frame.
However, when there's a multi-frame message, it's possible for a voice transmission to interrupt it. That is, we've sent some (but not all) of the frames of the message, and then PTT is asserted, and we start to transmit voice frames.
Let Mn represent message frame n within a single message packet, and Vn represent voice frame n. Let $ represent the number of frames in that message or voice transmission. What we transmit now looks like this:
M1 M2 M3 V1 V2 ... V$ M4 M5 ... M$
There are a couple of problems here.
First, M3 does not end in a 0x00 delimiter byte, since it's not the last part of a packet. M3 does not end at the end of a COBS chunk, either, except by coincidence. That means the COBS decoder will not interpret the first byte of V1 correctly as a COBS chunk length, so V1 is lost. The COBS decoder gets back on track at the start of V2, since V1 did end in a 0x00 delimiter byte.
Second, M4 probably doesn't start with a COBS chunk length byte. The COBS decoder will nonetheless assume that it does, and consume the corresponding number of bytes. It would only get back into sync again by accident, or at the end of the message where a 0x00 delimiter byte forces COBS to terminate the packet, ready or not. The UDP checksum on the message is almost certainly going to fail, so the whole text message will be discarded.
Disclaimer: I have not yet tried to reproduce this on the bench.
I believe that the best solution to this problem is my multi-stream COBS proposal, coming soon to a white paper near you. There are other options, such as using some bits from the Opulent Voice Frame Header to designate each frame as a particular type, and handling each type of frame with a separate COBS decoder.
Non-voice transmissions (currently control messages and chat messages, eventually to include general data) are handled at lower priority than voice. This works fine as long as each such message fits into a single frame.
However, when there's a multi-frame message, it's possible for a voice transmission to interrupt it. That is, we've sent some (but not all) of the frames of the message, and then PTT is asserted, and we start to transmit voice frames.
Let Mn represent message frame n within a single message packet, and Vn represent voice frame n. Let $ represent the number of frames in that message or voice transmission. What we transmit now looks like this:
M1 M2 M3 V1 V2 ... V$ M4 M5 ... M$
There are a couple of problems here.
First, M3 does not end in a 0x00 delimiter byte, since it's not the last part of a packet. M3 does not end at the end of a COBS chunk, either, except by coincidence. That means the COBS decoder will not interpret the first byte of V1 correctly as a COBS chunk length, so V1 is lost. The COBS decoder gets back on track at the start of V2, since V1 did end in a 0x00 delimiter byte.
Second, M4 probably doesn't start with a COBS chunk length byte. The COBS decoder will nonetheless assume that it does, and consume the corresponding number of bytes. It would only get back into sync again by accident, or at the end of the message where a 0x00 delimiter byte forces COBS to terminate the packet, ready or not. The UDP checksum on the message is almost certainly going to fail, so the whole text message will be discarded.
Disclaimer: I have not yet tried to reproduce this on the bench.
I believe that the best solution to this problem is my multi-stream COBS proposal, coming soon to a white paper near you. There are other options, such as using some bits from the Opulent Voice Frame Header to designate each frame as a particular type, and handling each type of frame with a separate COBS decoder.