Skip to content
Snippets Groups Projects
  1. Jul 18, 2014
  2. Jul 08, 2014
  3. Jul 03, 2014
  4. May 30, 2014
  5. May 28, 2014
  6. May 22, 2014
    • Scott Griepentrog's avatar
      ARI: Add ability to raise arbitrary User Events · cf21644d
      Scott Griepentrog authored
      User events can now be generated from ARI.  Events can be signalled with
      arbitrary json variables, and include one or more of channel, bridge, or
      endpoint snapshots.  An application must be specified which will receive
      the event message (other applications can subscribe to it).  The message
      will also be delivered via AMI provided a channel is attached.  Dialplan
      generated user event messages are still transmitted via the channel, and
      will only be received by a stasis application they are attached to or if
      the channel is subscribed to.
      
      This change also introduces the multi object blob mechanism used to send
      multiple snapshot types in a single message.  The dialplan app UserEvent
      was also changed to use multi object blob, and a new stasis message type
      created to handle them.
      
      ASTERISK-22697 #close
      Review: https://reviewboard.asterisk.org/r/3494/
      ........
      
      Merged revisions 414405 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414406 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      cf21644d
  7. Apr 18, 2014
  8. Apr 17, 2014
  9. Mar 28, 2014
  10. Mar 19, 2014
  11. Mar 07, 2014
    • Scott Griepentrog's avatar
      uniqueid: channel linkedid, ami, ari object creation with id's · 80ef9a21
      Scott Griepentrog authored
      Much needed was a way to assign id to objects on creation, and
      much change was necessary to accomplish it.  Channel uniqueids
      and linkedids are split into separate string and creation time
      components without breaking linkedid propgation.  This allowed
      the uniqueid to be specified by the user interface - and those
      values are now carried through to channel creation, adding the
      assignedids value to every function in the chain including the
      channel drivers. For local channels, the second channel can be
      specified or left to default to a ;2 suffix of first.  In ARI,
      bridge, playback, and snoop objects can also be created with a
      specified uniqueid.
      
      Along the way, the args order to allocating channels was fixed
      in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
      masquerade occurs.
      
      (closes issue ASTERISK-23120)
      Review: https://reviewboard.asterisk.org/r/3191/
      ........
      
      Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      80ef9a21
  12. Mar 06, 2014
  13. Feb 05, 2014
  14. Feb 01, 2014
  15. Jan 21, 2014
  16. Jan 14, 2014
  17. Dec 20, 2013
  18. Dec 18, 2013
  19. Dec 17, 2013
  20. Dec 14, 2013
  21. Dec 13, 2013
  22. Nov 30, 2013
  23. Nov 23, 2013
  24. Nov 21, 2013
  25. Nov 13, 2013
  26. Nov 12, 2013
  27. Nov 08, 2013
  28. Nov 07, 2013
    • David M. Lee's avatar
      ari: User better nicknames for ARI operations · 7d0d1a1e
      David M. Lee authored
      While working on building client libraries from the Swagger API, I
      noticed a problem with the nicknames.
      
          channel.deleteChannel()
          channel.answerChannel()
          channel.muteChannel()
      
      Etc. We put the object name in the nickname (since we were generating C
      code), but it makes OO generators redundant.
      
      This patch makes the nicknames more OO friendly. This resulted in a lot
      of name changing within the res_ari_*.so modules, but not much else.
      
      There were a couple of other fixed I made in the process.
      
       * When reversible operations (POST /hold, POST /unhold) were made more
         RESTful (POST /hold, DELETE /unhold), the path for the second operation
         was left in the API declaration. This worked, but really the two
         operations should have been on the same API.
       * The POST /unmute operation had still not been REST-ified.
      
      Review: https://reviewboard.asterisk.org/r/2940/
      ........
      
      Merged revisions 402528 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      7d0d1a1e
  29. Nov 01, 2013
  30. Oct 29, 2013
  31. Oct 25, 2013
  32. Oct 24, 2013
  33. Oct 21, 2013
  34. Oct 19, 2013
Loading