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

[Steve Davies]

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?

Thanks,
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20190122/5b975820/attachment.html>