Bandwidth negotiation does not accept NB

[hardrock13]

From what I managed to understand from the code, the patch allows Asterisk to work with all 4 types of bandwidth of the EVS codec: NB, WB, SWB and FB.

I had a chance to test the patch in practice and sometimes I stumbled on the following error:
no bandwidth in common

After checking the code, I noticed that there's a restriction regarding the negotiated bandwidth. In the res_format_attr_evs.c at the 803 line there is this:
if (0 == (attr_res->bw_recv & 0x1e) || 0 == (attr_res->bw_send & 0x1e)) { ast_log(LOG_WARNING, "no bandwidth in common\n"); return NULL;

From my limited knowledge, I take it this limits bandwidth negotiation to only the WB and up. That is, if common negotiated bandwidth is NB, then the module will consider that no common bandwidth was found, and therefore end the call.

Any specific reason to limit the common denominator to WB and up? Or was this pure own preference?

Interested in trying a change to this in practice:
if (attr_res->bw_recv == 0 || attr_res->bw_send == 0) {

[traud]

The bandwidth is encoded as plain text in the SDP, given as range values or single value. My module translates all known text strings (7) into a bit-set, like the set theory, it allows the module to check which bandwidth is on/off or one/zero. The lowest bit 0 is just an indicator whether it was included in SDP or a default is in use. Consequently, everything is shifted one the left, narrowband is bit 1.

Therefore, narrowband should be covered, as you can see in evs_parse_sdp_fmtp_bw. However, that does not say anything about a software bug being around. Are you able to enhance the error message to print which one failed bw_recv or bw_send and which value it has? Nevertheless, I guess the issue is deeper, in evs_parse_sdp_fmtp_bw. Are you able to debug print the SDP, at least the a=fmtp?

[hardrock13]

So I managed to grab 2-3 calls. All of them were dropping this error, specifically it was coming from res_format_attr_evs.c.
But - the parties did not even negotiate EVS codec and what is more, the call itself went in AMR-WB codec.

Here is the screen for the SDP from the SIP INVITE:

And here is the screen of Asterisk 200 OK answer:

Now I'm actually confused why the error popped at all, considering the call was not in EVS codec. Did the a=fmtp of AMR-WB options triggered the EVS module?

[traud]

That is indeed curious. Where is that Asterisk from? 16.18.0 sounds like a version from a Linux distribution, at least terrible old from May 2021. It should work but I am not sure what is going wrong here. Do you know how to debug a running Asterisk? Then you can create a breakpoint and jump through its code.

[hardrock13]

Yeah, it's an old Asterisk, have no control over changing that. Interestingly enough, I added extra logs and bw_recv and bw_send just come as 0x0 in logs. I added more logging above the
if (0 == (attr_res->bw_recv & 0x1e) || 0 == (attr_res->bw_send & 0x1e)) { ast_log(LOG_WARNING, "No common bandwidth: recv=0x%X, send=0x%X\n", attr_res->bw_recv, attr_res->bw_send); return NULL;

operation so that I get what it bw_send and bw_recv before they get put against 0x1e and it's still a 0x0. So will add more logging above to the evs_parse_sdp_fmtp_bw use for determining bw_send and bw_recv to try to understand how they actually look in the SDP.