Skip to content
Snippets Groups Projects
  1. Sep 21, 2010
  2. Sep 14, 2010
  3. Sep 02, 2010
  4. Aug 16, 2010
  5. Jul 16, 2010
  6. Jul 14, 2010
  7. Jun 28, 2010
  8. Jun 16, 2010
  9. Jun 10, 2010
  10. Jun 08, 2010
    • Terry Wilson's avatar
      Add SRTP support for Asterisk · 857814f4
      Terry Wilson authored
      After 5 years in mantis and over a year on reviewboard, SRTP support is finally
      being comitted. This includes generic CHANNEL dialplan functions that work for
      getting the status of whether a call has secure media or signaling as defined
      by the underlying channel technology and for setting whether or not a new
      channel being bridged to a calling channel should have secure signaling or
      media. See doc/tex/secure-calls.tex for examples.
      
      Original patch by mikma, updated for trunk and revised by me.
      
      (closes issue #5413)
      Reported by: mikma
      Tested by: twilson, notthematrix, hemanshurpatel
      
      Review: https://reviewboard.asterisk.org/r/191/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268894 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      857814f4
  11. May 24, 2010
    • Terry Wilson's avatar
      Add the FullyBooted AMI event · 3c9a8eba
      Terry Wilson authored
      It is possible to connect to the manager interface before all Asterisk modules
      are loaded. To ensure that an application does not send AMI actions that might
      require a module that has not yet loaded, the application can listen for the
      FullyBooted manager event. It will be sent upon connection if all modules have
      been loaded, or as soon as loading is complete. The event:
      
         Event: FullyBooted
         Privilege: system,all
         Status: Fully Booted
      
      Review: https://reviewboard.asterisk.org/r/639/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@265320 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      3c9a8eba
  12. Apr 22, 2010
  13. Apr 21, 2010
  14. Apr 09, 2010
    • Mark Michelson's avatar
      Merge Call completion support into trunk. · e24661fd
      Mark Michelson authored
      From Reviewboard:
      CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
      overview of the architecture can be found in the file doc/CCSS_architecture.pdf
      in the CCSS branch. Off the top of my head, the big differences between what is
      implemented and what is in the document are as follows:
      
      1. We did not end up modifying the Hangup application at all.
      2. The document states that a single call completion monitor may be used across
         multiple calls to the same device. This proved to not be such a good idea
         when implementing protocol-specific monitors, and so we ended up using one
         monitor per-device per-call.
      3. There are some configuration options which were conceived after the document
         was written. These are documented in the ccss.conf.sample that is on this
         review request.
      		      
      For some basic understanding of terminology used throughout this code, see the
      ccss.tex document that is on this review.
      
      This implements CCBS and CCNR in several flavors.
      
      First up is a "generic" implementation, which can work over any channel technology
      provided that the channel technology can accurately report device state. Call
      completion is requested using the dialplan application CallCompletionRequest and can
      be canceled using CallCompletionCancel. Device state subscriptions are used in order
      to monitor the state of called parties.
      
      Next, there is a SIP-specific implementation of call completion. This method uses the
      methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
      using SIP signaling. There are a few things to note here:
      
      * The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
        what is defined in the referenced draft.
      
      * Implementation of the draft required support for SIP PUBLISH. I attempted to write
        this in a generic-enough fashion such that if someone were to want to write PUBLISH
        support for other event packages, such as dialog-state or presence, most of the effort
        would be in writing callbacks specific to the event package.
      
      * A subportion of supporting PUBLISH reception was that we had to implement a PIDF
        parser. The PIDF support added is a bit minimal. I first wrote a validation
        routine to ensure that the PIDF document is formatted properly. The rest of the
        PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
        code. In other words, while there is PIDF support here, it is not in any state
        where it could easily be applied to other event packages as is.
      
      Finally, there are a variety of ISDN-related call completion protocols supported. These
      were written by Richard Mudgett, and as such I can't really say much about their
      implementation. There are notes in the CHANGES file that indicate the ISDN protocols
      over which call completion is supported.
      
      Review: https://reviewboard.asterisk.org/r/523
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      e24661fd
  15. Apr 05, 2010
  16. Mar 18, 2010
  17. Mar 03, 2010
    • Leif Madsen's avatar
      Update existing Local channel documentation. · 06ff72a7
      Leif Madsen authored
      A complete re-write of the Local channel documentation has been performed, with
      the existing information from localchannel.txt and localchannel.tex merged in.
      
      (closes issue #16637)
      Reported by: kobaz
      Patches: 
            localchannel.tex uploaded by lmadsen (license 10)
            localchannel.txt uploaded by lmadsen (license 10)
      Tested by: lmadsen, jsmith, mmichelson
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@250609 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      06ff72a7
  18. Mar 02, 2010
  19. Jan 13, 2010
  20. Dec 14, 2009
  21. Nov 06, 2009
  22. Oct 29, 2009
  23. Oct 28, 2009
  24. Oct 21, 2009
  25. Aug 27, 2009
  26. Aug 18, 2009
  27. Aug 05, 2009
  28. Aug 03, 2009
    • Kevin P. Fleming's avatar
      Rename 'canreinvite' option to 'directmedia', with backwards compatibility. · e9d22f80
      Kevin P. Fleming authored
      It is clear from multiple mailing list, forum, wiki and other sorts of posts
      that users don't really understand the effects that the 'canreinvite' config
      option actually has, and that in some cases they think that setting it to 'no'
      will actually cause various other features (T.38, MOH, etc.) to not work properly,
      when in fact this is not the case. This patch changes the proper name of the
      option to what it should have been from the beginning ('directmedia'), but
      preserves backwards compatibility for existing configurations.
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      e9d22f80
  29. Aug 01, 2009
  30. Jul 17, 2009
  31. Jul 11, 2009
    • Russell Bryant's avatar
      Add an API for reporting security events, and a security event logging module. · 4cf8a968
      Russell Bryant authored
      This commit introduces the security events API.  This API is to be used by
      Asterisk components to report events that have security implications.
      A simple example is when a connection is made but fails authentication.  These
      events can be used by external tools manipulate firewall rules or something
      similar after detecting unusual activity based on security events.
      
      Inside of Asterisk, the events go through the ast_event API.  This means that
      they have a binary encoding, and it is easy to write code to subscribe to these
      events and do something with them.
      
      One module is provided that is a subscriber to these events - res_security_log.
      This module turns security events into a parseable text format and sends them
      to the "security" logger level.  Using logger.conf, these log entries may be
      sent to a file, or to syslog.
      
      One service, AMI, has been fully updated for reporting security events.
      AMI was chosen as it was a fairly straight forward service to convert.
      The next target will be chan_sip.  That will be more complicated and will
      be done as its own project as the next phase of security events work.
      
      For more information on the security events framework, see the documentation
      generated from doc/tex/.  "make asterisk.pdf"
      
      Review: https://reviewboard.asterisk.org/r/273/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206021 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      4cf8a968
  32. Jun 30, 2009
    • Russell Bryant's avatar
      Move Asterisk-addons modules into the main Asterisk source tree. · c511a267
      Russell Bryant authored
      Someone asked yesterday, "is there a good reason why we can't just put these
      modules in Asterisk?".  After a brief discussion, as long as the modules are
      clearly set aside in their own directory and not enabled by default, it is
      perfectly fine.
      
      For more information about why a module goes in addons, see README-addons.txt.
      
      chan_ooh323 does not currently compile as it is behind some trunk API updates.
      However, it will not build by default, so it should be okay for now.
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204413 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      c511a267
  33. Jun 26, 2009
    • Russell Bryant's avatar
      Merge the new Channel Event Logging (CEL) subsystem. · 0264eef1
      Russell Bryant authored
      CEL is the new system for logging channel events.  This was inspired after
      facing many problems trying to represent what is possible to happen to a call
      in Asterisk using CDR records.  For more information on CEL, see the built in
      HTML or PDF documentation generated from the files in doc/tex/.
      
      Many thanks to Steve Murphy (murf) and Brian Degenhardt (bmd) for their hard
      work developing this code.  Also, thanks to Matt Nicholson (mnicholson) and
      Sean Bright (seanbright) for their assistance in the final push to get this
      code ready for Asterisk trunk.
      
      Review: https://reviewboard.asterisk.org/r/239/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203638 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      0264eef1
  34. Jun 23, 2009
Loading