Skip to content
Snippets Groups Projects
  1. Apr 12, 2017
    • George Joseph's avatar
      modules: change module LOAD_FAILUREs to LOAD_DECLINES · 747beb1e
      George Joseph authored
      In all non-pbx modules, AST_MODULE_LOAD_FAILURE has been changed
      to AST_MODULE_LOAD_DECLINE.  This prevents asterisk from exiting
      if a module can't be loaded.  If the user wishes to retain the
      FAILURE behavior for a specific module, they can use the "require"
      or "preload-require" keyword in modules.conf.
      
      A new API was added to logger: ast_is_logger_initialized().  This
      allows asterisk.c/check_init() to print to the error log once the
      logger subsystem is ready instead of just to stdout.  If something
      does fail before the logger is initialized, we now print to stderr
      instead of stdout.
      
      Change-Id: I5f4b50623d9b5a6cb7c5624a8c5c1274c13b2b25
      747beb1e
  2. Oct 27, 2016
    • Corey Farrell's avatar
      Remove ASTERISK_REGISTER_FILE. · a6e5bae3
      Corey Farrell authored
      ASTERISK_REGISTER_FILE no longer has any purpose so this commit removes
      all traces of it.
      
      Previously exported symbols removed:
      * __ast_register_file
      * __ast_unregister_file
      * ast_complete_source_filename
      
      This also removes the mtx_prof static variable that was declared when
      MTX_PROFILE was enabled.  This variable was only used in lock.c so it
      is now initialized in that file only.
      
      ASTERISK-26480 #close
      
      Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966
      a6e5bae3
  3. Jun 08, 2016
    • Timo Teräs's avatar
      Fixes to include signal.h · 39b69ab5
      Timo Teräs authored
      POSIX defines signal.h. sys/signal.h should not be used as it is
      c-library internal header which may or may not exist. Notably with
      musl it generates warning of being incorrect.
      
      Change-Id: Ia56b0aa1d84b5c590114867b1b384a624f39a6fc
      39b69ab5
  4. Nov 09, 2015
  5. Aug 19, 2015
    • Richard Mudgett's avatar
      rtp_engine.c: Initial split of payload types into rx and tx mappings. · 1a549ed1
      Richard Mudgett authored
      There are numerous problems with the current implementation of the RTP
      payload type mapping in Asterisk.  It uses only one mapping structure to
      associate payload types to codecs.  The single mapping is overkill if all
      of the payload type values are well known values.  Dynamic payload type
      mappings do not work as well with the single mapping because RFC3264
      allows each side of the link to negotiate different dynamic mappings for
      what they want to receive.  Not only could you have the same codec mapped
      for sending and receiving on different payload types you could wind up
      with the same payload type mapped to different codecs for each direction.
      
      1) An independent payload type mapping is needed for sending and
      receiving.
      
      2) The receive mapping needs to keep track of previous mappings because of
      the slack to when negotiation happens and current packets in flight using
      the old mapping arrive.
      
      3) The transmit mapping only needs to keep track of the current negotiated
      values since we are sending the packets and know when the switchover takes
      place.
      
      * Needed to create ast_rtp_codecs_payload_code_tx() and make some callers
      use the new function because ast_rtp_codecs_payload_code() was used for
      mappings in both directions.
      
      * Needed to create ast_rtp_codecs_payloads_xover() for cases where we need
      to pass preferred codec mappings to the peer channel for early media
      bridging or when we need to prefer the offered mapping that RFC3264 says
      we SHOULD use.
      
      * ast_rtp_codecs_payloads_xover() and ast_rtp_codecs_payload_code_tx() are
      the only new public functions created.  All the others were only used for
      the tx or rx mapping direction so the function doxygen now reflects which
      direction the function operates.
      
      * chan_mgcp.c: Removed call to ast_rtp_codecs_payloads_clear() as doing
      that makes no sense when processing an incoming SDP.  We would be wiping
      out any mappings that we set for the possible outgoing SDP we sent
      earlier.
      
      ASTERISK-25166
      Reported by: Kevin Harwell
      
      ASTERISK-17410
      Reported by: Boris Fox
      
      Change-Id: Iaf6c227bca68cb7c414cf2fd4108a8ac98bd45ac
      1a549ed1
  6. Jul 02, 2015
  7. May 23, 2015
    • Corey Farrell's avatar
      Stasis: Fix unsafe use of stasis_unsubscribe in modules. · 50044fdc
      Corey Farrell authored
      Many uses of stasis_unsubscribe in modules can be reached through unload.
      These have been switched to stasis_unsubscribe_and_join.
      
      Some subscription callbacks do nothing, for these I've created a noop
      callback function in stasis.c.  This is used by some modules that monitor
      MWI topics in order to enable cache, since the callback does not become
      invalid after dlclose it is safe to use stasis_unsubscribe on these, even
      during module unload.
      
      ASTERISK-25121 #close
      
      Change-Id: Ifc2549fbd8eef7d703c222978e8f452e2972189c
      50044fdc
  8. May 13, 2015
  9. Apr 30, 2015
    • Mark Michelson's avatar
      Restrict functionality when ACLs are misconfigured. · 11ffcf66
      Mark Michelson authored
      This patch has two main purposes:
      
      1) Improve warning messages when ACLs are configured improperly.
      2) Prevent misconfigured ACLs from allowing potentially unwanted
      traffic.
      
      To acomplish point (2) in most cases, whatever configuration object that
      the ACL belonged to was not allowed to load.
      
      The one exception is res_pjsip_acl. In that case, ACLs are their own
      configuration object. Furthermore, the module loading code has no
      indication that a ACL configuration had a failure. So the tactic taken
      here is to create an ACL that just blocks everything.
      
      ASTERISK-24969
      Reported by Corey Farrell
      
      Change-Id: I2ebcb6959cefad03cea4d81401be946203fcacae
      11ffcf66
  10. Apr 13, 2015
    • Matt Jordan's avatar
      git migration: Refactor the ASTERISK_FILE_VERSION macro · 4a582616
      Matt Jordan authored
      Git does not support the ability to replace a token with a version
      string during check-in. While it does have support for replacing a
      token on clone, this is somewhat sub-optimal: the token is replaced
      with the object hash, which is not particularly easy for human
      consumption. What's more, in practice, the source file version was often
      not terribly useful. Generally, when triaging bugs, the overall version
      of Asterisk is far more useful than an individual SVN version of a file. As a
      result, this patch removes Asterisk's support for showing source file
      versions.
      
      Specifically, it does the following:
      
      * Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and
        remove passing the version in with the macro. Other facilities
        than 'core show file version' make use of the file names, such as
        setting a debug level only on a specific file. As such, the act of
        registering source files with the Asterisk core still has use. The
        macro rename now reflects the new macro purpose.
      
      * main/asterisk:
        - Refactor the file_version structure to reflect that it no longer
          tracks a version field.
        - Remove the "core show file version" CLI command. Without the file
          version, it is no longer useful.
        - Remove the ast_file_version_find function. The file version is no
          longer tracked.
        - Rename ast_register_file_version/ast_unregister_file_version to
          ast_register_file/ast_unregister_file, respectively.
      
      * main/manager: Remove value from the Version key of the ModuleCheck
        Action. The actual key itself has not been removed, as doing so would
        absolutely constitute a backwards incompatible change. However, since
        the file version is no longer tracked, there is no need to attempt to
        include it in the Version key.
      
      * UPGRADE: Add notes for:
        - Modification to the ModuleCheck AMI Action
        - Removal of the "core show file version" CLI command
      
      Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e
      4a582616
  11. Dec 01, 2014
    • Matthew Jordan's avatar
      main/stasis: Allow subscriptions to use a threadpool for message delivery · 1106e8fd
      Matthew Jordan authored
      Prior to this patch, all Stasis subscriptions would receive a dedicated
      thread for servicing published messages. In contrast, prior to r400178
      (see review https://reviewboard.asterisk.org/r/2881/), the subscriptions
      shared a thread pool. It was discovered during some initial work on Stasis
      that, for a low subscription count with high message throughput, the
      threadpool was not as performant as simply having a dedicated thread per
      subscriber.
      
      For situations where a subscriber receives a substantial number of messages
      and is always present, the model of having a dedicated thread per subscriber
      makes sense. While we still have plenty of subscriptions that would follow
      this model, e.g., AMI, CDRs, CEL, etc., there are plenty that also fall into
      the following two categories:
      * Large number of subscriptions, specifically those tied to endpoints/peers.
      * Low number of messages. Some subscriptions exist specifically to coordinate
        a single message - the subscription is created, a message is published, the
        delivery is synchronized, and the subscription is destroyed.
      In both of the latter two cases, creating a dedicated thread is wasteful (and
      in the case of a large number of peers/endpoints, harmful). In those cases,
      having shared delivery threads is far more performant.
      
      This patch adds the ability of a subscriber to Stasis to choose whether or not
      their messages are dispatched on a dedicated thread or on a threadpool. The
      threadpool is configurable through stasis.conf.
      
      Review: https://reviewboard.asterisk.org/r/4193
      
      ASTERISK-24533 #close
      Reported by: xrobau
      Tested by: xrobau
      ........
      
      Merged revisions 428681 from http://svn.asterisk.org/svn/asterisk/branches/12
      ........
      
      Merged revisions 428687 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      1106e8fd
  12. Nov 09, 2014
  13. Sep 26, 2014
  14. Jul 25, 2014
  15. Jul 20, 2014
  16. May 22, 2014
  17. May 09, 2014
  18. Mar 07, 2014
    • Scott Griepentrog's avatar
      uniqueid: channel linkedid, ami, ari object creation with id's · 80ef9a21
      Scott Griepentrog authored
      Much needed was a way to assign id to objects on creation, and
      much change was necessary to accomplish it.  Channel uniqueids
      and linkedids are split into separate string and creation time
      components without breaking linkedid propgation.  This allowed
      the uniqueid to be specified by the user interface - and those
      values are now carried through to channel creation, adding the
      assignedids value to every function in the chain including the
      channel drivers. For local channels, the second channel can be
      specified or left to default to a ;2 suffix of first.  In ARI,
      bridge, playback, and snoop objects can also be created with a
      specified uniqueid.
      
      Along the way, the args order to allocating channels was fixed
      in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
      masquerade occurs.
      
      (closes issue ASTERISK-23120)
      Review: https://reviewboard.asterisk.org/r/3191/
      ........
      
      Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      80ef9a21
  19. Jan 21, 2014
  20. Dec 19, 2013
    • Richard Mudgett's avatar
      Voicemail: Remove mailbox identifier format (box@context) assumptions in the system. · e4803bbd
      Richard Mudgett authored
      This change is in preparation for external MWI support.
      
      Removed code from the system for normal mailbox handling that appends
      @default to the mailbox identifier if it does not have a context.  The
      only exception is the legacy hasvoicemail users.conf option.  The legacy
      option will only work for app_voicemail mailboxes.  The system cannot make
      any assumptions about the format of the mailbox identifer used by
      app_voicemail.
      
      chan_sip and chan_dahdi/sig_pri had the most changes because they both
      tried to interpret the mailbox identifier.  chan_sip just stored and
      compared the two components.  chan_dahdi actually used the box
      information.
      
      The ISDN MWI support configuration options had to be reworked because
      chan_dahdi was parsing the box@context format to get the box number.  As a
      result the mwi_vm_boxes chan_dahdi.conf option was added and is documented
      in the chan_dahdi.conf.sample file.
      
      Review: https://reviewboard.asterisk.org/r/3072/
      ........
      
      Merged revisions 404348 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404350 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      e4803bbd
  21. Dec 18, 2013
  22. Dec 05, 2013
  23. Dec 03, 2013
  24. Oct 23, 2013
  25. Oct 03, 2013
  26. Oct 02, 2013
  27. Sep 30, 2013
    • 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
  28. Aug 18, 2013
  29. 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
  30. Aug 02, 2013
  31. Aug 01, 2013
    • Matthew Jordan's avatar
      Support externally initiated parking requests; remove some dead code · 5c4b4824
      Matthew Jordan authored
      This patch does the following:
       * It adds support for externally initiated parking requests. In particular,
         chan_skinny has a protocol level message that initiates a call park.
         This patch now supports that option, as well as the protocol specific
         mechanisms in chan_dahdi/sig_analog and chan_mgcp.
       * A parking bridge features virtual table has been added that provides
         access to the parking functionality that the Bridging API needs. This
         includes requests to park an entire 'call' (with little or no additional
         information, thank you chan_skinny), perform a blind transfer to a parking
         extension, determine if an extension is a parking extension, as well as the
         actual "do the parking" request from the Bridging API.
       * Refactoring in chan_mgcp, chan_skinny, and chan_dahdi to make use of the new
         functions
       * The removal of some - but not all - dead parking code from features.c
      
      This also fixed blind transferring a multi-party bridge to a parking lot (which
      was implemented, but had at least one code path where using the parking features
      kK might not have worked)
      
      Review: https://reviewboard.asterisk.org/r/2710
      
      (closes issue ASTERISK-22134)
      Reported by: Matt Jordan
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      5c4b4824
    • David M. Lee's avatar
      Split caching out from the stasis_caching_topic. · e1b959cc
      David M. Lee authored
      In working with res_stasis, I discovered a significant limitation to
      the current structure of stasis_caching_topics: you cannot subscribe
      to cache updates for a single channel/bridge/endpoint/etc.
      
      To address this, this patch splits the cache away from the
      stasis_caching_topic, making it a first class object. The stasis_cache
      object is shared amongst individual stasis_caching_topics that are
      created per channel/endpoint/etc. These are still forwarded to global
      whatever_all_cached topics, so their use from most of the code does
      not change.
      
      In making these changes, I noticed that we frequently used a similar
      pattern for bridges, endpoints and channels:
      
           single_topic  ---------------->  all_topic
                 ^
                 |
           single_topic_cached  ----+---->  all_topic_cached
                                    |
                                    +---->  cache
      
      This pattern was extracted as the 'Stasis Caching Pattern', defined in
      stasis_caching_pattern.h. This avoids a lot of duplicate code between
      the different domain objects.
      
      Since the cache is now disassociated from its upstream caching topics,
      this also necessitated a change to how the 'guaranteed' flag worked
      for retrieving from a cache. The code for handling the caching
      guarantee was extracted into a 'stasis_topic_wait' function, which
      works for any stasis_topic.
      
      (closes issue ASTERISK-22002)
      Review: https://reviewboard.asterisk.org/r/2672/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395954 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      e1b959cc
  32. Jul 25, 2013
    • Matthew Jordan's avatar
      A great big renaming patch · cafc1158
      Matthew Jordan authored
      This patch renames the bridging* files to bridge*. This may seem pedantic
      and silly, but it fits better in line with current Asterisk naming conventions:
      * channel is not "channeling"
      * monitor is not "monitoring"
      etc.
      
      A bridge is an object. It is a first class citizen in Asterisk. "Bridging" is
      the act of using a bridge on a set of channels - and the API that fulfills that
      role is more than just the action.
      
      (closes issue ASTERISK-22130)
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      cafc1158
  33. Jul 23, 2013
    • Richard Mudgett's avatar
      Some chan_dahdi protected function renaming. · b4dd4ffb
      Richard Mudgett authored
      analog_lib_handles --> dahdi_analog_lib_handles
      enable_dtmf_detect --> dahdi_dtmf_detect_enable
      disable_dtmf_detect --> dahdi_dtmf_detect_disable
      dahdi_enable_ec --> dahdi_ec_enable
      dahdi_disable_ec --> dahdi_ec_disable
      update_conf --> dahdi_conf_update
      dahdi_link --> dahdi_master_slave_link
      dahdi_unlink --> dahdi_master_slave_unlink
      
      (closes issue ASTERISK-22129)
      Reported by: rmudgett
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395167 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      b4dd4ffb
  34. Jul 05, 2013
    • Matthew Jordan's avatar
      Refactor RTCP events over to Stasis; associate with channels · d0a55fa5
      Matthew Jordan authored
      This patch does the following:
      
      * It merges Jaco Kroon's patch from ASTERISK-20754, which provides channel
        information in the RTCP events. Because Stasis provides a cache, Jaco's
        patch was modified to pass the channel uniqueid to the RTP layer as
        opposed to a pointer to the channel. This has the following benefits:
        (1) It keeps the RTP engine 'clean' of references back to channels
        (2) It prevents circular dependencies and other potential ref counting issues
      * The RTP engine now allows any RTP implementation to raise RTCP messages.
        Potentially, other implementations (such as res_rtp_multicast) could also
        raise RTCP information. The engine provides structs to represent RTCP headers
        and RTCP SR/RR reports.
      * Some general refactoring in res_rtp_asterisk was done to try and tame the
        RTCP code. It isn't perfect - that's *way* beyond the scope of this work -
        but it does feel marginally better.
      * A few random bugs were fixed in the RTCP statistics. (Example: performing an
        assignment of a = a is probably not correct)
      * We now raise RTCP events for each SR/RR sent/received. Previously we wouldn't
        raise an event when we sent a RR report.
      
      Note that this work will be of use to others who want to monitor call quality
      or build modules that report call quality statistics. Since the events are now
      moving across the Stasis message bus, this is far easier to accomplish. It is
      also a first step (though by no means the last step) towards getting Olle's
      pinefrog work incorporated.
      
      Again: note that the patch by Jaco Kroon was modified slightly for this work;
      however, he did all of the hard work in finding the right places to set the
      channel in the RTP engine across the channel drivers. Much thanks goes to Jaco
      for his hard work here.
      
      Review: https://reviewboard.asterisk.org/r/2603/
      
      (closes issue ASTERISK-20574)
      Reported by: Jaco Kroon
      patches:
        asterisk-rtcp-channel.patch uploaded by jkroon (License 5671)
      
      (closes issue ASTERISK-21471)
      Reported by: Matt Jordan
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393740 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      d0a55fa5
  35. Jun 17, 2013
    • 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
  36. Jun 06, 2013
    • Mark Michelson's avatar
      Refactor the features configuration scheme. · 2dc8a060
      Mark Michelson authored
      Features configuration is handled in its own API in
      features_config.h and features_config.c. This way, features
      configuration is accessible to anything that needs it.
      
      In addition, features configuration has been altered to
      be more channel-oriented. Most callers of features API
      code will be supplying a channel so that the individual
      channel's settings will be acquired rather than the global
      setting.
      
      Missing from this commit is XML documentation for the
      features configuration. That will be handled in a separate
      commit.
      
      Review: https://reviewboard.asterisk.org/r/2578/
      
      (issue ASTERISK-21542)
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390751 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      2dc8a060
  37. May 28, 2013
Loading