[asterisk-dev] [Code Review] Change RFC2833 DTMF event duration on end to report actual elapsed time

[Jeff Peeler]

> On 2010-09-30 12:09:24, David Vossel wrote:
> > This patch looks sane to me. One question though, why are the Continuation frames triggered by incoming media?
> 
> Russell Bryant wrote:
>     I suspect for historical reasons, when there really wasn't a better option.  If we wanted to improve it such that continuation frames will work even if media isn't coming in, we could set a timer callback on the channel and fall back to using incoming media only if a timer is not available.

Well I initially considered adding a new frame type to represent the middle of the DTMF, but that would require adding protocol specific code to the core. This is the only way I can think of to truly have the duration be resent exactly as received.


- Jeff


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/957/#review2797
-----------------------------------------------------------


On 2010-09-30 11:00:22, Jeff Peeler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/957/
> -----------------------------------------------------------
> 
> (Updated 2010-09-30 11:00:22)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> The scenario here is with a non P2P early media session. The reported time length of DTMF presses are coming up short when sending to the remote side. Currently the event duration is a running total that is incremented when sending continuation packets. These continuation packets are only triggered upon incoming media from the remote side, which means that the running total probably is not going to end up matching the actual length of time Asterisk received DTMF. This patch changes the end event duration to be lengthened if it is detected that the end event is going to come up short.
> 
> 
> Diffs
> -----
> 
>   /branches/1.4/channels/chan_sip.c 289423 
>   /branches/1.4/include/asterisk/rtp.h 289423 
>   /branches/1.4/main/rtp.c 289423 
> 
> Diff: https://reviewboard.asterisk.org/r/957/diff
> 
> 
> Testing
> -------
> 
> Have tested sending various lengths of DTMF and verified both that Asterisk received the length of DTMF as expected, but now also sends the final duration correctly regardless of whether or not the remote side is sending media.
> 
> 
> Thanks,
> 
> Jeff
> 
>