On Tue, Jan 22, 2019 at 5:05 AM Steve Davies <davies...@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
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
