Skip to content
Snippets Groups Projects
  1. Feb 13, 2009
  2. Feb 12, 2009
  3. Feb 11, 2009
    • Mark Michelson's avatar
      0d5da5f4
    • Mark Michelson's avatar
      Fix odd "thank you" sound playing behavior in app_queue.c · 34161542
      Mark Michelson authored
      If someone has configured the queue to play an position or holdtime
      announcement, then it is odd and potentially unexpected to hear a 
      "Thank you for your patience" sound when no position or holdtime
      was actually announced.
      
      This fixes the announcement so that the "thanks" sound is only played
      in the case that a position or holdtime was actually announced.
      
      There is a way that the "thank you" sound can be played without a
      position or holdtime, and that is to set announce-frequency to a value
      but keep announce-position and announce-holdtime both turned off.
      
      (closes issue #14227)
      Reported by: caspy
      Patches:
            14227_v3.patch uploaded by putnopvut (license 60)
      Tested by: caspy
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174948 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      34161542
    • Mark Michelson's avatar
      Fix 'd' option for app_dial and add new option to Answer application · 47ebea6a
      Mark Michelson authored
      The 'd' option would not work for channel types which use RTP to transport
      DTMF digits. The only way to allow for this to work was to answer the channel
      if we saw that this option was enabled.
      
      I realized that this may cause issues with CDRs, specifically with giving false
      dispositions and answer times. I therefore modified ast_answer to take another
      parameter which would tell if the CDR should be marked answered.
      
      I also extended this to the Answer application so that the channel may be answered
      but not CDRified if desired.
      
      I also modified app_dictate and app_waitforsilence to only answer the channel if it
      is not already up, to help not allow for faulty CDR answer times.
      
      All of these changes are going into Asterisk trunk. For 1.6.0 and 1.6.1, however, all
      the changes except for the change to the Answer application will go in since we do
      not introduce new features into stable branches
      
      (closes issue #14164)
      Reported by: DennisD
      Patches:
            14164.patch uploaded by putnopvut (license 60)
      Tested by: putnopvut
      
      Review: http://reviewboard.digium.com/r/145
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      47ebea6a
    • Tilghman Lesher's avatar
      Blocked revisions 174885 via svnmerge · ff0b9087
      Tilghman Lesher authored
      ........
        r174885 | tilghman | 2009-02-11 14:54:18 -0600 (Wed, 11 Feb 2009) | 13 lines
        
        Restore a behavior that was recently changed, when we fixed issue #13962 and
        issue #13363 (related to issue #6176).  When a hangup occurs during a Macro
        execution in earlier 1.4, the h extension would execute within the Macro
        context, whereas it was always supposed to execute only within the main context
        (where Macro was called).  So this fix checks for an "h" extension in the
        deepest macro context where a hangup occurred; if it exists, that "h" extension
        executes, otherwise the main context "h" is executed.
        (closes issue #14122)
         Reported by: wetwired
         Patches: 
               20090210__bug14122.diff.txt uploaded by Corydon76 (license 14)
         Tested by: andrew
      ........
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174886 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      ff0b9087
    • Joshua Colp's avatar
      Tell the device state core a change happened when a channel is freed but not a specific state. · 84355353
      Joshua Colp authored
      We need to do this because while we know that the freeing of the channel may cause something to become
      not in use we do not know this for sure. There may be another channel that is still up which would cause
      it to be in use.
      (closes issue #13238)
      Reported by: kowalma
      Patches:
            20090121__bug13238.diff.txt uploaded by Corydon76 (license 14)
      Tested by: alecdavis
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174844 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      84355353
  4. Feb 10, 2009
  5. Feb 09, 2009
Loading