Skip to content
Snippets Groups Projects
  1. Oct 03, 2014
  2. Sep 26, 2014
  3. Sep 09, 2014
  4. Sep 05, 2014
    • Richard Mudgett's avatar
      func_channel.c: Add missing locking to some CHANNEL() requests. · 025bd1bf
      Richard Mudgett authored
      * The CHANNEL() audionativeformat, videonativeformat, audioreadformat, and
      audiowriteformat now need locking since the media format rework when
      accessing the channel's format pointers.
      
      * Increased the buffer size for CHANNEL() audionativeformat and
      videonativeformat output strings since the allow=all can be a lengthy
      list.
      
      * Tweaked the CHANNEL() XML documentation for secure_bridge_signaling,
      secure_bridge_media, and state.
      
      * Ensured the output buffer is initialized for secure_bridge_signaling and
      secure_bridge_media.
      
      * Made use the locked_copy_string() macro instead of inlining it for trace
      and checkhangup.
      ........
      
      Merged revisions 422700 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      025bd1bf
  5. Aug 18, 2014
  6. Aug 11, 2014
  7. Aug 06, 2014
  8. Jul 31, 2014
  9. Jul 28, 2014
  10. Jul 25, 2014
  11. Jul 20, 2014
  12. Jul 18, 2014
  13. Jul 15, 2014
  14. Jun 17, 2014
  15. Jun 03, 2014
  16. May 30, 2014
  17. May 28, 2014
  18. May 21, 2014
  19. May 09, 2014
  20. May 07, 2014
  21. May 01, 2014
  22. Apr 23, 2014
  23. Apr 15, 2014
  24. Apr 12, 2014
  25. Apr 08, 2014
  26. Apr 05, 2014
    • Russell Bryant's avatar
      func_periodic_hook: New function for periodic hooks. · ea290b2c
      Russell Bryant authored
      This commit introduces a new dialplan function, PERIODIC_HOOK().
      It allows you run to a dialplan hook on a channel periodically.  The
      original use case that inspired this was the ability to play a beep
      periodically into a call being recorded.  The implementation is much
      more generic though and could be used for many other things.
      
      The implementation makes heavy use of existing Asterisk components.
      It uses a combination of Local channels and ChanSpy() to run some
      custom dialplan and inject any audio it generates into an active call.
      
      The other important bit of the implementation is how it figures out
      when to trigger the beep playback.  This implementation uses the
      audiohook API, even though it's not actually touching the audio in any
      way.  It's a convenient way to get a callback and check if it's time
      to kick off another beep.  It would be nice if this was timer event
      based instead of polling based, but unfortunately I don't see a way to
      do it that won't interfere with other things.
      
      Review: https://reviewboard.asterisk.org/r/3362/
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411768 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      ea290b2c
  27. Mar 27, 2014
  28. 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
  29. Mar 06, 2014
    • George Joseph's avatar
      sorcery: Create AST_SORCERY dialplan function. · a4906e9f
      George Joseph authored
      This patch creates the AST_SORCERY dialplan function which allows someone to
      retrieve any value from a sorcery-based config file.  It's similar to 
      AST_CONFIG.
      
      The creation of the function itself was fairly straightforward but it required
      changes to the underlying sorcery infrastructure that rippled into individual
      sorcery objects.  The changes stemmed from inconsistencies in how sorcery
      created ast_variable objectsets from sorcery objects and the inconsistency
      in how individual objects used that feature especially when it came to
      parameters that can be specified multiple times like contact in aor and match
      in identify.  You can read more here...
      http://lists.digium.com/pipermail/asterisk-dev/2014-February/065202.html
      
      So, what this patch does, besides actually creating the AST_SORCERY function,
      is the following...
      
      * Creates ast_variable_list_append which is a helper to append one ast_variable
        list to another.
      * Modifies the ast_sorcery_object_field_register functions to accept the
        already-defined sorcery_fields_handler callback.
      * Modifies ast_sorcery_objectset_create to accept a parameter indicating return
        type preference...a single ast_variable with all values concatenated or an
        ast_variable list with multiple entries.  Also fixed a few bugs.
      * Modifies individual sorcery object implementations to use the new function
        definition of the ast_sorcery_object_field_register functions.
      * Modifies location.c and res_pjsip_endpoint_identifier_ip.c to implement
        sorcery_fields_handler handlers so they return multiple occurrences as an
        ast_variable_list.
      * Added a whole bunch of tests to test_sorcery.
      
      (closes issue ASTERISK-22537)
      Review: http://reviewboard.asterisk.org/r/3254/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410042 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      a4906e9f
  30. Mar 05, 2014
  31. Mar 04, 2014
  32. Feb 07, 2014
  33. Feb 04, 2014
  34. Jan 14, 2014
    • Richard Mudgett's avatar
      verbosity: Fix performance of console verbose messages. · 828f339a
      Richard Mudgett authored
      The per console verbose level feature as previously implemented caused a
      large performance penalty.  The fix required some minor incompatibilities
      if the new rasterisk is used to connect to an earlier version.  If the new
      rasterisk connects to an older Asterisk version then the root console
      verbose level is always affected by the "core set verbose" command of the
      remote console even though it may appear to only affect the current
      console.  If an older version of rasterisk connects to the new version
      then the "core set verbose" command will have no effect.
      
      * Fixed the verbose performance by not generating a verbose message if
      nothing is going to use it and then filtered any generated verbose
      messages before actually sending them to the remote consoles.
      
      * Split the "core set debug" and "core set verbose" CLI commands to remove
      the per module verbose support that cannot work with the per console
      verbose level.
      
      * Added a silent option to the "core set verbose" command.
      
      * Fixed "core set debug off" tab completion.
      
      * Made "core show settings" list the current console verbosity in addition
      to the root console verbosity.
      
      * Changed the default verbose level of the 'verbose' setting in the
      logger.conf [logfiles] section.  The default is now to once again follow
      the current root console level.  As a result, using the AMI Command action
      with "core set verbose" could again set the root console verbose level and
      affect the verbose level logged.
      
      (closes issue AST-1252)
      Reported by: Guenther Kelleter
      
      Review: https://reviewboard.asterisk.org/r/3114/
      ........
      
      Merged revisions 405431 from http://svn.asterisk.org/svn/asterisk/branches/11
      ........
      
      Merged revisions 405432 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405436 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      828f339a
  35. Jan 12, 2014
  36. Jan 02, 2014
Loading