Skip to content
Snippets Groups Projects
  1. May 05, 2015
    • Corey Farrell's avatar
      Modules: Make ast_module_info->self available to auxiliary sources. · a8bfa9e1
      Corey Farrell authored
      ast_module_info->self is often needed to register items with the core.  Many
      modules have ad-hoc code to make this pointer available to auxiliary sources.
      This change updates the module build process to make the needed information
      available to all sources in a module.
      
      ASTERISK-25056 #close
      Reported by: Corey Farrell
      
      Change-Id: I18c8cd58fbcb1b708425f6757becaeca9fa91815
      a8bfa9e1
  2. Apr 30, 2015
    • Richard Mudgett's avatar
      chan_dahdi: Add the chan_dahdi.conf force_restart_unavailable_chans option. · 03c51cf5
      Richard Mudgett authored
      Some telco switches occasionally ignore ISDN RESTART requests.  The fix
      for ASTERISK-19608 added an escape clause for B channels in the restarting
      state if the telco ignores a RESTART request.  If the telco fails to
      acknowledge the RESTART then Asterisk will assume the telco acknowledged
      the RESTART on the second call attempt requesting the B channel by the
      telco.  The escape clause is good for dealing with RESTART requests in
      general but it does cause the next call for the restarting B channel to be
      rejected if the telco insists the call must go on that B channel.
      
      chan_dahdi doesn't really need to issue a RESTART request in response to
      receiving a cause 44 (Requested channel not available) code.  Sending the
      RESTART in such a situation is not required (nor prohibited) by the
      standards.  I think chan_dahdi does this for historical reasons to deal
      with buggy peers to get channels unstuck in a similar fashion as the
      chan_dahdi.conf resetinterval option.
      
      * Add the chan_dahdi.conf force_restart_unavailable_chans compatability
      option that when disabled will prevent chan_dahdi from trying to RESTART
      the channel in response to a cause 44 code.
      
      ASTERISK-25034 #close
      Reported by: Richard Mudgett
      
      Change-Id: Ib8b17a438799920f4a2038826ff99a1884042f65
      03c51cf5
  3. 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
  4. Mar 13, 2015
  5. Mar 06, 2015
    • Richard Mudgett's avatar
      chan_dahdi/sig_analog: Fix distinctive ring detection to suck less. · c7cc1b30
      Richard Mudgett authored
      The distinctive ring feature interferes with detecting Caller ID and
      appears to have been broken for years.  What happens is if you have a
      ring-ring cadence as used in the UK you get too many DAHDI events for the
      distinctive ring pattern array and Caller ID detection is aborted.  I
      think when Zapata/DAHDI added the ring begin event it broke distinctive
      ring.  More events happen than before and the code does no filtering of
      which event times are recorded in the pattern array.
      
      * Made distinctive ring only record the ringt count when the ring ends
      instead of on just any DAHDI event.  Distinctive ring can be ring,
      ring-ring, ring-ring-ring, or different ring durations for the up to three
      rings.
      
      * Fixed the distinctive ring detection enable (chan_dahdi.conf option
      usedistinctiveringdetection) to be per port instead of somewhat per port
      and somewhat global.  This has been broken since v1.8.
      
      * Fixed using the default distinctive ring context when the detected
      pattern does not match any configured dringX patterns.  The default
      context did not get set when the previous call was a matched distinctive
      ring pattern and the current call is not matched.  This has been broken
      since v1.8.
      
      * Made distinctive ring have no effect on Caller ID detection when it is
      disabled.  Caller ID detection just monitors for 10 seconds before giving
      up.
      
      * Fixed leak of struct callerid_state memory when a polarity reversal
      during Caller ID detection causes the incoming call to be aborted.
      
      DAHDI-1143
      AST-1545
      ASTERISK-24825 #close
      Reported by: Richard Mudgett
      
      ASTERISK-17588
      Reported by: Daniel Flounders
      
      Review: https://reviewboard.asterisk.org/r/4444/
      ........
      
      Merged revisions 432530 from http://svn.asterisk.org/svn/asterisk/branches/11
      ........
      
      Merged revisions 432534 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432551 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      c7cc1b30
  6. Feb 19, 2015
  7. Jan 12, 2015
  8. Jan 09, 2015
    • Richard Mudgett's avatar
      AMI: Remove no longer used parameter from astman_send_listack(). · ef34a05f
      Richard Mudgett authored
      Follow-up issue to -r430435 from reviewboard review.
      
      ASTERISK-24049
      Review: https://reviewboard.asterisk.org/r/4315/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430452 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      ef34a05f
    • Richard Mudgett's avatar
      AMI: Make AMI actions that generate event lists consistent. · 52a7cdb1
      Richard Mudgett authored
      * Made the following AMI actions use list API calls for consistency:
      Agents
      BridgeInfo
      BridgeList
      BridgeTechnologyList
      ConfbridgeLIst
      ConfbridgeLIstRooms
      CoreShowChannels
      DAHDIShowChannels
      DBGet
      DeviceStateList
      ExtensionStateList
      FAXSessions
      Hangup
      IAXpeerlist
      IAXpeers
      IAXregistry
      MeetmeList
      MeetmeListRooms
      MWIGet
      ParkedCalls
      Parkinglots
      PJSIPShowEndpoint
      PJSIPShowEndpoints
      PJSIPShowRegistrationsInbound
      PJSIPShowRegistrationsOutbound
      PJSIPShowResourceLists
      PJSIPShowSubscriptionsInbound
      PJSIPShowSubscriptionsOutbound
      PresenceStateList
      PRIShowSpans
      QueueStatus
      QueueSummary
      ShowDialPlan
      SIPpeers
      SIPpeerstatus
      SIPshowregistry
      SKINNYdevices
      SKINNYlines
      Status
      VoicemailUsersList
      
      * Incremented the AMI version to 2.7.0.
      
      * Changed astman_send_listack() to not use the listflag parameter and
      always set the value to "Start" so the start capitalization is consistent.
      i.e., The FAXSessions used "Start" while the rest of the system used
      "start".  The corresponding complete event always used "Complete".
      
      * Fixed ami_show_resource_lists() "PJSIPShowResourceLists" to output the
      AMI ActionID for all of its list events.
      
      * Fixed off-nominal AMI protocol error in manager_bridge_info(),
      manager_parking_status_single_lot(), and
      manager_parking_status_all_lots().  Use of astman_send_error() after
      responding to the original AMI action request violates the action response
      pattern by sending two responses.
      
      * Fixed minor protocol error in action_getconfig() when no requested
      categories are found.  Each line needs to be formatted as "Header: text".
      
      * Fixed off-nominal memory leak in manager_build_parked_call_string().
      
      * Eliminated unnecessary use of RAII_VAR() in ami_subscription_detail().
      
      ASTERISK-24049 #close
      Reported by: Jonathan Rose
      
      Review: https://reviewboard.asterisk.org/r/4315/
      ........
      
      Merged revisions 430434 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      52a7cdb1
  9. Dec 19, 2014
  10. Dec 18, 2014
  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. Jul 25, 2014
  13. Jul 21, 2014
  14. Jul 20, 2014
  15. Jul 03, 2014
  16. Jun 23, 2014
    • Tzafrir Cohen's avatar
      suspended destructions of pri spans on events · 3451d6a7
      Tzafrir Cohen authored
      If a DAHDI span disappears, we wish for its representation in Asterisk
      to be destroyed as well.
      
      The information about the span's removal may come from several paths:
      
      1. DAHDI sends DAHDI_EVENT_REMOVE on every channel.
      2. An extra DAHDI_EVENT_REMOVED is sent on every subsequent call to
         DAHDI_GET_EVENT.
      3. Every read (including the internal one by libpri on the D-channel)
         returns -ENODEV.
      
      Asterisk responsds to DAHDI_EVENT_REMOVE on a channel by destroying it.
      
      Destroying a channel requires holding the channel list lock (iflock).
      Destroying a channel that is part of a span requires holding the span's
      lock. Destroying a channel from a context that holds the span lock,
      while at the same time another channel is destroyed directly, leads to a
      deadlock. Solution: don't destroy span while holding the channels list
      lock.
      
      Thus changes in this patch:
      * Deferring removal of PRI spans in response to events: doomed spans
        are collected on a list.
      * Doomed spans are removed periodically by the monitor thread.
      * ENODEV reads from the D-channel will warant the same deferred removal.
      
      Review: https://reviewboard.asterisk.org/r/3548/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417059 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      3451d6a7
  17. Jun 16, 2014
    • Richard Mudgett's avatar
      chan_dahdi: Adds support for major update to libss7. · 0c896d8b
      Richard Mudgett authored
      * SS7 support now requires libss7 v2.0 or later.  The new libss7 is not
      backwards compatible.
      
      * Added SS7 support for connected line and redirecting.
      
      * Most SS7 CLI commands are reworked as well as new SS7 commands added.
      See online CLI help.
      
      * Added several SS7 config option parameters described in
      chan_dahdi.conf.sample.
      
      * ISUP timer support reworked and now requires explicit configuration.
      See ss7.timers.sample.
      
      Special thanks to Kaloyan Kovachev for his support and persistence in
      getting the original patch by adomjan updated and ready for release.
      
      SS7-27 #close
      Reported by: adomjan
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416416 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      0c896d8b
  18. May 22, 2014
  19. May 16, 2014
  20. May 09, 2014
  21. Mar 07, 2014
  22. Jan 09, 2014
  23. Jan 03, 2014
  24. Dec 23, 2013
  25. 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
  26. Dec 18, 2013
  27. Dec 05, 2013
  28. Dec 03, 2013
  29. Nov 12, 2013
  30. Oct 24, 2013
  31. Oct 14, 2013
  32. Oct 03, 2013
  33. Oct 02, 2013
  34. Oct 01, 2013
  35. 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
Loading