Merged revisions 289840 via svnmerge from
authorJeff Peeler <jpeeler@digium.com>
Sat, 2 Oct 2010 02:46:43 +0000 (02:46 +0000)
committerJeff Peeler <jpeeler@digium.com>
Sat, 2 Oct 2010 02:46:43 +0000 (02:46 +0000)
commitc44527e18573dd7dec57a4d4142700e7ecd6d729
tree31a600b3ba6ead6aabc8d1b68984788f32b52097
parent1517166700ac4c7a27097578a41a0d944d405098
Merged revisions 289840 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
  r289840 | jpeeler | 2010-10-01 21:43:45 -0500 (Fri, 01 Oct 2010) | 29 lines

  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: https://origsvn.digium.com/svn/asterisk/trunk@289841 65c4cc65-6c06-0410-ace0-fbb531ad65f3
channels/chan_sip.c
include/asterisk/rtp_engine.h
main/rtp_engine.c
res/res_rtp_asterisk.c