diff options
| author | jpeeler <jpeeler@f38db490-d61c-443f-a65b-d21fe96a405b> | 2010-10-02 02:43:45 +0000 |
|---|---|---|
| committer | jpeeler <jpeeler@f38db490-d61c-443f-a65b-d21fe96a405b> | 2010-10-02 02:43:45 +0000 |
| commit | 0cb3dec91ee785b8c07150d78ac296c1debb9a57 (patch) | |
| tree | d11e0d1f7cdeb2456a50e9f47d0b592d113ccbd4 /res/res_smdi.exports.in | |
| parent | dfb1c45c3cbd058d3fcb2fe7d982ccae6b6b562c (diff) | |
Merged revisions 289798 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r289798 | jpeeler | 2010-10-01 18:01:31 -0500 (Fri, 01 Oct 2010) | 22 lines
Merged revisions 289797 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r289797 | jpeeler | 2010-10-01 17:58:38 -0500 (Fri, 01 Oct 2010) | 15 lines
Change RFC2833 DTMF event duration on end to report actual elapsed time.
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.
Review: https://reviewboard.asterisk.org/r/957/
ABE-2476
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.8@289840 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'res/res_smdi.exports.in')
0 files changed, 0 insertions, 0 deletions