Skip to content
Snippets Groups Projects
  1. Nov 18, 2010
  2. Nov 17, 2010
  3. Nov 16, 2010
  4. Nov 15, 2010
  5. Nov 12, 2010
  6. Nov 11, 2010
  7. Nov 10, 2010
  8. Nov 09, 2010
  9. Nov 08, 2010
  10. Nov 05, 2010
  11. Nov 04, 2010
  12. 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
    • Richard Mudgett's avatar
      Merged revisions 293807 via svnmerge from · cbd42ce6
      Richard Mudgett authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ................
        r293807 | rmudgett | 2010-11-03 13:35:19 -0500 (Wed, 03 Nov 2010) | 34 lines
        
        Merged revisions 293806 via svnmerge from 
        https://origsvn.digium.com/svn/asterisk/branches/1.6.2
        
        ................
          r293806 | rmudgett | 2010-11-03 13:31:57 -0500 (Wed, 03 Nov 2010) | 27 lines
          
          Merged revisions 293805 via svnmerge from 
          https://origsvn.digium.com/svn/asterisk/branches/1.4
          
          ........
            r293805 | rmudgett | 2010-11-03 13:23:04 -0500 (Wed, 03 Nov 2010) | 20 lines
            
            Party A in an analog 3-way call would continue to hear ringback after party C answers.
            
            All parties are analog FXS ports.
            1) A calls B.
            2) A flash hooks to call C.
            3) A flash hooks to bring C into 3-way call before C answers.  (A and B hear ringback)
            4) C answers
            5) A continues to hear ringback during the 3-way call. (All parties can hear each other.)
            
            * Fixed use of wrong variable in dahdi_bridge() that stopped ringback on
            the wrong subchannel.
            
            * Made several debug messages have more information.
            
            A similar issue happens if B and C are SIP channels.  B continues to hear
            ringback.  For some reason this only affects v1.8 and trunk.
            
            * Don't start ringback on the real and 3-way subchannels when creating the
            3-way conference.  Removing this code is benign on v1.6.2 and earlier.
          ........
        ................
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@293808 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      cbd42ce6
  13. Nov 02, 2010
Loading