Files
asterisk/main
Richard Mudgett b183d64131 Merged revisions 313579 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
  r313579 | rmudgett | 2011-04-13 11:29:49 -0500 (Wed, 13 Apr 2011) | 48 lines
  
  Merged revisions 313545 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.4
  
  ........
    r313545 | rmudgett | 2011-04-13 11:21:24 -0500 (Wed, 13 Apr 2011) | 41 lines
    
    Asterisk does not hangup a channel after endpoint hangs up.
    
    If the call that the dialplan started an AGI script for is hungup while
    the AGI script is in the middle of a command then the AGI script is not
    notified of the hangup.  There are many AGI Exec commands that this can
    happen with.  The reported applications have been: Background, Wait, Read,
    and Dial.  Also the AGI Get Data command.
    
    * Don't wait on the Asterisk channel after it has hung up.  The channel is
    likely to never need servicing again.
    
    * Restored the AGI script's ability to return the AGI_RESULT_HANGUP value
    in run_agi().  It previously only could return AGI_RESULT_SUCCESS or
    AGI_RESULT_FAILURE after the DeadAGI and AGI applications were merged.
    
    (closes issue #17954)
    Reported by: mn3250
    Patches:
          issue17954_v1.8.patch uploaded by rmudgett (license 664)
          issue17954_v1.6.2.patch uploaded by rmudgett (license 664)
          issue17954_v1.4.patch uploaded by rmudgett (license 664)
    Tested by: rmudgett
    JIRA SWP-2171
    
    (closes issue #18492)
    Reported by: devmod
    Tested by: rmudgett
    JIRA SWP-2761
    
    (closes issue #18935)
    Reported by: nvitaly
    Tested by: astmiv, rmudgett
    JIRA SWP-3216
    
    (closes issue #17393)
    Reported by: siby
    Tested by: rmudgett
    JIRA SWP-2727
    
    Review: https://reviewboard.asterisk.org/r/1165/
  ........
................


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@313588 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-04-13 16:31:50 +00:00
..
2010-12-20 09:14:29 +00:00
2011-02-02 18:56:42 +00:00
2010-07-14 15:48:36 +00:00
2010-06-17 17:23:43 +00:00
2010-07-16 13:32:22 +00:00
2010-05-18 22:48:51 +00:00
2010-04-22 18:07:02 +00:00