Skip to content
Snippets Groups Projects
  1. Nov 14, 2014
    • Matthew Jordan's avatar
      tests/test_cel: Unlock bridge on off nominal paths · 32685449
      Matthew Jordan authored
      If the test fails due to memory allocation errors, we may as well attempt to
      unlock the bridge on the way out.
      ........
      
      Merged revisions 427927 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      32685449
    • Mark Michelson's avatar
      Fix race condition that could result in ARI transfer messages not being sent. · 2d9471ab
      Mark Michelson authored
      From reviewboard:
      
      "During blind transfer testing, it was noticed that tests were failing
      occasionally because the ARI blind transfer event was not being sent.
      After investigating, I detected a race condition in the blind transfer
      code. When blind transferring a single channel, the actual transfer
      operation (i.e. removing the transferee from the bridge and directing
      them to the proper dialplan location) is queued onto the transferee
      bridge channel. After queuing the transfer operation, the blind transfer
      Stasis message is published. At the time of publication, snapshots of
      the channels and bridge involved are created. The ARI subscriber to the
      blind transfer Stasis message then attempts to determine if the bridge
      or any of the involved channels are subscribed to by ARI applications.
      If so, then the blind transfer message is sent to the applications. The
      way that the ARI blind transfer message handler works is to first see
      if the transferer channel is subscribed to. If not, then iterate over
      all the channel IDs in the bridge snapshot and determine if any of
      those are subscribed to. In the test we were running, the lone
      transferee channel was subscribed to, so an ARI event should have been
      sent to our application. Occasionally, though, the bridge snapshot did
      not have any channels IDs on it at all. Why?
      
      The problem is that since the blind transfer operation is handled by a
      separate thread, it is possible that the transfer will have completed and
      the channels removed from the bridge before we publish the blind transfer
      Stasis message. Since the blind transfer has completed, the bridge on
      which the transfer occurred no longer has any channels on it, so the
      resulting bridge snapshot has no channels on it. Through investigation of
      the code, I found that attended transfers can have this issue too for the
      case where a transferee is transferred to an application."
      
      The fix employed here is to decouple the creation of snapshots for the transfer
      messages from the publication of the transfer messages. This way, snapshots
      can be created to reflect what they are at the time of the transfer operation.
      
      Review: https://reviewboard.asterisk.org/r/4135
      ........
      
      Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
      ........
      
      Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      2d9471ab
  2. Nov 06, 2014
  3. Nov 05, 2014
  4. Oct 17, 2014
  5. Oct 16, 2014
  6. Oct 14, 2014
  7. Oct 13, 2014
    • George Joseph's avatar
      manager/config: Support templates and non-unique category names via AMI · c7e6b6ba
      George Joseph authored
      This patch provides the capability to manipulate templates and categories
      with non-unique names via AMI.
      
      Summary of changes:
      
      GetConfig and GetConfigJSON: Added "Filter" parameter:  A comma separated list
      of name_regex=value_regex expressions which will cause only categories whose
      variables match all expressions to be considered.  The special variable name
      TEMPLATES can be used to control whether templates are included.  Passing
      'include' as the value will include templates along with normal categories.
      Passing 'restrict' as the value will restrict the operation to ONLY templates.
      Not specifying a TEMPLATES expression results in the current default behavior
      which is to not include templates.
      
      UpdateConfig: NewCat now includes options for allowing duplicate category
      names, indicating if the category should be created as a template, and
      specifying templates the category should inherit from.  The rest of the
      actions now accept a filter string as defined above.  If there are non-unique
      category names, you can now update specific ones based on variable values.
      
      To facilitate the new capabilities in manager, corresponding changes had to be
      made to config, most notably the addition of filter criteria to many of the
      APIs.  In some cases it was easy to change the references to use the new
      prototype but others would have required touching too many files for this
      patch so a wrapper with the original prototype was created.  Macros couldn't
      be used in this case because it would break binary compatibility with modules
      such as res_digium_phone that are linked to real symbols.
      
      Tested-by: George Joseph
      
      Review: https://reviewboard.asterisk.org/r/4033/
      ........
      
      Merged revisions 425383 from http://svn.asterisk.org/svn/asterisk/branches/12
      ........
      
      Merged revisions 425384 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425385 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      c7e6b6ba
  8. Oct 10, 2014
  9. Sep 26, 2014
  10. Sep 23, 2014
    • Mark Michelson's avatar
      Make CDR and CEL unit tests less FRACKy. · a89964a5
      Mark Michelson authored
      Prior to this commit, CDR and CEL tests were expected to trigger
      FRACKs (i.e. assertions) due to the fact that the channels they
      create have no formats on them. Some code was independently added
      recently that attempts to prevent FRACKs from occurring by failing
      early when attempting to set up translation paths if one or both
      channels support no formats. Unfortunately, this attempt to be helpful
      made the CDR and CEL tests go from simply FRACKing to outright
      failing and in some cases, failing so badly as to crash Asterisk.
      
      This commit seeks to correct past mistakes by adding the ulaw format
      to channels created by the CDR and CEL unit tests. This makes setting
      up translation paths succeed, eliminates previously-seen FRACKs, and
      ultimately causes the unit tests to succeed again.
      
      Review: https://reviewboard.asterisk.org/r/4014
      ........
      
      Merged revisions 423783 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423784 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      a89964a5
  11. Sep 18, 2014
  12. Aug 27, 2014
  13. Aug 20, 2014
  14. Aug 14, 2014
  15. Aug 08, 2014
  16. Aug 07, 2014
  17. Aug 06, 2014
  18. Aug 05, 2014
    • Matthew Jordan's avatar
      Multiple revisions 420089-420090,420097 · 47bf7efc
      Matthew Jordan authored
      ........
        r420089 | mjordan | 2014-08-05 15:10:52 -0500 (Tue, 05 Aug 2014) | 72 lines
        
        ARI: Add channel technology agnostic out of call text messaging
        
        This patch adds the ability to send and receive text messages from various
        technology stacks in Asterisk through ARI. This includes chan_sip (sip),
        res_pjsip_messaging (pjsip), and res_xmpp (xmpp). Messages are sent using the
        endpoints resource, and can be sent directly through that resource, or to a
        particular endpoint.
        
        For example, the following would send the message "Hello there" to PJSIP
        endpoint alice with a display URI of sip:asterisk@mycooldomain.org:
        
        ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk@mycooldomain.org&body=Hello+There
        
        This is equivalent to the following as well:
        
        ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk@mycooldomain.org&body=Hello+There
        
        Both forms are available for message technologies that allow for arbitrary
        destinations, such as chan_sip.
        
        Inbound messages can now be received over ARI as well. An ARI application that
        subscribes to endpoints will receive messages from those endpoints:
        
        {
          "type": "TextMessageReceived",
          "timestamp": "2014-07-12T22:53:13.494-0500",
          "endpoint": {
            "technology": "PJSIP",
            "resource": "alice",
            "state": "online",
            "channel_ids": []
          },
          "message": {
            "from": "\"alice\" <sip:alice@127.0.0.1>",
            "to": "pjsip:asterisk@127.0.0.1",
            "body": "Watson, come here.",
            "variables": []
          },
          "application": "testsuite"
        }
        
        The above was made possible due to some rather major changes in the message
        core. This includes (but is not limited to):
        - Users of the message API can now register message handlers. A handler has
          two callbacks: one to determine if the handler has a destination for the
          message, and another to handle it.
        - All dialplan functionality of handling a message was moved into a message
          handler provided by the message API.
        - Messages can now have the technology/endpoint associated with them.
          Various other properties are also now more easily accessible.
        - A number of ao2 containers that weren't really needed were replaced with
          vectors. Iteration over ao2_containers is expensive and pointless when
          the lifetime of things is well defined and the number of things is very
          small.
        
        res_stasis now has a new file that makes up its structure, messaging. The
        messaging functionality implements a message handler, and passes received
        messages that match an interested endpoint over to the app for processing.
        
        Note that inadvertently while testing this, I reproduced ASTERISK-23969.
        res_pjsip_messaging was incorrectly parsing out the 'to' field, such that
        arbitrary SIP URIs mangled the endpoint lookup. This patch includes the
        fix for that as well.
        
        Review: https://reviewboard.asterisk.org/r/3726
        
        ASTERISK-23692 #close
        Reported by: Matt Jordan
        
        ASTERISK-23969 #close
        Reported by: Andrew Nagy
      ........
        r420090 | mjordan | 2014-08-05 15:16:37 -0500 (Tue, 05 Aug 2014) | 2 lines
        
        Remove automerge properties :-(
      ........
        r420097 | mjordan | 2014-08-05 16:36:25 -0500 (Tue, 05 Aug 2014) | 2 lines
        
        test_message: Fix strict-aliasing compilation issue
      ........
      
      Merged revisions 420089-420090,420097 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      47bf7efc
  19. Jul 23, 2014
  20. Jul 22, 2014
  21. Jul 21, 2014
  22. Jul 20, 2014
  23. Jul 07, 2014
    • Kinsey Moore's avatar
      CEL: Fix incorrect/missing extra field information · edcaa540
      Kinsey Moore authored
      This corrects two issues with the extra field information in Asterisk
      12+ in channel event logs.
      
      It is possible to inject custom values into the dialstatus provided by
      ast_channel_dial_type() Stasis messages that fall outside the
      enumeration allowed for the DIALSTATUS channel variable. CEL now
      filters for the allowed values and ignores other values.
      
      The "hangupsource" extra field key is always blank if the far end
      channel is a chan_pjsip channel. This is because the hangupsource is
      never set for the pjsip channel driver. This change sets the
      hangupsource whenever a hangup is queued for chan_pjsip channels.
      
      This corrects an issue with the pjsip channel driver where the
      hangupcause information was not being set properly.
      
      Review: https://reviewboard.asterisk.org/r/3690/
      ........
      
      Merged revisions 418071 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418084 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      edcaa540
  24. Jun 27, 2014
  25. Jun 26, 2014
  26. Jun 20, 2014
  27. Jun 16, 2014
    • Kevin Harwell's avatar
      res_http_websocket: read/write string fixup · bd0aa4fb
      Kevin Harwell authored
      There was a problem when reading a string from the websocket. It assumed the
      received data had a null terminator and tried to write the data to an ast_str.
      This of course could/would read past the end of the given buffer while
      writing the data to the internal buffer of ast_str. Modified the the code to
      correctly place a null terminator on the result string.
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416394 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      bd0aa4fb
  28. Jun 15, 2014
  29. Jun 06, 2014
  30. Jun 05, 2014
    • Kevin Harwell's avatar
      res_http_websocket: Create a websocket client · e763d704
      Kevin Harwell authored
      Added a websocket server client in Asterisk. Asterisk has a websocket server,
      but not a client. The ability to have Asterisk be able to connect to a websocket
      server can potentially be useful for future work (for instance this could allow
      ARI to connect back to some external system, although more work would be needed
      in order to incorporate that).
      
      Also a couple of things to note - proxy connection support has not been
      implemented and there is limited http response code handling (basically, it is
      connect or not).
      
      Also added an initial new URI handling mechanism to core.  Internet type URI's
      are parsed into a data structure that contains pointers to the various parts of
      the URI.
      
      (closes issue ASTERISK-23742)
      Reported by: Kevin Harwell
      Review: https://reviewboard.asterisk.org/r/3541/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415223 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      e763d704
  31. May 23, 2014
  32. Apr 11, 2014
  33. Apr 02, 2014
  34. Mar 17, 2014
  35. Mar 14, 2014
  36. Mar 07, 2014
Loading