Bitstream is corrupted error

[thinkdmg]

I managed to apply the patch and test the EVS codec with an actual SBC. But sometimes, some calls are logging such errors:

2nd CMR; bitstream is corrupted
2nd frame; bitstream is corrupted

Sometimes they come 2-3 times (both of them), sometimes Asterisk writes them 100+ times for a call.

The related code for this errors in codec_evs.c is like this (starting line 464):

if (toc_byte & 0x80) { /* Header Type identification bit */
		ast_log(LOG_ERROR, "2nd CMR; bitstream is corrupted\n");
	}

	if (toc_byte & 0x40) { /* Followed bit */
		ast_log(LOG_ERROR, "2nd frame; bitstream is corrupted\n"); /* ToDo */
	}

I'm suspecting this happens because of there is no PLC (Packet-Loss Concealment) implemented?
The force_limitations.patch is forcing only Header Full format. If some RTP packages do not come with headers, can that be a reason for the errors I get in logs? What if I change hf-only =-1 ?

Don't have many chances to test all the scenarios, so would be great to get an advice on how would be the best to proceed.

[traud]

The module only implements hf-only, and the module negotiates hf-only. Consequently, if you change that default, you do not solve this issue but just get even more errors. To proceed with this, you have to debug the bitstream whether the frame got just corrupted or indeed is not hf-only. If it is the latter, you have to determine, why hf-only negotiation failed. If that is a software bug in the remote party, then there is a reason to implement all hf modes in my module.

However, the issue is much more complicated, if that is not a corrupted payload and its TOC states that a frame is followed by another speech frame (in this very same payload), then you have to implement that. This is a feature which is not implemented by my AMR module either, because that is work and I considered that an unused edge case. However, a VoIP SIP client for Microsoft Windows ‘MicroSIP’ is using that. And perhaps your remote party as well. Therefore that comment, ToDo.

Long story short, you have to debug whether this is really a second frame scenario in RTP, or a hf negation failure in SDP, or just a corrupted frame on the transport. The easiest way to proceed with this: Which mode is affected EVS or AMR-WB? And is it always the same remote party (user agent) creating those frames?

[thinkdmg]

First what I should mention, is that only EVS codec shows these errors. No call with AMR-WB showed something like this from my extensive monitoring. I don't have ability to catch the RTP traffic, but let's see if SDP has anything to do with it. If it is RTP wise, then I will need to decide if to ignore it and just throw it into the "network errors" box or analyse further.

So I managed to focus on 2 calls that dropped like 50 of these errors. One had User Agent as iPhone on iOS 17.5.1, the other had Samsung SM-G525F-XCA.

Here's the SIP INVITE for one of them:

And here is Asterisk 200 OK answer:

So, I'm wondering whether the fact that the INVITE does not specify hf-only at all and after my Asterisk 200 OK it just does ACK -> does that mean that essentially the hf-only is not negotiated at all? Or just buggy on the remote side which sends it dynamically in different hf-only?

Or is it something related to another parameter sent by Asterisk? What do you think?

[traud]

Both, Apple iOS and Samsung, were tested. Of course, that says not much as there are always corner cases. Anyway, without RTP data, I do not know how to proceed here.

[thinkdmg]

While I'm trying to get the RTP data, here's what one of the original engineers for the SBC node told me when EVS codec was activated:
"It's useless sending always sending Header-Full, as it increases the overall packet size and the overhead. the other part is that DTX-recv is only valid for the upstream (other direction fromt he one used). Also ok, but useless."

An advice please, if you can:
If I set the hf-only to -1, does this mean it will not be negotiated anymore, and the Asterisk will just dynamically try to understand which mode is it?
As an alternative, can I just set it to a mode where it is disabled/not present?

Thanks a lot in advance.

[traud]

Answered with my previous answer: ‘[My transcoding] module only implements hf-only, and the [negotiation] module negotiates hf-only. Consequently, if you change that default, you do not solve this issue but just get even more errors.’

[traud]

Were you able to track this is down to the culprit via RTP?