Skip to content
Snippets Groups Projects
  1. Jul 22, 2014
    • Matthew Jordan's avatar
      ARI: Fix endpoint/channel subscription issues; allow for subscriptions to tech · bb87796f
      Matthew Jordan authored
      This patch serves two purposes:
      (1) It fixes some bugs with endpoint subscriptions not reporting all of the
          channel events
      (2) It serves as the preliminary work needed for ASTERISK-23692, which allows
          for sending/receiving arbitrary out of call text messages through ARI in a
          technology agnostic fashion.
      
      The messaging functionality described on ASTERISK-23692 requires two things:
      (1) The ability to send/receive messages associated with an endpoint. This is
          relatively straight forwards with the endpoint core in Asterisk now.
      (2) The ability to send/receive messages associated with a technology and an
          arbitrary technology defined URI. This is less straight forward, as
          endpoints are formed from a tech + resource pair. We don't have a
          mechanism to note that a technology that *may* have endpoints exists.
      
      This patch provides such a mechanism, and fixes a few bugs along the way.
      
      The first major bug this patch fixes is the forwarding of channel messages
      to their respective endpoints. Prior to this patch, there were two problems:
      (1) Channel caching messages weren't forwarded. Thus, the endpoints missed
          most of the interesting bits (such as channel creation, destruction, state
          changes, etc.)
      (2) Channels weren't associated with their endpoint until after creation.
          This resulted in endpoints missing the channel creation message, which
          limited the usefulness of the subscription in the first place (a major use
          case being 'tell me when this endpoint has a channel'). Unfortunately,
          this meant another parameter to ast_channel_alloc. Since not all channel
          technologies support an ast_endpoint, this patch makes such a call
          optional and opts for a new function, ast_channel_alloc_with_endpoint.
      
      When endpoints are created, they will implicitly create a technology endpoint
      for their technology (if one does not already exist). A technology endpoint is
      special in that it has no state, cannot have channels created for it, cannot
      be created explicitly, and cannot be destroyed except on shutdown. It does,
      however, have all messages from other endpoints in its technology forwarded to
      it.
      
      Combined with the bug fixes, we now have Stasis messages being properly
      forwarded. Consider the following scenario: two PJSIP endpoints (foo and bar),
      where bar has a single channel associated with it and foo has two channels
      associated with it. The messages would be forwarded as follows:
      
      channel PJSIP/foo-1 --
                            \
                             --> endpoint PJSIP/foo --
                            /                         \
      channel PJSIP/foo-2 --                           \
                                                        ---- > endpoint PJSIP
                                                      /
      channel PJSIP/bar-1 -----> endpoint PJSIP/bar --
      
      ARI, through the applications resource, can:
       - subscribe to endpoint:PJSIP/foo and get notifications for channels
         PJSIP/foo-1,PJSIP/foo-2 and endpoint PJSIP/foo
       - subscribe to endpoint:PJSIP/bar and get notifications for channels
         PJSIP/bar-1 and endpoint PJSIP/bar
       - subscribe to endpoint:PJSIP and get notifications for channels
         PJSIP/foo-1,PJSIP/foo-2,PJSIP/bar-1 and endpoints PJSIP/foo,PJSIP/bar
      
      Note that since endpoint PJSIP never changes, it never has events itself. It
      merely provides an aggregation point for all other endpoints in its technology
      (which in turn aggregate all channel messages associated with that endpoint).
      
      This patch also adds endpoints to res_xmpp and chan_motif, because the actual
      messaging work will need it (messaging without XMPP is just sad).
      
      Review: https://reviewboard.asterisk.org/r/3760/
      
      ASTERISK-23692
      ........
      
      Merged revisions 419196 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      bb87796f
  2. Jul 20, 2014
  3. Jul 18, 2014
  4. Jul 07, 2014
    • Matthew Jordan's avatar
      ARI/res_stasis: Subscribe to both Local channel halves when originating to app · d4b436d0
      Matthew Jordan authored
      This patch fixes two bugs:
      
      1. When originating a channel into a Stasis application, we already create a
         subscription for the channel that is going into our Stasis app.
         Unfortunately, when you create a Local channel and pass it off to a Stasis
         app, you really aren't creating just one channel: you're creating two. This
         patch snags the second half of the Local channel pair (assuming it is a
         Local channel pair, but luckily core_local is kind about such assumptions)
         and subscribes to it as well.
      
      2. Subscriptions are a bit sticky right now. If a subscription is made, the
         'interest' count gets bumped on the Stasis subscription - but unless
         something explicitly unsubscribes the channel, said subscription sticks
         around. This is not much of a problem is a user is creating the subscription
         - if they made it, they must want it. However, when we are creating
         implicit subscriptions, we need to make sure something clears them out.
         This patch takes a pessimistic approach: it watches the cache updates
         coming from Stasis and, if we notice that the cache just cleared out an
         object, we delete our subscription object. This keeps our ao2 container of
         Stasis forwards in an application from growing out of hand; it also is a
         bit more forgiving for end users who may not realize they were supposed to
         unsubscribe from that channel that just hung up.
      
      Review: https://reviewboard.asterisk.org/r/3710/
      #ASTERISK-23939 #close
      ........
      
      Merged revisions 418089 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418090 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      d4b436d0
  5. Jul 03, 2014
  6. Jul 02, 2014
  7. Jun 26, 2014
    • Matthew Jordan's avatar
      res_http_websocket: Close websocket correctly and use careful fwrite · 365ae752
      Matthew Jordan authored
      When a client takes a long time to process information received from Asterisk,
      a write operation using fwrite may fail to write all information. This causes
      the underlying file stream to be in an unknown state, such that the socket
      must be disconnected. Unfortunately, there are two problems with this in
      Asterisk's existing websocket code:
      1. Periodically, during the read loop, Asterisk must write to the connected
         websocket to respond to pings. As such, Asterisk maintains a reference to
         the session during the loop. When ast_http_websocket_write fails, it may
         cause the session to decrement its ref count, but this in and of itself
         does not break the read loop. The read loop's write, on the other hand,
         does not break the loop if it fails. This causes the socket to get in a
         'stuck' state, preventing the client from reconnecting to the server.
      2. More importantly, however, is that the fwrite in ast_http_websocket_write
         fails with a large volume of data when the client takes awhile to process
         the information. When it does fail, it fails writing only a portion of
         the bytes. With some debugging, it was shown that this was failing in a
         similar fashion to ASTERISK-12767. Switching this over to ast_careful_fwrite
         with a long enough timeout solved the problem.
      
      Note that this version of the patch, unlike r417310 in Asterisk 11, exposes
      configuration options beyond just chan_sip's sip.conf. Configuration options
      to configure the write timeout have also been added to pjsip.conf and ari.conf.
      
      #ASTERISK-23917 #close
      Reported by: Matt Jordan
      
      Review: https://reviewboard.asterisk.org/r/3624/
      ........
      
      Merged revisions 417310 from http://svn.asterisk.org/svn/asterisk/branches/11
      ........
      
      Merged revisions 417311 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417317 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      365ae752
  8. Jun 13, 2014
    • Matthew Jordan's avatar
      stasis: Reduce creation of channel snapshots to improve performance · 9cc1a8e8
      Matthew Jordan authored
      During some performance testing of Asterisk with AGI, ARI, and lots of Local
      channels, we noticed that there's quite a hit in performance during channel
      creation and releasing to the dialplan (ARI continue). After investigating
      the performance spike that occurs during channel creation, we discovered
      that we create a lot of channel snapshots that are technically unnecessary.
      This includes creating snapshots during:
       * AGI execution
       * Returning objects for ARI commands
       * During some Local channel operations
       * During some dialling operations
       * During variable setting
       * During some bridging operations
      And more.
      
      This patch does the following:
       - It removes a number of fields from channel snapshots. These fields were
         rarely used, were expensive to have on the snapshot, and hurt performance.
         This included formats, translation paths, Log Call ID, callgroup, pickup
         group, and all channel variables. As a result, AMI Status,
         "core show channel", "core show channelvar", and "pjsip show channel" were
         modified to either hit the live channel or not show certain pieces of data.
         While this is unfortunate, the performance gain from this patch is worth
         the loss in behaviour.
       - It adds a mechanism to publish a cached snapshot + blob. A large number of
         publications were changed to use this, including:
         - During Dial begin
         - During Variable assignment (if no AMI variables are emitted - if AMI
           variables are set, we have to make snapshots when a variable is changed)
         - During channel pickup
         - When a channel is put on hold/unhold
         - When a DTMF digit is begun/ended
         - When creating a bridge snapshot
         - When an AOC event is raised
         - During Local channel optimization/Local bridging
         - When endpoint snapshots are generated
         - All AGI events
         - All ARI responses that return a channel
         - Events in the AgentPool, MeetMe, and some in Queue
       - Additionally, some extraneous channel snapshots were being made that were
         unnecessary. These were removed.
       - The result of ast_hashtab_hash_string is now cached in stasis_cache. This
         reduces a large number of calls to ast_hashtab_hash_string, which reduced
         the amount of time spent in this function in gprof by around 50%.
      
      #ASTERISK-23811 #close
      Reported by: Matt Jordan
      
      Review: https://reviewboard.asterisk.org/r/3568/
      ........
      
      Merged revisions 416211 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416216 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      9cc1a8e8
  9. May 30, 2014
  10. 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
  11. Apr 18, 2014
  12. Apr 17, 2014
  13. Apr 15, 2014
  14. Apr 11, 2014
  15. Mar 25, 2014
  16. Mar 20, 2014
    • Richard Mudgett's avatar
      assigned-uniqueids: Miscellaneous cleanup and fixes. · 1ba13718
      Richard Mudgett authored
      * Fix memory leak in ast_unreal_new_channels().  Made it generate the ;2
      uniqueid on a stack variable instead of mallocing it.
      
      * Made send error response to ARI and AMI requests instead of just logging
      excessive uniqueid length and allowing truncation.  action_originate() and
      ari_channels_handle_originate_with_id().
      
      * Fixed minor truncating uniqueid hole when generating the ;2 uniqueid
      string length.  Created public and internal lengths of uniqueid.  The
      internal length can handle a max public uniqueid plus an appended ;2.
      
      * free() and ast_free() are NULL tolerant so they don't need a NULL test
      before calling.
      
      * Made use better struct initialization format instead of the position
      dependent initialization format.  Also anything not explicitly initialized
      in the struct is initialized to zero by the compiler.
      
      * Made ast_channel_internal_set_fake_ids() use the safer
      ast_copy_string() instead of strncpy().
      
      Review: https://reviewboard.asterisk.org/r/3371/
      ........
      
      Merged revisions 410949 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      1ba13718
  17. Mar 19, 2014
  18. Mar 14, 2014
  19. Mar 10, 2014
  20. Mar 08, 2014
  21. 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
  22. Mar 06, 2014
  23. Feb 21, 2014
  24. Feb 11, 2014
  25. Feb 01, 2014
  26. Jan 21, 2014
  27. Jan 14, 2014
  28. Jan 12, 2014
  29. Dec 20, 2013
  30. Dec 17, 2013
  31. Dec 14, 2013
  32. Dec 13, 2013
  33. Nov 30, 2013
  34. Nov 23, 2013
    • Kevin Harwell's avatar
      ARI: Implement device state API · ed483779
      Kevin Harwell authored
      Created a data model and implemented functionality for an ARI device state
      resource.  The following operations have been added that allow a user to
      manipulate an ARI controlled device:
      
      Create/Change the state of an ARI controlled device
      PUT    /deviceStates/{deviceName}&{deviceState}
      
      Retrieve all ARI controlled devices
      GET    /deviceStates
      
      Retrieve the current state of a device
      GET    /deviceStates/{deviceName}
      
      Destroy a device-state controlled by ARI
      DELETE /deviceStates/{deviceName}
      
      The ARI controlled device must begin with 'Stasis:'.  An example controlled
      device name would be Stasis:Example.  A 'DeviceStateChanged' event has also
      been added so that an application can subscribe and receive device change
      events.  Any device state, ARI controlled or not, can be subscribed to.
      
      While adding the event, the underlying subscription control mechanism was
      refactored so that all current and future resource subscriptions would be
      the same.  Each event resource must now register itself in order to be able
      to properly handle [un]subscribes.
      
      (issue ASTERISK-22838)
      Reported by: Matt Jordan
      Review: https://reviewboard.asterisk.org/r/3025/
      ........
      
      Merged revisions 403134 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403135 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      ed483779
Loading