[asterisk-dev] slin Transcode + JB = Console warning spam

[Matt Fredrickson]

On Tue, Jan 22, 2019 at 5:05 AM Steve Davies <davies147 at gmail.com> wrote:
>
> Hi,
>
> This is possibly an OLD bug that has existed since at least 1.8.x and persists into 16.x.
>
> In asterisk 16, main/translate.c ~line 646 is the following code:
>
>   if (f->samples != current->samples && ast_test_flag(current, AST_FRFLAG_HAS_TIMING_INFO)) {
>     ast_debug(4, "Sample size different %d vs %d\n", f->samples, current->samples);
>     ast_clear_flag(current, AST_FRFLAG_HAS_TIMING_INFO);
>   }
>
> Which if I understand it correctly states that after a transcode, if the number of samples has changed, then the timing info is not valid. (In fact the timing values appear to be corrected about 4 lines earlier) The case where this really falls down is where SLIN is being used to move from wideband to narrowband, eg slin48000 to slin16000, where the number of samples changes by a factor of 4x, but the timing values are perfectly correct.
>
> This is not normally a problem until one of the above modified frames is passed into a jitter-buffer.
>
> In asterisk 16, main/abstract_jb.c ~line 287 is the following:
>
>   if (!ast_test_flag(f, AST_FRFLAG_HAS_TIMING_INFO) || f->len < 2 || f->ts < 0) {
>     ast_log(LOG_WARNING, "%s received frame with invalid timing info: "
>       "has_timing_info=%u, len=%ld, ts=%ld, src=%s\n",
>       ast_channel_name(chan), ast_test_flag(f, AST_FRFLAG_HAS_TIMING_INFO), f->len, f->ts, f->src);
>     return -1;
>   }
>
> Resulting in a once-per frame WARNING of "...received frame with invalid timing info..." as reported back in 2014 in
> https://issues.asterisk.org/jira/browse/ASTERISK-24424
>
> The issue is most easily replicated in older versions where a MASQ is used more regularly by transferring a wideband SIP channel with JB enabled to a Local...;2 channel
>
> Summary:
> I think there might be 3 bugs here...
> 1) in transcode.c it is falsely assumed that a change in the number of samples invalidates timing info
> 2) in abstract_jb.c having no timing info causes a loud warning to be spammed.
> 3) a MASQ into a Local/...;2 channel can enable a JB where none should ever exist.
>
> If any of these hold water, I can raise issues on Jira, but though I'd run in through the mailing list first?

Every time I have to look at this code I have to go down the rabbit
hole and remember how it works.  It's quite possible that there are
multiple bugs at work here, as I don't think anybody's completely
audited the interaction of the jitter buffer and transcoder path in a
while.  I'm going to try to put some more brain time into this
tomorrow and might have a better follow up response.

Kevin Harwell or Alexander Traud might have a few good thoughts on
this as well since I think they've put more recent time into this
code.

-- 
Matthew Fredrickson
Digium - A Sangoma Company | Asterisk Project Lead
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA