Skip to content
Snippets Groups Projects
  1. Apr 09, 2015
    • George Joseph's avatar
      loader/main: Don't set ast_fully_booted until deferred reloads are processed · 9a63ada0
      George Joseph authored
      Until we have a true module management facility it's sometimes necessary for one 
      module to force a reload on another before its own load is complete.  If 
      Asterisk isn't fully booted yet, these reloads are deferred.  The problem is 
      that asterisk reports fully booted before processing the deferred reloads which 
      means Asterisk really isn't quite ready when it says it is.
      
      This patch moves the report of fully booted after the processing of the deferred 
      reloads is complete.
      
      Since the pjsip stack has the most number of related modules, I ran the 
      channels/pjsip testsuite to make sure there aren't any issues.  All tests 
      passed.
      
      Tested-by: George Joseph
      Review: https://reviewboard.asterisk.org/r/4604/
      ........
      
      Merged revisions 434544 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434546 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      9a63ada0
    • Mark Michelson's avatar
      Reduce duplication of common DNS code. · c08ebc6e
      Mark Michelson authored
      The NAPTR and SRV branches were worked on independently and
      resulted in some code being duplicated in each. Since both
      have been merged into trunk now, this patch reduces the
      duplication by factoring out common code into its own
      source files.
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434490 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      c08ebc6e
    • Matthew Jordan's avatar
      clang compiler warnings: Fix autological comparisons · ea009872
      Matthew Jordan authored
      This fixes autological comparison warnings in the following:
       * chan_skinny: letohl may return a signed or unsigned value, depending on the
         macro chosen
       * func_curl: Provide a specific cast to CURLoption to prevent mismatch
       * cel: Fix enum comparisons where the enum can never be negative
       * enum: Fix comparison of return result of dn_expand, which returns a signed
         int value
       * event: Fix enum comparisons where the enum can never be negative
       * indications: tone_data.freq1 and freq2 are unsigned, and hence can never be
         negative
       * presencestate: Use the actual enum value for INVALID state
       * security_events: Fix enum comparisons where the enum can never be negative
       * udptl: Don't bother to check if the return value from encode_length is less
         than 0, as it returns an unsigned int
       * translate: Since the parameters are unsigned int, don't bother checking
         to see if they are negative. The cast to unsigned int would already blow
         past the matrix bounds.
       * res_pjsip_exten_state: Use a temporary value to cache the return of
         ast_hint_presence_state
       * res_stasis_playback: Fix enum comparisons where the enum can never be
         negative
       * res_stasis_recording: Add an enum value for the case where the recording
         operation is in error; fix enum comparisons
       * resource_bridges: Use enum value as opposed to -1
       * resource_channels: Use enum value as opposed to -1
      
      Review: https://reviewboard.asterisk.org/r/4533
      ASTERISK-24917
      Reported by: dkdegroot
      patches:
        rb4533.patch submitted by dkdegroot (License 6600)
      ........
      
      Merged revisions 434469 from http://svn.asterisk.org/svn/asterisk/branches/11
      ........
      
      Merged revisions 434470 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      ea009872
  2. Apr 08, 2015
  3. Apr 07, 2015
  4. Apr 06, 2015
  5. Apr 01, 2015
  6. Mar 30, 2015
  7. Mar 28, 2015
  8. Mar 27, 2015
  9. Mar 26, 2015
  10. Mar 25, 2015
  11. Mar 23, 2015
  12. Mar 22, 2015
  13. Mar 20, 2015
  14. Mar 19, 2015
  15. Mar 17, 2015
  16. Mar 14, 2015
  17. Mar 13, 2015
  18. Mar 12, 2015
    • Matthew Jordan's avatar
      main/audiohook: Update internal sample rate on reads · 38ee441e
      Matthew Jordan authored
      When an audiohook is created (which is used by the various Spy applications
      and Snoop channel in Asterisk 13+), it initially is given a sample rate of
      8kHz. It is expected, however, that this rate may change based on the media
      that passes through the audiohook. However, the read/write operations on the
      audiohook behave very differently.
      
      When a frame is written to the audiohook, the format of the frame is checked
      against the internal sample rate. If the rate of the format does not match
      the internal sample rate, the internal sample rate is updated and a new SLIN
      format is chosen based on that sample rate. This works just fine.
      
      When a frame is read, however, we do something quite different. If the format
      rate matches the internal sample rate, all is fine. However, if the rates
      don't match, the audiohook attempts to "fix up" the number of samples that
      were requested. This can result in some seriously large number of samples
      being requested from the read/write factories.
      
      Consider the worst case - 192kHz SLIN. If we attempt to read 20ms worth of
      audio produced at that rate, we'd request 3840 samples (192000 / (1000 / 20)).
      However, if the audiohook is still expecting an internal sample rate of 8000,
      we'll attempt to "fix up" the requested samples to:
      
        samples_converted = samples * (ast_format_get_sample_rate(format) /
                                       (float) audiohook->hook_internal_samp_rate);
      
        which is:
      
        92160 = 3840 * (192000 / 8000)
      
      This results in us attempting to read 92160 samples from our factories, as
      opposed to the 3840 that we actually wanted. On a 64-bit machine, this
      miraculously survives - despite allocating up to two buffers of length 92160
      on the stack. The 32-bit machines aren't quite so lucky. Even in the case where
      this works, we will either (a) get way more samples than we wanted; or (b) get
      about 3840 samples, assuming the timing is pretty good on the machine.
      
      Either way, the calculation being performed is wrong, based on the API users
      expectations.
      
      My first inclination was to allocate the buffers on the heap. As it is,
      however, there's at least two drawbacks with doing this:
      (1) It's a bit complicated, as the size of the buffers may change during the
          lifetime of the audiohook (ew).
      (2) The stack is faster (yay); the heap is slower (boo).
      
      Since our calculation is flat out wrong in the first place, this patch fixes
      this issue by instead updating the internal sample rate based on the format
      passed into the read operation. This causes us to read the correct number of
      samples, and has the added benefit of setting the audihook with the right
      SLIN format.
      
      Note that this issue was caught by the Asterisk Test Suite as a result of
      r432195 in the 13 branch. Because this issue is also theoretically possible
      in Asterisk 11, the change is being made here as well.
      
      Review: https://reviewboard.asterisk.org/r/4475/
      ........
      
      Merged revisions 432810 from http://svn.asterisk.org/svn/asterisk/branches/11
      ........
      
      Merged revisions 432811 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432812 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      38ee441e
    • Matthew Jordan's avatar
      Add support for the clang compiler; update RAII_VAR to use BlocksRuntime · 29304d10
      Matthew Jordan authored
      RAII_VAR, which is used extensively in Asterisk to manage reference counted
      resources, uses a GCC extension to automatically invoke a cleanup function
      when a variable loses scope. While this functionality is incredibly useful
      and has prevented a large number of memory leaks, it also prevents Asterisk
      from being compiled with clang.
      
      This patch updates the RAII_VAR macro such that it can be compiled with clang.
      It makes use of the BlocksRuntime, which allows for a closure to be created
      that performs the actual cleanup.
      
      Note that this does not attempt to address the numerous warnings that the clang
      compiler catches in Asterisk.
      
      Much thanks for this patch goes to:
      * The folks on StackOverflow who asked this question and Leushenko for
        providing the answer that formed the basis of this code:
        http://stackoverflow.com/questions/24959440/rewrite-gcc-cleanup-macro-with-nested-function-for-clang
      * Diederik de Groot, who has been extremely patient in working on getting this
        patch into Asterisk.
      
      Review: https://reviewboard.asterisk.org/r/4370/
      
      ASTERISK-24133
      ASTERISK-23666
      ASTERISK-20399
      ASTERISK-20850 #close
      Reported by: Diederik de Groot
      patches:
        RAII_CLANG.patch uploaded by Diederik de Groot (License 6600)
      ........
      
      Merged revisions 432807 from http://svn.asterisk.org/svn/asterisk/branches/11
      ........
      
      Merged revisions 432808 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      29304d10
  19. Mar 10, 2015
Loading