Skip to content
Snippets Groups Projects
Select Git revision
20 results
Search by author
  • Any Author
  • Adam Porteous Adam Porteous adam.porteous
  • Alex Hopkins Alex Hopkins 59hopper
  • Amin Ben Romdhane Amin Ben Romdhane amin.benromdhane
  • Andreas Gnau Andreas Gnau AGnau
  • Andrej Kucharik Andrej Kucharik andrej.kucharik
  • Andrii Pypa Andrii Pypa andrii.pypa
  • Anjan Chanda Anjan Chanda anjancx
  • Balalakshmi Arunachalam Rajendran Balalakshmi Arunachalam Rajendran arbala
  • Benjamin Larsson Benjamin Larsson benjamin
  • Charles Foster Charles Foster charles.foster_bt.com
  • Dariusz Iwanoczko Dariusz Iwanoczko dariusz.iwanoczko
  • Divya Chandrasekaran Divya Chandrasekaran divya.c
  • Dominic Lake Dominic Lake dominic.lake
  • Elena Vengerova Elena Vengerova helen
  • Erik Karlsson Erik Karlsson erik.karlsson
  • Filip Matusiak Filip Matusiak filmat
  • Filip Strelec Filip Strelec filip.strelec
  • Fredrik Östling Fredrik Östling fredrik.ostling
  • Geoff Elliott Geoff Elliott gdelliott
  • George Yang George Yang gyang
20 authors
  1. Nov 10, 2010
  3. Nov 09, 2010
  5. Nov 08, 2010
  7. Nov 05, 2010
  9. Nov 04, 2010
  11. 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
  15. Nov 01, 2010
  17. Oct 30, 2010
  19. Oct 29, 2010
  21. Oct 28, 2010
  23. Oct 26, 2010
  25. Oct 25, 2010
    • Tilghman Lesher's avatar
      Merged revisions 292969 via svnmerge from · f96d27b9
      Tilghman Lesher authored 
      https://origsvn.digium.com/svn/asterisk/branches/1.8

........
  r292969 | tilghman | 2010-10-25 16:15:19 -0500 (Mon, 25 Oct 2010) | 2 lines
  
  Several more defines that need to be altered for compiling against an older version of libpri
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@292970 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      f96d27b9
    • Tilghman Lesher's avatar
      Merged revisions 292906 via svnmerge from · 7bc278bd
      Tilghman Lesher authored 
      https://origsvn.digium.com/svn/asterisk/branches/1.8

........
  r292906 | tilghman | 2010-10-25 14:28:35 -0500 (Mon, 25 Oct 2010) | 4 lines
  
  Allow the DAHDI driver to compile, even with a sufficiently older version of libpri.
  
  Fixes our Bamboo builds.
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@292915 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      7bc278bd
    • David Vossel's avatar
      Merged revisions 292868 via svnmerge from · 7189a944
      David Vossel authored 
      https://origsvn.digium.com/svn/asterisk/branches/1.8

................
  r292868 | dvossel | 2010-10-25 14:07:50 -0500 (Mon, 25 Oct 2010) | 39 lines
  
  Merged revisions 292867 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
  
  ................
    r292867 | dvossel | 2010-10-25 14:06:21 -0500 (Mon, 25 Oct 2010) | 32 lines
    
    Merged revisions 292866 via svnmerge from 
    https://origsvn.digium.com/svn/asterisk/branches/1.4
    
    ........
      r292866 | dvossel | 2010-10-25 14:05:07 -0500 (Mon, 25 Oct 2010) | 27 lines
      
      This patch turns chan_local pvts into astobj2 objects.
      
      chan_local does some dangerous things involving deadlock avoidance.
      tech_pvt functions like hangup and queue_frame are provided with a
      locked channel upon entry.  Those functions are completely safe as
      long as you don't attempt to give up that channel lock, but that is
      impossible to guarantee due to the required deadlock avoidance necessary
      to lock both the tech_pvt and both channels involved.
      
      In the past, we have tried to account for this by doing things like
      setting a "glare" flag that indicates what function should destroy the
      pvt.  This was used in local_hangup and local_queue_frame to decided
      who should destroy the pvt if they collided in separate threads.  I
      have removed the need to do this by converting all chan_local tech_pvts
      to astobj2.  This means we can ref a pvt before deadlock avoidance
      and not have to worry about that pvt possibly getting destroyed under
      us.  It also cleans up where we destroy the tech_pvt.  The only unlink
      from the tech_pvt container occurs in local_hangup now, which is where
      it should occur.
      
      Since there still may be thread collisions on some functions like
      local_hangup after deadlock avoidance, I have added some checks to detect
      those collisions and exit appropriately.  I think this patch is going to
      solve quite a bit of weirdness we have had with local channels in the past.
    ........
  ................
................


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@292869 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      7189a944
  27. Oct 22, 2010