Skip to content
Snippets Groups Projects
  1. Dec 03, 2013
  2. Oct 23, 2013
  3. Oct 08, 2013
  4. Sep 30, 2013
    • Matthew Jordan's avatar
      Parse arguments passed to the CDR_PROP function correctly · de07050d
      Matthew Jordan authored
      I can only blame this on a bad merge, because this in no way worked properly
      the way it was written. Mea culpa. The function should now parse its arguments
      correctly and function properly. (Note that the API used by the CDR_PROP
      function has working unit tests... this was merely bad coding of the actual
      registered function)
      
      (closes issue ASTERISK-22613)
      Reported by: Private Name
      ........
      
      Merged revisions 400196 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      de07050d
    • David M. Lee's avatar
      Multiple revisions 399887,400138,400178,400180-400181 · 2de42c2a
      David M. Lee authored
      ........
        r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line
        
        Minor performance bump by not allocate manager variable struct if we don't need it
      ........
        r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines
        
        Stasis performance improvements
        
        This patch addresses several performance problems that were found in
        the initial performance testing of Asterisk 12.
        
        The Stasis dispatch object was allocated as an AO2 object, even though
        it has a very confined lifecycle. This was replaced with a straight
        ast_malloc().
        
        The Stasis message router was spending an inordinate amount of time
        searching hash tables. In this case, most of our routers had 6 or
        fewer routes in them to begin with. This was replaced with an array
        that's searched linearly for the route.
        
        We more heavily rely on AO2 objects in Asterisk 12, and the memset()
        in ao2_ref() actually became noticeable on the profile. This was
        #ifdef'ed to only run when AO2_DEBUG was enabled.
        
        After being misled by an erroneous comment in taskprocessor.c during
        profiling, the wrong comment was removed.
        
        Review: https://reviewboard.asterisk.org/r/2873/
      ........
        r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines
        
        Taskprocessor optimization; switch Stasis to use taskprocessors
        
        This patch optimizes taskprocessor to use a semaphore for signaling,
        which the OS can do a better job at managing contention and waiting
        that we can with a mutex and condition.
        
        The taskprocessor execution was also slightly optimized to reduce the
        number of locks taken.
        
        The only observable difference in the taskprocessor implementation is
        that when the final reference to the taskprocessor goes away, it will
        execute all tasks to completion instead of discarding the unexecuted
        tasks.
        
        For systems where unnamed semaphores are not supported, a really
        simple semaphore implementation is provided. (Which gives identical
        performance as the original taskprocessor implementation).
        
        The way we ended up implementing Stasis caused the threadpool to be a
        burden instead of a boost to performance. This was switched to just
        use taskprocessors directly for subscriptions.
        
        Review: https://reviewboard.asterisk.org/r/2881/
      ........
        r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines
        
        Optimize how Stasis forwards are dispatched
        
        This patch optimizes how forwards are dispatched in Stasis.
        
        Originally, forwards were dispatched as subscriptions that are invoked
        on the publishing thread. This did not account for the vast number of
        forwards we would end up having in the system, and the amount of work it
        would take to walk though the forward subscriptions.
        
        This patch modifies Stasis so that rather than walking the tree of
        forwards on every dispatch, when forwards and subscriptions are changed,
        the subscriber list for every topic in the tree is changed.
        
        This has a couple of benefits. First, this reduces the workload of
        dispatching messages. It also reduces contention when dispatching to
        different topics that happen to forward to the same aggregation topic
        (as happens with all of the channel, bridge and endpoint topics).
        
        Since forwards are no longer subscriptions, the bulk of this patch is
        simply changing stasis_subscription objects to stasis_forward objects
        (which, admittedly, I should have done in the first place.)
        
        Since this required me to yet again put in a growing array, I finally
        abstracted that out into a set of ast_vector macros in
        asterisk/vector.h.
        
        Review: https://reviewboard.asterisk.org/r/2883/
      ........
        r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines
        
        Remove dispatch object allocation from Stasis publishing
        
        While looking for areas for performance improvement, I realized that an
        unused feature in Stasis was negatively impacting performance.
        
        When a message is sent to a subscriber, a dispatch object is allocated
        for the dispatch, containing the topic the message was published to, the
        subscriber the message is being sent to, and the message itself.
        
        The topic is actually unused by any subscriber in Asterisk today. And
        the subscriber is associated with the taskprocessor the message is being
        dispatched to.
        
        First, this patch removes the unused topic parameter from Stasis
        subscription callbacks.
        
        Second, this patch introduces the concept of taskprocessor local data,
        data that may be set on a taskprocessor and provided along with the data
        pointer when a task is pushed using the ast_taskprocessor_push_local()
        call. This allows the task to have both data specific to that
        taskprocessor, in addition to data specific to that invocation.
        
        With those two changes, the dispatch object can be removed completely,
        and the message is simply refcounted and sent directly to the
        taskprocessor.
        
        Review: https://reviewboard.asterisk.org/r/2884/
      ........
      
      Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      2de42c2a
  5. Sep 10, 2013
  6. Aug 28, 2013
  7. Aug 17, 2013
    • Kinsey Moore's avatar
      Strip down the old event system · 59753b1e
      Kinsey Moore authored
      This removes unused code, event types, IE pltypes, and event IE types
      where possible and makes several functions private that were once
      public. This includes a renumbering of the remaining event and IE types
      which breaks binary compatibility with previous versions. The last
      remaining consumers of the old event system (or parts thereof) are
      main/security_events.c, res/res_security_log.c, tests/test_cel.c,
      tests/test_event.c, main/cel.c, and the CEL backends.
      
      Review: https://reviewboard.asterisk.org/r/2703/
      (closes issue ASTERISK-22139)
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396887 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      59753b1e
  8. Aug 06, 2013
  9. Aug 02, 2013
  10. Aug 01, 2013
  11. Jul 25, 2013
  12. Jul 23, 2013
  13. Jul 21, 2013
  14. Jul 14, 2013
  15. Jun 26, 2013
  16. Jun 19, 2013
    • Matthew Jordan's avatar
      Handle variable substitution in dummy variables · 68103abb
      Matthew Jordan authored
      When func_cdr is used for variable substitution, there is no channel name
      and hence no run-time information available for CDR variable substitution.
      In that case, the correct thing to do is to use the CDR object on the channel
      passed to the function. This patch checks to see if the channel passed in
      has a name - if not, it uses ast_cdr_format_var instead of ast_cdr_get_var.
      
      This allows CDR backends to continue to use variable substitution in order to
      resolve ast_cdr object properties.
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392214 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      68103abb
  17. Jun 17, 2013
    • David M. Lee's avatar
      Fix build warnings related to printf/scanf of tv_usec. · 4aa47d68
      David M. Lee authored
      The type of tv_usec is suseconds_t. On Linux, this is usually a long int, but
      the specification is actually pretty lax on what it might actually be. And,
      sadly, there's no printf/scanf width specifier for suseconds_t. So it could
      bit an int or a long, but there's not a great way to tell which it is.
      
      This patch fixes scanf by reading into a long temporary variable that's then
      stored into the tv_usec. It fixes printf by casting the tv_usec to a long
      first.
      
      This patch also adds some missing width specifiers for some debug statements,
      which would cause ".000001" to be displayed at ".1".
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392076 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      4aa47d68
    • Matthew Jordan's avatar
      Update Asterisk's CDRs for the new bridging framework · 6258bbe7
      Matthew Jordan authored
      This patch is the initial push to update Asterisk's CDR engine for the new
      bridging framework. This patch guts the existing CDR engine and builds the new
      on top of messages coming across Stasis. As changes in channel state and bridge
      state are detected, CDRs are built and dispatched accordingly. This
      fundamentally changes CDRs in a few ways.
      (1) CDRs are now *very* reflective of the actual state of channels and bridges.
          This means CDRs track well with what an actual channel is doing - which
          is useful in transfer scenarios (which were previously difficult to pin
          down). It does, however, mean that CDRs cannot be 'fooled'. Previous
          behavior in Asterisk allowed for CDR applications, channels, and other
          properties to be spoofed in parts of the code - this no longer works.
      (2) CDRs have defined behavior in multi-party scenarios. This behavior will not
          be what everyone wants, but it is a defined behavior and as such, it is
          predictable.
      (3) The CDR manipulation functions and applications have been overhauled. Major
          changes have been made to ResetCDR and ForkCDR in particular. Many of the
          options for these two applications no longer made any sense with the new
          framework and the (slightly) more immutable nature of CDRs.
      
      There are a plethora of other changes. For a full description of CDR behavior,
      see the CDR specification on the Asterisk wiki.
      
      (closes issue ASTERISK-21196)
      
      Review: https://reviewboard.asterisk.org/r/2486/
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      6258bbe7
  18. May 21, 2013
  19. May 17, 2013
    • David M. Lee's avatar
      Fix shutdown assertions in stasis-core · b97c71bb
      David M. Lee authored
      In r388005, macros were introduced to consistently define message
      types. This added an assert if a message type was used either before
      it was initialized or after it had been cleaned up. It turns out that
      this assertion fires during shutdown.
      
      This actually exposed a hidden shutdown ordering problem. Since
      unsubscribing is asynchronous, it's possible that the message types
      used by the subscription could be freed before the final message of
      the subscription was processed.
      
      This patch adds stasis_subscription_join(), which blocks until the
      last message has been processed by the subscription. Since joining was
      most commonly done right after an unsubscribe, a
      stasis_unsubscribe_and_join() convenience function was also added.
      
      Similar functions were also added to the stasis_caching_topic and
      stasis_message_router, since they wrap subscriptions and have similar
      problems.
      
      Other code in trunk was refactored to join() where appropriate, or at
      least verify that the subscription was complete before being
      destroyed.
      
      Review: https://reviewboard.asterisk.org/r/2540
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389011 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      b97c71bb
  20. May 04, 2013
  21. Apr 16, 2013
  22. Apr 03, 2013
  23. Mar 20, 2013
  24. Feb 18, 2013
  25. Feb 15, 2013
  26. Jan 31, 2013
  27. Jan 22, 2013
    • Matthew Jordan's avatar
      Add ControlPlayback manager action · 7d9871b3
      Matthew Jordan authored
      This patch adds the capability for asynchronous manipulation of audio being
      played back to a channel though a new AMI action "ControlPlayback". The
      ControlPlayback action supports a number of operations, the availability of
      which depend on the application being used to send audio to the channel.
      When the audio playback was initiated using the ControlPlayback application
      or CONTROL STREAM FILE AGI command, the audio can be paused, stopped,
      restarted, reversed, or skipped forward. When initiated by other mechanisms
      (such as the Playback application), the audio can be stopped, reversed, or
      skipped forward.
      
      Review: https://reviewboard.asterisk.org/r/2265/
      
      (closes issue ASTERISK-20882)
      Reported by: mjordan
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@379830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      7d9871b3
  28. Jan 02, 2013
    • Automerge script's avatar
      Merged revisions 378374,378377,378384 via svnmerge from · b375abae
      Automerge script authored
      file:///srv/subversion/repos/asterisk/trunk
      
      ................
        r378374 | rmudgett | 2013-01-02 15:23:16 -0600 (Wed, 02 Jan 2013) | 33 lines
        
        Fix AMI redirect action with two channels failing to redirect both channels.
        
        The AMI redirect action can fail to redirect two channels that are bridged
        together.  There is a race between the AMI thread redirecting the two
        channels and the bridge thread noticing that a channel is hungup from the
        redirects.
        
        * Made the bridge wait for both channels to be redirected before exiting.
        
        * Made the AMI redirect check that all required headers are present before
        proceeding with the redirection.
        
        * Made the AMI redirect require that any supplied ExtraChannel exist
        before proceeding.  Previously the code fell back to a single channel
        redirect operation.
        
        (closes issue ASTERISK-18975)
        Reported by: Ben Klang
        
        (closes issue ASTERISK-19948)
        Reported by: Brent Dalgleish
        Patches:
              jira_asterisk_19948_v11.patch (license #5621) patch uploaded by rmudgett
        Tested by: rmudgett, Thomas Sevestre, Deepak Lohani, Kayode
        
        Review: https://reviewboard.asterisk.org/r/2243/
        ........
        
        Merged revisions 378356 from http://svn.asterisk.org/svn/asterisk/branches/1.8
        ........
        
        Merged revisions 378358 from http://svn.asterisk.org/svn/asterisk/branches/11
      ................
        r378377 | mjordan | 2013-01-02 16:10:32 -0600 (Wed, 02 Jan 2013) | 24 lines
        
        Prevent crashes from occurring when reading from data sources with large values
        
        When reading configuration data from an Asterisk .conf file or when pulling
        data from an Asterisk RealTime backend, Asterisk was copying the data on the
        stack for manipulation. Unfortunately, it is possible to read configuration
        data or realtime data from some data source that provides a large blob of
        characters. This could potentially cause a crash via a stack overflow.
        
        This patch prevents large sets of data from being read from an ARA backend or
        from an Asterisk conf file.
        
        (issue ASTERISK-20658)
        Reported by: wdoekes
        Tested by: wdoekes, mmichelson
        patches:
         * issueA20658_dont_process_overlong_config_lines.patch uploaded by wdoekes (license 5674)
         * issueA20658_func_realtime_limit.patch uploaded by wdoekes (license 5674)
        ........
        
        Merged revisions 378375 from http://svn.asterisk.org/svn/asterisk/branches/1.8
        ........
        
        Merged revisions 378376 from http://svn.asterisk.org/svn/asterisk/branches/11
      ................
        r378384 | mjordan | 2013-01-02 16:19:32 -0600 (Wed, 02 Jan 2013) | 11 lines
        
        Clean up app_mysql's application entry points to properly parse arguments
        
        When parsing arguments, application entry points should not attempt to
        directly modify the parameters to the function. This patch properly duplicates
        the passed in parameters before attempting to parse them.
        
        (issue ASTERISK-20658)
        Reported by: wdoekes
        patches:
          issueA20658_sanitize_app_mysql.patch uploaded by wdoekes (license 5674)
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/team/mmichelson/threadpool@378385 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      b375abae
    • Matthew Jordan's avatar
      Prevent crashes from occurring when reading from data sources with large values · 89f9e077
      Matthew Jordan authored
      When reading configuration data from an Asterisk .conf file or when pulling
      data from an Asterisk RealTime backend, Asterisk was copying the data on the
      stack for manipulation. Unfortunately, it is possible to read configuration
      data or realtime data from some data source that provides a large blob of
      characters. This could potentially cause a crash via a stack overflow.
      
      This patch prevents large sets of data from being read from an ARA backend or
      from an Asterisk conf file.
      
      (issue ASTERISK-20658)
      Reported by: wdoekes
      Tested by: wdoekes, mmichelson
      patches:
       * issueA20658_dont_process_overlong_config_lines.patch uploaded by wdoekes (license 5674)
       * issueA20658_func_realtime_limit.patch uploaded by wdoekes (license 5674)
      ........
      
      Merged revisions 378375 from http://svn.asterisk.org/svn/asterisk/branches/1.8
      ........
      
      Merged revisions 378376 from http://svn.asterisk.org/svn/asterisk/branches/11
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378377 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      89f9e077
    • Automerge script's avatar
      Merged revisions 378322 via svnmerge from · 675914bb
      Automerge script authored
      file:///srv/subversion/repos/asterisk/trunk
      
      ................
        r378322 | mjordan | 2013-01-02 12:11:59 -0600 (Wed, 02 Jan 2013) | 33 lines
        
        Prevent exhaustion of system resources through exploitation of event cache
        
        Asterisk maintains an internal cache for devices in the event subsystem. The
        device state cache holds the state of each device known to Asterisk, such that
        consumers of device state information can query for the last known state for
        a particular device, even if it is not part of an active call. The concept of
        a device in Asterisk can include entities that do not have a physical
        representation. One way that this occurred was when anonymous calls are allowed
        in Asterisk. A device was automatically created and stored in the cache for
        each anonymous call that occurred; this was possible in the SIP and IAX2
        channel drivers and through channel drivers that utilized the
        res_jabber/res_xmpp resource modules (Gtalk, Jingle, and Motif). These devices
        are never removed from the system, allowing anonymous calls to potentially
        exhaust a system's resources.
        
        This patch changes the event cache subsystem and device state management to
        no longer cache devices that are not associated with a physical entity.
        
        (issue ASTERISK-20175)
        Reported by: Russell Bryant, Leif Madsen, Joshua Colp
        Tested by: kmoore
        patches:
          event-cachability-3.diff uploaded by jcolp (license 5000)
        ........
        
        Merged revisions 378303 from http://svn.asterisk.org/svn/asterisk/branches/1.8
        ........
        
        Merged revisions 378320 from http://svn.asterisk.org/svn/asterisk/branches/10
        ........
        
        Merged revisions 378321 from http://svn.asterisk.org/svn/asterisk/branches/11
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/team/mmichelson/threadpool@378329 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      675914bb
    • Matthew Jordan's avatar
      Prevent exhaustion of system resources through exploitation of event cache · 8fb5bdce
      Matthew Jordan authored
      Asterisk maintains an internal cache for devices in the event subsystem. The
      device state cache holds the state of each device known to Asterisk, such that
      consumers of device state information can query for the last known state for
      a particular device, even if it is not part of an active call. The concept of
      a device in Asterisk can include entities that do not have a physical
      representation. One way that this occurred was when anonymous calls are allowed
      in Asterisk. A device was automatically created and stored in the cache for
      each anonymous call that occurred; this was possible in the SIP and IAX2
      channel drivers and through channel drivers that utilized the
      res_jabber/res_xmpp resource modules (Gtalk, Jingle, and Motif). These devices
      are never removed from the system, allowing anonymous calls to potentially
      exhaust a system's resources.
      
      This patch changes the event cache subsystem and device state management to
      no longer cache devices that are not associated with a physical entity.
      
      (issue ASTERISK-20175)
      Reported by: Russell Bryant, Leif Madsen, Joshua Colp
      Tested by: kmoore
      patches:
        event-cachability-3.diff uploaded by jcolp (license 5000)
      ........
      
      Merged revisions 378303 from http://svn.asterisk.org/svn/asterisk/branches/1.8
      ........
      
      Merged revisions 378320 from http://svn.asterisk.org/svn/asterisk/branches/10
      ........
      
      Merged revisions 378321 from http://svn.asterisk.org/svn/asterisk/branches/11
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378322 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      8fb5bdce
  29. Nov 30, 2012
Loading