<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi,<div><br></div><div>This is possibly an OLD bug that has existed since at least 1.8.x and persists into 16.x.</div><div><br></div><div>In asterisk 16, main/translate.c ~line 646 is the following code:</div><div><br></div><div><div>  if (f->samples != current->samples && ast_test_flag(current, AST_FRFLAG_HAS_TIMING_INFO)) {</div><div>    ast_debug(4, "Sample size different %d vs %d\n", f->samples, current->samples);</div><div>    ast_clear_flag(current, AST_FRFLAG_HAS_TIMING_INFO);</div><div>  }</div></div><div><br></div><div>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.</div><div><br></div><div>This is not normally a problem until one of the above modified frames is passed into a jitter-buffer.</div><div><br></div><div>In asterisk 16, main/abstract_jb.c ~line 287 is the following:</div><div><br></div><div><div>  if (!ast_test_flag(f, AST_FRFLAG_HAS_TIMING_INFO) || f->len < 2 || f->ts < 0) {</div><div>    ast_log(LOG_WARNING, "%s received frame with invalid timing info: "</div><div>      "has_timing_info=%u, len=%ld, ts=%ld, src=%s\n",</div><div>      ast_channel_name(chan), ast_test_flag(f, AST_FRFLAG_HAS_TIMING_INFO), f->len, f->ts, f->src);</div><div>    return -1;</div><div>  }</div></div><div><br></div><div>Resulting in a once-per frame WARNING of "...received frame with invalid timing info..." as reported back in 2014 in</div><div><a href="https://issues.asterisk.org/jira/browse/ASTERISK-24424">https://issues.asterisk.org/jira/browse/ASTERISK-24424</a><br></div><div><br></div><div>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</div><div><br></div><div>Summary:</div><div>I think there might be 3 bugs here...</div><div>1) in transcode.c it is falsely assumed that a change in the number of samples invalidates timing info</div><div>2) in abstract_jb.c having no timing info causes a loud warning to be spammed.</div><div>3) a MASQ into a Local/...;2 channel can enable a JB where none should ever exist.</div><div><br></div><div>If any of these hold water, I can raise issues on Jira, but though I'd run in through the mailing list first?</div><div><br></div><div>Thanks,</div><div>Steve</div></div></div></div></div></div></div>