[asterisk-dev] BugID 014021, Zap/DAHDI timers, internal timing and packetization

[Dan Austin]

Russell wrote:
>> I know the issue can be solved, but I am not sure it can be solved
>> in 1.4 or 1.6.0 since the fix will likely need changes to the
>> channel structure.


> It definitely sounds like you're on the right track to the fix for
> this.  Thank you for working on it!

> As far as changing ast_channel goes, we might be in luck.  I just
> deprecated a field in the ast_channel struct as a part of a bug fix.
> However, it's still there for the sake of maintaining ABI.  So, we
> actually have 80 bytes that we can use for other things if needed.  :-)

> You could change:

>    char unused_old_dtmfq[AST_MAX_EXTENSION];

> to something like:

>    union {
>       /*! This is a deprecated field of the ast_channel struct */
>       char unused_old_dtmfq[AST_MAX_EXTENSION];
>       /*! The size of the following struct must be less than or equal
>to AST_MAX_EXTENSION */
>       struct {
>          uint16_t timer_rate;
>       };
>    };

I wanted to follow up on this again.  I have not had time to
actually work on it in the past month, but I tried to think
through the options.

The solution is not trivial, otherwise I guess it would have
been solved by now.

I think we need to not call ast_rtp_raw_write from ast_rtp_write
if a smoother is present, but still feed the smoother.  We then
need a way to process the smoother.  The two options I see
are.

1.) A separate thread that sleeps, either for the packetization
value, or packet interval.  I think this is fairly ugly, and
we would need to track the thread and kill it when the RTP
session ends.

2.)  Use the ast_settimeout() function to setup a callback to
process the smoother buffer.  The main issue with this would
be that other functions can and do reset the rate of the
timing fd.  There are only a few users of ast_settimeout, and
maybe they can be taught to not use it, or a separate timing fd
just for the RTP stream (ugly?)

I'd appreciate any thoughts or opinions about either option.

Dan