Skip to content
Snippets Groups Projects
  1. Jan 31, 2011
  2. Jan 26, 2011
  3. Jan 24, 2011
    • Russell Bryant's avatar
      Merged revisions 303549 via svnmerge from · 09213439
      Russell Bryant authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ................
        r303549 | russell | 2011-01-24 14:51:37 -0600 (Mon, 24 Jan 2011) | 45 lines
        
        Merged revisions 303548 via svnmerge from 
        https://origsvn.digium.com/svn/asterisk/branches/1.6.2
        
        ................
          r303548 | russell | 2011-01-24 14:49:53 -0600 (Mon, 24 Jan 2011) | 38 lines
          
          Merged revisions 303546 via svnmerge from 
          https://origsvn.digium.com/svn/asterisk/branches/1.4
          
          ........
            r303546 | russell | 2011-01-24 14:32:21 -0600 (Mon, 24 Jan 2011) | 31 lines
            
            Fix channel redirect out of MeetMe() and other issues with channel softhangup.
            
            Mantis issue #18585 reports that a channel redirect out of MeetMe() stopped
            working properly.  This issue includes a patch that resolves the issue by
            removing a call to ast_check_hangup() from app_meetme.c.  I left that in my
            patch, as it doesn't need to be there.  However, the rest of the patch fixes
            this problem with or without the change to app_meetme.
            
            The key difference between what happens before and after this patch is the
            effect of the END_OF_Q control frame.  After END_OF_Q is hit in ast_read(),
            ast_read() will return NULL.  With the ast_check_hangup() removed, app_meetme
            sees this which causes it to exit as intended.  Checking ast_check_hangup()
            caused app_meetme to exit earlier in the process, and the target of the
            redirect saw the condition where ast_read() returned NULL.
            
            Removing ast_check_hangup() works around the issue in app_meetme, but doesn't
            solve the issue if another application did the same thing.  There are also
            other edge cases where if an application finishes at the same time that a
            redirect happens, the target of the redirect will think that the channel hung
            up.  So, I made some changes in pbx.c to resolve it at a deeper level.  There
            are already places that unset the SOFTHANGUP_ASYNCGOTO flag in an attempt to
            abort the hangup process.  My patch extends this to remove the END_OF_Q frame
            from the channel's read queue, making the "abort hangup" more complete.  This
            same technique was used in every place where a softhangup flag was cleared.
            
            (closes issue #18585)
            Reported by: oej
            Tested by: oej, wedhorn, russell
            
            Review: https://reviewboard.asterisk.org/r/1082/
          ........
        ................
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303551 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      09213439
    • Matthew Nicholson's avatar
      According to section 19.1.2 of RFC 3261: · e706b570
      Matthew Nicholson authored
        For each component, the set of valid BNF expansions defines exactly
        which characters may appear unescaped.  All other characters MUST be
        escaped.
      
      This patch modifies ast_uri_encode() to encode strings in line with this recommendation.  This patch also adds an ast_escape_quoted() function which escapes '"' and '\' characters in quoted strings in accordance with section 25.1 of RFC 3261.  The ast_uri_encode() function has also been modified to take an ast_flags struct describing the set of rules it should use when escaping characters to allow for it to escape SIP URIs in addition to HTTP URIs and other types of URIs or variations of those two URI types in the future.
      
      The ast_uri_decode() function has also been modified to accept an ast_flags struct describing the set of rules to use when decoding to enable decoding '+' as ' ' in legacy http URLs.
      
      The unit tests for these functions have also been updated.
      
      ABE-2705
      
      Review: https://reviewboard.asterisk.org/r/1081/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303509 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      e706b570
  4. Jan 19, 2011
  5. Dec 20, 2010
  6. Dec 18, 2010
  7. Dec 12, 2010
  8. Dec 10, 2010
  9. Dec 03, 2010
    • Matthew Nicholson's avatar
      Merged revisions 297157,297486,297495 via svnmerge from · 23d106b8
      Matthew Nicholson authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ........
        r297157 | mnicholson | 2010-12-01 13:47:33 -0600 (Wed, 01 Dec 2010) | 2 lines
        
        Changed some NOTICE and WARNING messages to DEBUG messages.
      ........
        r297486 | mnicholson | 2010-12-02 15:30:47 -0600 (Thu, 02 Dec 2010) | 6 lines
        
        Add support for reserving a fax session before answering the channel.
        
        Note: this change breaks ABI compatibility.
        
        FAX-217
      ........
        r297495 | mnicholson | 2010-12-03 09:21:52 -0600 (Fri, 03 Dec 2010) | 4 lines
        
        Print a DEBUG message instead of a WARNING message when the selected fax tech does not support reserving sessions.
        
        Answer the channel before quering it for t.38 support.  This is necessary for the query to work properly over local channels.
      ........
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@297496 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      23d106b8
  10. Dec 01, 2010
  11. Nov 30, 2010
  12. Nov 29, 2010
  13. Nov 27, 2010
  14. Nov 22, 2010
    • Richard Mudgett's avatar
      Merged revisions 295866 via svnmerge from · 7c7486ad
      Richard Mudgett authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ................
        r295866 | rmudgett | 2010-11-22 13:36:10 -0600 (Mon, 22 Nov 2010) | 60 lines
        
        Merged revisions 295843 via svnmerge from 
        https://origsvn.digium.com/svn/asterisk/branches/1.6.2
        
        ................
          r295843 | rmudgett | 2010-11-22 13:28:23 -0600 (Mon, 22 Nov 2010) | 53 lines
          
          Merged revisions 295790 via svnmerge from 
          https://origsvn.digium.com/svn/asterisk/branches/1.4
          
          ........
            r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010) | 46 lines
            
            The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call.
            
            To recreate the problem:
            1) Party A calls Party B
            2) Invoke CLI "channel redirect" command to redirect channel call leg
            associated with A.
            3) All associated channels are hung up.
            
            Note that if the CLI command were done on the channel call leg associated
            with B it works.
            
            This regression was a result of the fix for issue #16946
            (https://reviewboard.asterisk.org/r/740/).
            
            The regression affects all features that use an async goto to execute the
            dialplan because of an external event: Channel redirect, AMI redirect, SIP
            REFER, and FAX detection.
            
            The struct ast_channel._softhangup code is a mess.  The variable is used
            for several purposes that do not necessarily result in the call being hung
            up.  I have added doxygen comments to describe how the various _softhangup
            bits are used.  I have corrected all the places where the variable was
            tested in a non-bit oriented manner.
            
            The primary fix is the new AST_CONTROL_END_OF_Q frame.  It acts as a weak
            hangup request so the soft hangup requests that do not normally result in
            a hangup do not hangup.
            
            JIRA SWP-2470
            JIRA SWP-2489
            
            (closes issue #18171)
            Reported by: SantaFox
            (closes issue #18185)
            Reported by: kwemheuer
            (closes issue #18211)
            Reported by: zahir_koradia
            (closes issue #18230)
            Reported by: vmarrone
            (closes issue #18299)
            Reported by: mbrevda
            (closes issue #18322)
            Reported by: nerbos
            
            Review:	https://reviewboard.asterisk.org/r/1013/
          ........
        ................
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@295867 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      7c7486ad
  15. Nov 20, 2010
    • Russell Bryant's avatar
      Merged revisions 295711 via svnmerge from · 9fbbdfb2
      Russell Bryant authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ................
        r295711 | russell | 2010-11-19 18:50:00 -0600 (Fri, 19 Nov 2010) | 36 lines
        
        Merged revisions 295710 via svnmerge from 
        https://origsvn.digium.com/svn/asterisk/branches/1.6.2
        
        ........
          r295710 | russell | 2010-11-19 18:45:51 -0600 (Fri, 19 Nov 2010) | 29 lines
          
          Fix cache of device state changes for multiple servers.
          
          This patch addresses a regression where device states across multiple servers
          were not being processing completely correctly.  The code works to determine
          the overall state by looking at the last known state of a device on each
          server.  However, there was a regression due to some invasive rewrites of how
          the cache works that led to the cache only storing the last device state change
          for a device, regardless of which server it was on.
          
          The code is set up to cache device state change events by ensuring that each
          event in the cache has a unique device name + entity ID (server ID).  The code
          that was responsible for comparing raw information elements (which EID is)
          always returned a match due to a memcmp() with a length of 0.
          
          There isn't much code to fix the actual bug.  This patch also introduces a new
          CLI command that was very useful for debugging this problem.  The command
          allows you to dump the contents of the event cache.
          
          (closes issue #18284)
          Reported by: klaus3000
          Patches:
                issue18284.rev1.txt uploaded by russell (license 2)
          Tested by: russell, klaus3000
          
          (closes issue #18280)
          Reported by: klaus3000
          
          Review: https://reviewboard.asterisk.org/r/1012/
        ........
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@295712 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      9fbbdfb2
  16. Nov 18, 2010
  17. Nov 09, 2010
  18. Nov 08, 2010
    • Jeff Peeler's avatar
      Merged revisions 294278 via svnmerge from · 12a40275
      Jeff Peeler authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ................
        r294278 | jpeeler | 2010-11-08 15:59:45 -0600 (Mon, 08 Nov 2010) | 23 lines
        
        Merged revisions 294277 via svnmerge from 
        https://origsvn.digium.com/svn/asterisk/branches/1.6.2
        
        ........
          r294277 | jpeeler | 2010-11-08 15:58:13 -0600 (Mon, 08 Nov 2010) | 16 lines
          
          Fix playback failure when using IAX with the timerfd module.
          
          To fix this issue the alert pipe will now be used when the timerfd module is
          in use. There appeared to be a race that was not solved by adding locking in the
          timerfd module, but needed to be there anyway. The race was between the timer
          being put in non-continuous mode in ast_read on the channel thread and the IAX 
          frame scheduler queuing a frame which would enable continuous mode before the
          non-continuous mode event was read. This race for now is simply avoided.
          
          (closes issue #18110)
          Reported by: tpanton
          Tested by: tpanton
          
          I put tested by tpanton because it was tested on his hardware. Thanks for the
          remote access to debug this issue!
        ........
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@294279 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      12a40275
  19. Nov 03, 2010
    • Terry Wilson's avatar
      Merged revisions 293803 via svnmerge from · abc94089
      Terry Wilson authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ........
        r293803 | twilson | 2010-11-03 11:05:14 -0700 (Wed, 03 Nov 2010) | 25 lines
        
        Avoid valgrind warnings for ast_rtp_instance_get_xxx_address
        
        The documentation for ast_rtp_instance_get_(local/remote)_address stated that
        they returned 0 for success and -1 on failure. Instead, they returned 0 if the
        address structure passed in was already equivalent to the address instance
        local/remote address or 1 otherwise. 90% of the calls to these functions
        completely ignored the return address and passed in an uninitialized struct,
        which would make valgrind complain even though the operation was technically
        safe.
        
        This patch fixes the documentation and converts the get_xxx_address functions
        to void since all they really do is copy the address and cannot fail.
        Additionally two new functions
        (ast_rtp_instance_get_and_cmp_(local/remote)_address) are created for the 3
        times where the return value was actually checked. The
        get_and_cmp_local_address function is currently unused, but exists for the sake
        of symmetry.
        
        The only functional change as a result of this change is that we will not do an
        ast_sockaddr_cmp() on (mostly uninitialized) addresses before doing the
        ast_sockaddr_copy() in the get_*_address functions. So, even though it is an
        API change, it shouldn't have a noticeable change in behavior.
        
        Review: https://reviewboard.asterisk.org/r/995/
      ........
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@293809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      abc94089
  20. Oct 26, 2010
  21. Oct 25, 2010
  22. Oct 14, 2010
  23. Oct 11, 2010
    • David Vossel's avatar
      Merged revisions 291192 via svnmerge from · 0736871c
      David Vossel authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ........
        r291192 | dvossel | 2010-10-11 16:38:39 -0500 (Mon, 11 Oct 2010) | 19 lines
        
        Gtalk enhancements and general code cleanup.
        
        This patch includes several chan_gtalk enhancements.
        Two new gtalk.conf options have been added, externip
        and stunadd.  Setting externip allows us to
        manually specify what the external IP address is
        outside of a NAT environment.  Setting the stunaddr
        option to a valid stun server allows for that external
        ip to be retrieved via a STUN server automatically.  This
        external IP is then advertised during call setup as
        a possible candidate.
        
        I have also attempted to clean up chan_gtalk's code
        so it meets our coding guidelines. During this cleanup
        I noticed several things that need to be done in the
        code and made a TODO section at the top of the file.
      ........
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@291193 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      0736871c
  24. Oct 07, 2010
  25. Oct 05, 2010
  26. Oct 02, 2010
  27. Sep 30, 2010
  28. Sep 28, 2010
  29. Sep 24, 2010
  30. Sep 20, 2010
    • David Vossel's avatar
      Merged revisions 287647 via svnmerge from · 2f3dee23
      David Vossel authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ........
        r287647 | dvossel | 2010-09-20 17:09:16 -0500 (Mon, 20 Sep 2010) | 21 lines
        
        Addition of the FrameHook API (AKA AwesomeHooks)
        
        So far all our tools for viewing and manipulating media streams
        within Asterisk have been entirely focused on audio.  That made
        sense then, but is not scalable now.  The FrameHook API lets us
        tap into and manipulate _ANY_ type of media or signaling passed
        on a channel present today or in the future.  This tool is a step
        in the direction of expanding Asterisk's boundaries and will help
        generate some rather interesting applications in the future.
        
        In addition to the FrameHook API, a simple dialplan function
        exercising the api has been included as well.  This function
        is called FRAME_TRACE().  FRAME_TRACE() allows for the internal
        ast_frames read and written to a channel to be output.  Filters
        can be placed on this function to debug only certain types of frames.
        This function could be thought of as an internal way of doing
        ast_frame packet captures.
        
        Review: https://reviewboard.asterisk.org/r/925/
      ........
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287648 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      2f3dee23
  31. Sep 15, 2010
  32. Sep 10, 2010
Loading