Skip to content
Snippets Groups Projects
  1. Feb 01, 2011
  2. Jan 31, 2011
  3. Jan 30, 2011
  4. Jan 29, 2011
  5. Jan 28, 2011
  6. Jan 27, 2011
  7. Jan 26, 2011
  8. Jan 25, 2011
    • Richard Mudgett's avatar
      Merged revisions 304007 via svnmerge from · ca014f49
      Richard Mudgett authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ................
        r304007 | rmudgett | 2011-01-25 17:28:25 -0600 (Tue, 25 Jan 2011) | 22 lines
        
        Merged revisions 304006 via svnmerge from 
        https://origsvn.digium.com/svn/asterisk/branches/1.6.2
        
        ................
          r304006 | rmudgett | 2011-01-25 17:25:32 -0600 (Tue, 25 Jan 2011) | 15 lines
          
          Merged revisions 304005 via svnmerge from 
          https://origsvn.digium.com/svn/asterisk/branches/1.4
          
          ........
            r304005 | rmudgett | 2011-01-25 17:21:09 -0600 (Tue, 25 Jan 2011) | 8 lines
            
            DTMF attended transfers sometimes fail for no apparent reason.
            
            The loop in feature_request_and_dial() can exit when Party C has answered
            without processing an AST_CONTROL_ANSWER.  Also sometimes an
            AST_CONTROL_ANSWER never happens even though Party C has answered.
            
            Don't hangup Party C if he is up or we receive an AST_CONTROL_ANSWER.
          ........
        ................
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@304008 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      ca014f49
    • Terry Wilson's avatar
      Merged revisions 303962 via svnmerge from · cd9221d2
      Terry Wilson authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ................
        r303962 | twilson | 2011-01-25 16:09:01 -0600 (Tue, 25 Jan 2011) | 30 lines
        
        Merged revisions 303960 via svnmerge from 
        https://origsvn.digium.com/svn/asterisk/branches/1.6.2
        
        ................
          r303960 | twilson | 2011-01-25 16:02:42 -0600 (Tue, 25 Jan 2011) | 23 lines
          
          Merged revisions 303906 via svnmerge from 
          https://origsvn.digium.com/svn/asterisk/branches/1.4
          
          ........
            r303906 | twilson | 2011-01-25 14:50:59 -0600 (Tue, 25 Jan 2011) | 16 lines
            
            Guard against retransmitting BYEs indefinitely
            
            In the case of an attended transfer (A calls B, A atxfers to C) where
            A becomes unreachable before replying to Asterisk's BYE, Asterisk can
            sometimes retransmit the BYE indefinitely. This is because
            __sip_autodestruct tests p->refer && !ast_test_flag(&p->flags[0],
            SIP_ALREADYGONE and will then transmit a BYE. When this BYE times out,
            it will not ever be marked as ALREADYGONE, so when __sip_autodestruct
            is called again, we end up starting the cycle over.
            
            This patch adds a call to sip_alreadygone(pkt->owner) in retrans_pkt
            in the case of a BYE that has timed out. This should prevent Asterisk
            from trying to transmit new BYE messages in the future.
            
            Review: https://reviewboard.asterisk.org/r/1077/
          ........
        ................
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303963 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      cd9221d2
    • Tilghman Lesher's avatar
      Merged revisions 303860 via svnmerge from · 50c43232
      Tilghman Lesher authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ................
        r303860 | tilghman | 2011-01-25 12:55:27 -0600 (Tue, 25 Jan 2011) | 12 lines
        
        Merged revisions 303858 via svnmerge from 
        https://origsvn.digium.com/svn/asterisk/branches/1.6.2
        
        ........
          r303858 | tilghman | 2011-01-25 12:41:26 -0600 (Tue, 25 Jan 2011) | 5 lines
          
          Fix "sip show user <tab>", so that it actually shows results, instead of just completing the last entry.
          
          (closes issue #16675)
          Reported by: pj
        ........
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303861 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      50c43232
    • Richard Mudgett's avatar
      Merged revisions 303771 via svnmerge from · 7889af7c
      Richard Mudgett authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ................
        r303771 | rmudgett | 2011-01-25 11:49:20 -0600 (Tue, 25 Jan 2011) | 54 lines
        
        Merged revisions 303769 via svnmerge from 
        https://origsvn.digium.com/svn/asterisk/branches/1.6.2
        
        ................
          r303769 | rmudgett | 2011-01-25 11:42:42 -0600 (Tue, 25 Jan 2011) | 47 lines
          
          Merged revisions 303765 via svnmerge from 
          https://origsvn.digium.com/svn/asterisk/branches/1.4
          
          ........
            r303765 | rmudgett | 2011-01-25 11:36:50 -0600 (Tue, 25 Jan 2011) | 40 lines
            
            Sending out unnecessary PROCEEDING messages breaks overlap dialing.
            
            Issue #16789 was a good idea.  Unfortunately, it breaks overlap dialing
            through Asterisk.  There is not enough information available at this point
            to know if dialing is complete.  The ast_exists_extension(),
            ast_matchmore_extension(), and ast_canmatch_extension() calls are not
            adequate to detect a dial through extension pattern of "_9!".
            
            Workaround is to use the dialplan Proceeding() application early in
            non-dial through extensions.
            
            * Effectively revert issue #16789.
            
            * Allow outgoing overlap dialing to hear dialtone and other early media.
            A PROGRESS "inband-information is now available" message is now sent after
            the SETUP_ACKNOWLEDGE message for non-digital calls.  An
            AST_CONTROL_PROGRESS is now generated for incoming SETUP_ACKNOWLEDGE
            messages for non-digital calls.
            
            * Handling of the AST_CONTROL_CONGESTION in chan_dahdi/sig_pri was
            inconsistent with the cause codes.
            
            * Added better protection from sending out of sequence messages by
            combining several flags into a single enum value representing call
            progress level.
            
            * Added diagnostic messages for deferred overlap digits handling corner
            cases.
            
            (closes issue #17085)
            Reported by: shawkris
            
            (closes issue #18509)
            Reported by: wimpy
            Patches:
                  issue18509_early_media_v1.8_v3.patch uploaded by rmudgett (license 664)
                  Expanded upon issue18509_early_media_v1.8_v3.patch to include analog
                  and SS7 because of backporting requirements.
            Tested by: wimpy, rmudgett
          ........
        ................
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303772 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      7889af7c
    • Jeff Peeler's avatar
      Merged revisions 303678 via svnmerge from · d3c7a689
      Jeff Peeler authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ................
        r303678 | jpeeler | 2011-01-25 11:02:38 -0600 (Tue, 25 Jan 2011) | 33 lines
        
        Merged revisions 303677 via svnmerge from 
        https://origsvn.digium.com/svn/asterisk/branches/1.6.2
        
        ................
          r303677 | jpeeler | 2011-01-25 10:59:28 -0600 (Tue, 25 Jan 2011) | 26 lines
          
          Merged revisions 303676 via svnmerge from 
          https://origsvn.digium.com/svn/asterisk/branches/1.4
          
          ........
            r303676 | jpeeler | 2011-01-25 10:58:29 -0600 (Tue, 25 Jan 2011) | 20 lines
            
            Fix voicemail sequencing for file based storage.
            
            A previous change was made to account for when the number of voicemail messages
            exceeds the max limit to be handled properly, but it caused gaps in the messages
            to not be properly handled. This has now been resolved.
            
            In later non 1.4 branches, it appears that resequencing wasn't even occurring
            due from what appears and accidental code removal.
            
            (closes issue #18498)
            Reported by: JJCinAZ
            Patches: 
                  bug18498v2.patch uploaded by jpeeler (license 325)
            
            (closes issue #18486)
            Reported by: bluefox
            Patches: 
                  bug18486.patch uploaded by jpeeler (license 325)
          ........
        ................
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303679 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      d3c7a689
Loading