Skip to content
Snippets Groups Projects
  1. Jul 20, 2014
  2. Jul 18, 2014
  3. Jun 08, 2014
  4. Jun 01, 2014
  5. May 28, 2014
    • Matthew Jordan's avatar
      Logger/CLI/etc.: Fix some aesthetic issues; reduce chatty verbose messages · fb5690ce
      Matthew Jordan authored
      This patch addresses some aesthetic issues in Asterisk. These are all just
      minor tweaks to improve the look of the CLI when used in a variety of
      settings. Specifically:
       * A number of chatty verbose messages were removed or demoted to DEBUG
         messages. Verbose messages with a verbosity level of 5 or higher were -
         if kept as verbose messages - demoted to level 4. Several messages
         that were emitted at verbose level 3 were demoted to 4, as announcement
         of dialplan applications being executed occur at level 3 (and so the
         effects of those applications should generally be less).
       * Some verbose messages that only appear when their respective 'debug'
         options are enabled were bumped up to always be displayed.
       * Prefix/timestamping of verbose messages were moved to the verboser
         handlers. This was done to prevent duplication of prefixes when the
         timestamp option (-T) is used with the CLI.
       * Verbose magic is removed from messages before being emitted to
         non-verboser handlers. This prevents the magic in multi-line verbose
         messages (such as SIP debug traces or the output of DumpChan) from
         being written to files.
       * _Slightly_ better support for the "light background" option (-W) was
         added. This includes using ast_term_quit in the output of XML
         documentation help, as well as changing the "Asterisk Ready" prompt to
         bright green on the default background (which stands a better chance of
         being displayed properly than bright white).
      
      Review: https://reviewboard.asterisk.org/r/3547/
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414798 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      fb5690ce
  6. May 19, 2014
  7. May 18, 2014
    • Matthew Jordan's avatar
      bridge_native_rtp/bridge_channel: Fix direct media issues due to frame hook · 17ff4d92
      Matthew Jordan authored
      This patch fixes issues with direct media bridges that occur after a blind
      transfer. These issues were caught by the (currently failing)
      pjsip/transfers/blind_transfer/caller_direct_media test.
      
      The test currently fails primarily for two reasons:
      (1) When Bob and Charlie (the transfer target and the transfer destination)
          enter a bridge together, the framehook remains on the transfer target
          channel until both channels are in the bridge. As it consumes voice frames,
          the initial bridge type is a simple bridge. The framehook is removed when
          both channels are in the bridge; however, this does not currently cause the
          bridging framework to re-evaluate the bridge. This patch adds a
          AST_SOFTHANGUP_UNBRIDGE poke to the transfer target channel when a
          framehook is removed so the bridge can re-evaluate itself.
      
      (2) When a channel leaves a native RTP bridge, it may be leaving due to being
          hung up. Sending a re-INVITE to a channel that is about to be hung up is
          not nice - in fact, there's a good chance we'll send the BYE request before
          the channel has had a chance to send back a 200 OK. To be somewhat nicer,
          this patch adds a function to channel.h that allows the bridging framework
          to query for exactly why a channel is leaving a bridge via the channel's
          soft hangup flags. This allows it to only send the re-INVITE if there's a
          chance the channel will survive the native bridging experience.
      
      Review: https://reviewboard.asterisk.org/r/3535/
      ........
      
      Merged revisions 414122 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414123 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      17ff4d92
  8. May 11, 2014
  9. May 10, 2014
  10. May 09, 2014
  11. Apr 15, 2014
  12. Mar 17, 2014
    • Mark Michelson's avatar
      Fix stuck channel in ARI through the introduction of synchronous bridge actions. · d44aefee
      Mark Michelson authored
      Playing back a file to a channel in an ARI bridge would attempt to wait until
      the playback concluded before returning. The method used involved signaling the
      waiting thread in the ARI custom playback function.
      
      The problem with this is that there were some corner cases that were not accounted for:
      * If a bridge channel could not be found, then we never would attempt the playback but
        would still attempt to wait for the playback to complete.
      * If the bridge playfile action failed to queue, we would still attempt to wait for the
        playback to complete.
      * If the bridge playfile action were queued but some circumstance caused the playback
        not to occur (the bridge dies, the channel is removed from the bridge), then we would
        never be notified.
      
      The solution to this is to move the waiting logic into the bridge code. A new bridge
      API function is added to queue a synchronous action on a bridge. The waiting thread
      is notified when the queued frame has been freed, either due to an error occurring
      or due to successful playback. As a failsafe, the waiting thread has a 10 minute
      timeout just in case there is a frame leak somewhere.
      
      Review: https://reviewboard.asterisk.org/r/3338
      ........
      
      Merged revisions 410673 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410684 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      d44aefee
  13. Mar 05, 2014
  14. Dec 13, 2013
  15. Oct 29, 2013
  16. Oct 11, 2013
    • Richard Mudgett's avatar
      Softmix: Fix crash when switching from softmix to another bridge technology. · 0ddcee5a
      Richard Mudgett authored
      The crash is caused by a race condition when switching between native RTP
      and softmix bridging technologies.  In this situation, the bridging
      technology is switched from native RTP to softmix, and then back to native
      RTP fast enough that the softmix private data gets destroyed before the
      softmix mixing thread gets started.
      
      Thanks to Kinsey Moore for the crash analysis.
      
      * Fix race condition when starting the softmix mixing thread and switching
      to another bridge technology.
      
      (closes issue ASTERISK-22678)
      Reported by: John Bigelow
      Patches:
            jira_asterisk_22678_v12.patch (license #5621) patch uploaded by rmudgett
      Tested by: John Bigelow
      ........
      
      Merged revisions 400849 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400850 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      0ddcee5a
  17. Oct 03, 2013
  18. Sep 27, 2013
  19. Sep 18, 2013
  20. Aug 23, 2013
  21. Aug 22, 2013
  22. Aug 21, 2013
    • Richard Mudgett's avatar
      Fix several interrelated issues dealing with the holding bridge technology. · d213dfa3
      Richard Mudgett authored
      * Added an option flags parameter to interval hooks.  Interval hooks now
      can specify if the callback will affect the media path or not.
      
      * Added an option flags parameter to the bridge action custom callback.
      The action callback now can specify if the callback will affect the media
      path or not.
      
      * Made the holding bridge technology reexamine the participant idle mode
      option whenever the entertainment is restarted.
      
      * Fixed app_agent_pool waiting agents needlessly starting and stopping MOH
      every second by specifying the heartbeat interval hook as not affecting
      the media path.
      
      * Fixed app_agent_pool agent alert from restarting the MOH after the alert
      beep.  The agent entertainment is now changed from MOH to silence after
      the alert beep.
      
      * Fixed holding bridge technology to defer starting the entertainment.  It
      was previously a mixture of immediate and deferred.
      
      * Fixed holding bridge technology to immediately stop the entertainment.
      It was previously a mixture of immediate and deferred.  If the channel
      left the bridging system, any deferred stopping was discarded before
      taking effect.
      
      * Miscellaneous holding bridge technology rework coding improvements.
      
      Review: https://reviewboard.asterisk.org/r/2761/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397294 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      d213dfa3
  23. Aug 15, 2013
  24. Aug 09, 2013
  25. Aug 05, 2013
    • Jonathan Rose's avatar
      bridge_holding: Add suspsend/unsuspend callbacks · 2d87fc77
      Jonathan Rose authored
      Suspend and unsuspend callbacks are added to the holding bridge so
      that entertainment can be disabled and re-enabled when operations
      would suspend a channel on the bridge (such as playback operations).
      This fixes entertainment so that when those operations end, the
      entertainment can pick back up and it also serves as an optimization.
      Also, this patch fixes a bug caused by triggering ringing frames
      immediately instead of pushing them to the queue which created a race
      condition where sometimes parking with ringing during attended
      transfers would cause the ringing to be interrupted by an unhold
      frame.
      
      (closes issue ASTERISK-22006)
      Reported by: Matt Jordan
      Review: https://reviewboard.asterisk.org/r/2711/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396189 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      2d87fc77
  26. Jul 31, 2013
  27. Jul 26, 2013
    • Richard Mudgett's avatar
      Remove the unsafe bridge parameter from ast_bridge_hook_callback's. · c017d5e6
      Richard Mudgett authored
      Most hook callbacks did not need the bridge parameter.  The pointer value
      could become invalid if the channel is moved to another bridge while it is
      executing.
      
      * Fixed some issues in feature_attended_transfer() as a result.
      
      * Reduce the bridge inhibit count in
      attended_transfer_properties_shutdown() after it has restored the bridge
      channel hooks.
      
      * Removed basic bridge requirement on feature_blind_transfer().  It does
      not require the basic bridge like feature_attended_transfer().
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395574 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      c017d5e6
    • Richard Mudgett's avatar
      Improved feature limits interval hook implementaion. · 50aba6be
      Richard Mudgett authored
      * Fixed feature limits to not use special members of struct
      ast_bridge_features.
      
      * Fixed memory leak in off nominal paths of bridge_builtin_set_limits().
      
      * Fixed off nominal path in ast_bridge_features_limits_construct() freeing
      unallocated memory if it was not called by bridge_builtin_set_limits().
      
      * Made bridge_builtin_interval_features.so unloadable.
      
      * Simplified parking's use of its duration interval hook.
      
      * Made BridgeWait S option not depend upon another module being loaded.
      
      (closes issue ASTERISK-22107)
      Reported by: Matt Jordan
      
      Review: https://reviewboard.asterisk.org/r/2701/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      50aba6be
  28. Jul 25, 2013
  29. Jul 24, 2013
  30. Jul 23, 2013
Loading