Skip to content
Snippets Groups Projects
  1. Sep 26, 2008
  2. Sep 25, 2008
    • Steve Murphy's avatar
      (closes issue #13557) · e74584ca
      Steve Murphy authored
      Reported by: nickpeirson
      
      The user attached a patch, but the license is not yet
      recorded. I took the liberty of finding and replacing
      ALL index() calls with strchr() calls, and that
      involves more than just main/pbx.c;
      
      chan_oss, app_playback, func_cut also had calls
      to index(), and I changed them out. 1.4 had no
      references to index() at all.
      
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@144569 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      e74584ca
    • Steve Murphy's avatar
      (closes issue #13559) · a36696f2
      Steve Murphy authored
      Reported by: mnicholson
      Patches:
            pbx_lua8.diff uploaded by mnicholson (license 96)
      
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@144563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      a36696f2
    • Steve Murphy's avatar
      I added a little verbage to hashtab for the hashtab_destroy func. · 38028fa6
      Steve Murphy authored
      It was pretty sparsely documented.
      
      This update fleshes out the pbx_lua module, to 
      add the switch statements to the extensions in the
      extensions.lua file, as well as removing them when
      the module is unloaded.
      
      Many thanks to Matt Nicholson for his fine
      contribution!
      
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@144523 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      38028fa6
    • Steve Murphy's avatar
      (closes issue #13558) · f8ddaae7
      Steve Murphy authored
      Reported by: mnicholson
      
      Considering that the example extensions.lua used nothing but ["12345"] notation,
      and that the resulting error message: 
      
      [Sep 24 17:01:16] ERROR[12393]: pbx_lua.c:1204 exec: Error executing lua extension: attempt to call a nil value
      
      is not very informative as to the nature of the problem, I think this bug
      fix is a big win!
      
      
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@144482 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      f8ddaae7
    • Steve Murphy's avatar
      Blocked revisions 144420 via svnmerge · 82abf73a
      Steve Murphy authored
      I am pushing this up to trunk and beyond, because I am not
      certain that this bug will happen in the same way in 
      trunk and 1.6.x. If someone can document this problem
      in 1.6.x or trunk, I can revert this block and push the
      change up.
      
      ........
      r144420 | murf | 2008-09-25 10:12:14 -0600 (Thu, 25 Sep 2008) | 25 lines
      
      (closes issue #12101)
      Reported by: MVF
      Tested by: neutrino88, urzedo, murf, thiagofernandes
      
      Many thanks to neutrino88 for this patch, which
      solves a problem whereby channels get a CANCEL
      request, respond to it properly, but end up 
      in a hung state, infinitely being rescheduled.
      This fix is a bit crude, in that catches the
      problem at a rather late phase, but it may
      prevent infinite rescheduling problems that
      might still arise.
      
      It might have been better to find out why,
      in the course of protocol handling, the channel
      was not destroyed, but we leave that to 
      future generations.
      
      Many thanks to urzedo and thiagofernandes for
      their work in verifying that the patch code
      indeed is being executing, and averting the
      problem.
      
      
      
      ........
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@144421 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      82abf73a
    • Tilghman Lesher's avatar
      Recorded merge of revisions 144356 via svnmerge from · 5d5a7793
      Tilghman Lesher authored
      https://origsvn.digium.com/svn/asterisk/branches/1.4
      
      ........
        r144356 | tilghman | 2008-09-24 20:44:47 -0500 (Wed, 24 Sep 2008) | 6 lines
        
        Backport Hebrew language to voicemail.
        (closes issue #13155)
         Reported by: greenfieldtech
         Patches: 
               voicemail-hebrew-patch-1.4-SVN.c.patch uploaded by greenfieldtech (license 369)
      ........
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@144357 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      5d5a7793
  3. Sep 24, 2008
  4. Sep 23, 2008
    • Mark Michelson's avatar
      Fix a conflict in flag values · ad859c94
      Mark Michelson authored
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@144149 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      ad859c94
    • Steve Murphy's avatar
      Merged revisions 144066 via svnmerge from · 8343faed
      Steve Murphy authored
      https://origsvn.digium.com/svn/asterisk/branches/1.4
      
      ........
      r144066 | murf | 2008-09-23 10:41:49 -0600 (Tue, 23 Sep 2008) | 29 lines
      
      (closes issue #13489)
      Reported by: DougUDI
      Tested by: murf
      
      (closes issue #13490)
      Reported by: seanbright
      Tested by: murf
      
      (closes issue #13467)
      Reported by: edantie
      Tested by: murf, edantie, DougUDI
      
      
      This crash happens because we are unsafely handling old pointers.
      The channel whose cdr is being handled, has been hung up and 
      destroyed already. I reorganized the code a bit, and tried not
      to lose the fork-cdr-chain concepts of the previous code.
      I now verify that the 'previous' channel (the channel we
      had when the bridge was started), still exists, by looking it up
      by name in the channel list. I also do not try to reset the
      CDR's of channels involved in bridges. 
      
      Testing shows it solves the crash problem, and should not
      negatively impact previous fixes involving CDR's generated
      during/after blind transfers. (The reason we need to reset
      the CDR's on the "beginning" channels in the first place).
      
      
      
      ........
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@144067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      8343faed
    • Mark Michelson's avatar
      When a promiscuous redirect contained both a user and · 8625eb9d
      Mark Michelson authored
      host portion in the Contact URI and specifies a 
      transport, the parsing done in parse_moved_contact
      resulted in a malformed URI.
      
      This commit fixes the parsing so that a proper
      Dial string may be formed when the forwarded
      call is placed.
      
      (closes issue #13523)
      Reported by: mattdarnell
      Patches:
            13523v2.patch uploaded by putnopvut (license 60)
      Tested by: mattdarnell
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@144025 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      8625eb9d
    • Steve Murphy's avatar
      Blocked revisions 143964 via svnmerge · b3ee41ad
      Steve Murphy authored
      ........
      r143964 | murf | 2008-09-23 08:22:10 -0600 (Tue, 23 Sep 2008) | 21 lines
      
      In at least one machine, we noted that the timestr
      was not getting set in the STMT; it was coming out,
      usually, as binary garbage to an mssql server.
      These changes fixed the problem. The only thing
      I can venture forth as a guess, is that the pointer
      is being stored in the interface, not a copy of the
      string. Because we ripped the build process into a 
      subroutine, the timestr became a temp. stack variable,
      and between the time the STMT got built and the
      time it was executed on the server, the string being
      pointed to was damaged. At any rate, even if this
      theory is false, and some mechanism was at fault,
      this fix worked reliably where it didn't before.
      
      Why this bug didn't bite last week, I have no idea.
      This change basically defines the timestr buffer
      in the calling function, extending the life of the
      buffer to cover both the STMT's building and
      processing to the server.
      
      I AM BLOCKING THIS FIX FROM TRUNK, because we
      tested out a trunk release, and it is working
      fine.
      ........
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@143974 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      b3ee41ad
  5. Sep 22, 2008
  6. Sep 21, 2008
  7. Sep 20, 2008
  8. Sep 19, 2008
  9. Sep 18, 2008
  10. Sep 17, 2008
  11. Sep 16, 2008
    • Jeff Peeler's avatar
      Blocked revisions 143270 via svnmerge · 8af206ab
      Jeff Peeler authored
      ........
      r143270 | jpeeler | 2008-09-16 16:44:21 -0500 (Tue, 16 Sep 2008) | 9 lines
      
      (closes issue #13493)
      Reported by: mdu113
      Patches:
            bug13493.diff uploaded by jpeeler (license 325)
      Tested by: mdu113
      
      Changed park_call_full to hold the parkinglot lock a little longer, which protects the parkeduser struct from being freed out from underneath. Made sure that the parking extension is added to the parking context while holding the lock thereby ensuring that there are no spurious warnings from removal attempts when a hangup occurs while the parking lot is being announced.
      
      
      ........
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@143271 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      8af206ab
    • Jeff Peeler's avatar
      Blocked revisions 143204 via svnmerge · 8b3cbaa7
      Jeff Peeler authored
      ........
      r143204 | jpeeler | 2008-09-16 11:14:25 -0500 (Tue, 16 Sep 2008) | 10 lines
      
      (closes issue #13465)
      (closes issue #13425)
      Reported by: mdu113
      Patches:
            bug13425.diff uploaded by jpeeler (license 325)
      Tested by: mdu113
      
      The main change here was to masquerade the channel if the channel that was to be parked was running a PBX on it. The PBX thread can then maintain full control of the channel (the zombie) as it expects to while allowing the parking thread full control of the real (parked) channel.
      
      
      ........
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@143226 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      8b3cbaa7
  12. Sep 15, 2008
  13. Sep 14, 2008
  14. Sep 13, 2008
  15. Sep 12, 2008
Loading