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

[Russell Bryant]

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

Ship it!



/branches/1.4/main/rtp.c
<https://reviewboard.asterisk.org/r/957/#comment5994>

    Check option_debug here, and in newer versions, use ast_debug()


- Russell


On 2010-09-30 16:22:23, Jeff Peeler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/957/
> -----------------------------------------------------------
> 
> (Updated 2010-09-30 16:22:23)
> 
> 
> 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
> 
>