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
    • Kinsey Moore's avatar
      Fix more dev-mode build issues · 9056c23b
      Kinsey Moore authored
      ........
      
      Merged revisions 419129 from http://svn.asterisk.org/svn/asterisk/branches/1.8
      ........
      
      Merged revisions 419162 from http://svn.asterisk.org/svn/asterisk/branches/11
      ........
      
      Merged revisions 419163 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419175 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      9056c23b
  2. Jul 21, 2014
  3. Jul 20, 2014
  4. Jul 18, 2014
  5. Jul 16, 2014
  6. Jul 09, 2014
  7. Jul 08, 2014
  8. Jul 07, 2014
    • Joshua Colp's avatar
      res_pjsip_dialog_info_body_generator: Add dialog-info+xml support for presence. · 534ffd84
      Joshua Colp authored
      This module implements dialog-info+xml for the purposes of presence. This means
      that phones such as Grandstreams can now subscribe to receive presence information
      for an extension.
      
      ASTERISK-21443 #close
      Reported by: Matt Jordan
      
      Review: https://reviewboard.asterisk.org/r/3705/
      ........
      
      Merged revisions 418116 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418117 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      534ffd84
    • 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
    • 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
  9. Jul 04, 2014
    • Matthew Jordan's avatar
      Remove many deprecated modules · 97834718
      Matthew Jordan authored
      Billing records are fair,
      To get paid is quite bright,
      You should really use ODBC;
      Good-bye cdr_sqlite.
      
      Microsoft did once push H.323,
      Hell, we all remember NetMeeting.
      But try to compile chan_h323 now
      And you will take quite a beating.
      
      The XMPP and SIP war was fierce,
      And in the distant fray
      Was birthed res_jabber/chan_jingle;
      But neither to stay.
      
      For everyone did care and chase what Google professed.
      "Free Internet Calling" was what devotees cried,
      But Google did change the specs so often
      That the developers were happy the day chan_gtalk died.
      
      And then there was that odd application
      Dedicated to the Polish tongue.
      app_saycountpl was subsumed by Say;
      One could say its bell was rung.
      
      To read and parse a file from the dialplan
      You could (I guess) use an application.
      app_readfile did fill that purpose, but I think
      A function is perhaps better in its creation.
      
      Barging is rude, I'm not sure why we do it.
      Inwardly, the caller will probably sigh.
      But if you really must do it,
      Don't use app_dahdibarge, use ChanSpy.
      
      We all despise the sound of tinny robots
      It makes our queues so cold.
      To control such an abomination
      It's better to not use Wait/SetMusicOnHold.
      
      It's often nice to know properties of a channel
      It makes our calls right
      We have a nice function called CHANNEL
      And so SIPCHANINFO is sent off into the night.
      
      And now things get odd;
      Apparently one could delimit with a colon
      Properties from the SIPPEER function!
      Commas are in; all others are done.
      
      Finally, a word on pipes and commas.
      We're sorry. We can't say it enough.
      But those compatibility options in asterisk.conf;
      To maintain them forever was just too tough.
      
      This patch removes:
      
      * cdr_sqlite
      * chan_gtalk
      * chan_jingle
      * chan_h323
      * res_jabber
      * app_saycountpl
      * app_readfile
      * app_dahdibarge
      
      It removes the following applications/functions:
      
      * WaitMusicOnHold
      * SetMusicOnHold
      * SIPCHANINFO
      
      It removes the colon delimiter from the SIPPEER function.
      
      Finally, it also removes all compatibility options that were configurable from
      asterisk.conf, as these all applied to compatibility with Asterisk 1.4 systems.
      
      Review: https://reviewboard.asterisk.org/r/3698/
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418019 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      97834718
  10. Jul 03, 2014
  11. Jul 02, 2014
  12. Jul 01, 2014
  13. Jun 30, 2014
  14. Jun 27, 2014
  15. Jun 26, 2014
  16. Jun 25, 2014
  17. Jun 23, 2014
  18. Jun 20, 2014
  19. Jun 19, 2014
  20. Jun 17, 2014
  21. Jun 16, 2014
  22. Jun 15, 2014
  23. Jun 14, 2014
  24. 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
    • Kinsey Moore's avatar
      MoH: Don't restart stream on repeated start calls · 0acc6265
      Kinsey Moore authored
      Currently, music on hold will stop and then start again from the
      beginning if ast_moh_start() is called multiple times. This can happen
      if a call is put on hold repeatedly (the channel receives multiple
      HOLD control frames) and can be triggered from ARI by starting MoH on a
      channel multiple times. This is fairly jarring/annoying to users.
      
      This change prevents MoH from being restarted if the requested music
      class is the same as the one currently playing.
      
      Review: https://reviewboard.asterisk.org/r/3615/
      ........
      
      Merged revisions 416150 from http://svn.asterisk.org/svn/asterisk/branches/1.8
      ........
      
      Merged revisions 416151 from http://svn.asterisk.org/svn/asterisk/branches/11
      ........
      
      Merged revisions 416152 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416153 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      0acc6265
Loading