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
    • Joshua Colp's avatar
      chan_iax2: Restore previous behavior of iax2_best_codec. · 84beaf27
      Joshua Colp authored
      The iax2_best_codec function was changed to convert the formats
      into a format compatibilities structure and grab the first
      format from it. The resulting order differs from the previous
      order of iax2_best_codec which causes unexpected formats to
      get chosen (such as g723).
      
      This commit brings back the old behavior of iax2_best_codec by
      having a specified preference list.
      
      Review: https://reviewboard.asterisk.org/r/3835/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419180 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      84beaf27
  2. Jul 21, 2014
  3. Jul 20, 2014
  4. Jul 18, 2014
  5. Jul 17, 2014
    • Matthew Jordan's avatar
      chan_sip: Make progressinband=never really mean 'never' · 1ce23d45
      Matthew Jordan authored
      progressinband=never in sip.conf is easily defeated if an onward trunk sends a
      progress indication of its own. This is almost certain to happen if the onward
      trunk is ISDN or IAX as these technologies send a progress indication even if
      early media is not required. This progress message is passed to the caller,
      and causes the "never" option to be rather badly named.
      
      This patch changes the behaviour of this setting in the following ways:
      
      1) In sip_write(), do not pass the media unless we have either progressed
         beyond INV_EARLY_MEDIA, or we are in INV_EARLY_MEDIA state, and early
         media is both set-up and wanted. This helps resolve double-ringing on some
         buggy handsets.
      
      2) In sip_indicate(), if we see AST_CONTROL_PROGRESS, but
         SIP_PROG_INBAND_NEVER is set, send a 180 Ringing instead to avoid implicitly
         enabling early media. Avoid sending double ring indications.
      
      NOTE: the meaning of the SIP_PROGRESS_SENT flag changes slightly in this patch
      to also encapsulate the fact that a channel has *sent or received* a 183
      Progress indication. This makes the updated code in sip_write() much more
      simple.
      
      Review: https://reviewboard.asterisk.org/r/3700
      
      ASTERISK-23972 #close
      Reported by: Steve Davies
      patches:
        inband_never_present_early_media2 uploaded by Steve Davies (License 5012)
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      1ce23d45
  6. Jul 16, 2014
  7. Jul 10, 2014
  8. 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
  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. Jun 30, 2014
  12. Jun 26, 2014
  13. Jun 25, 2014
  14. Jun 23, 2014
    • Tzafrir Cohen's avatar
      suspended destructions of pri spans on events · 3451d6a7
      Tzafrir Cohen authored
      If a DAHDI span disappears, we wish for its representation in Asterisk
      to be destroyed as well.
      
      The information about the span's removal may come from several paths:
      
      1. DAHDI sends DAHDI_EVENT_REMOVE on every channel.
      2. An extra DAHDI_EVENT_REMOVED is sent on every subsequent call to
         DAHDI_GET_EVENT.
      3. Every read (including the internal one by libpri on the D-channel)
         returns -ENODEV.
      
      Asterisk responsds to DAHDI_EVENT_REMOVE on a channel by destroying it.
      
      Destroying a channel requires holding the channel list lock (iflock).
      Destroying a channel that is part of a span requires holding the span's
      lock. Destroying a channel from a context that holds the span lock,
      while at the same time another channel is destroyed directly, leads to a
      deadlock. Solution: don't destroy span while holding the channels list
      lock.
      
      Thus changes in this patch:
      * Deferring removal of PRI spans in response to events: doomed spans
        are collected on a list.
      * Doomed spans are removed periodically by the monitor thread.
      * ENODEV reads from the D-channel will warant the same deferred removal.
      
      Review: https://reviewboard.asterisk.org/r/3548/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417059 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      3451d6a7
  15. Jun 19, 2014
  16. Jun 16, 2014
    • Richard Mudgett's avatar
      chan_dahdi: Adds support for major update to libss7. · 0c896d8b
      Richard Mudgett authored
      * SS7 support now requires libss7 v2.0 or later.  The new libss7 is not
      backwards compatible.
      
      * Added SS7 support for connected line and redirecting.
      
      * Most SS7 CLI commands are reworked as well as new SS7 commands added.
      See online CLI help.
      
      * Added several SS7 config option parameters described in
      chan_dahdi.conf.sample.
      
      * ISUP timer support reworked and now requires explicit configuration.
      See ss7.timers.sample.
      
      Special thanks to Kaloyan Kovachev for his support and persistence in
      getting the original patch by adomjan updated and ready for release.
      
      SS7-27 #close
      Reported by: adomjan
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416416 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      0c896d8b
    • Matthew Jordan's avatar
      channels/chan_sip: Forbid remote bridging if T.38 is negotiated · 8313964d
      Matthew Jordan authored
      When a framehook is removed - such as the fax gateway framehook - the bridge
      framework will re-evaluate the bridge mixing technologies to see if it can
      improve the bridging. When this occurs, get_rtp_info will be called to
      determine if local or remote bridging can be used. Using remote bridging
      will cause a fax to fail, as direct media negotiation will cause some small
      number of packets to not arrive at the remote endpoint.
      
      This patch forces local native bridging if T.38 negotiation is in progress or
      has been established.
      ........
      
      Merged revisions 416318 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416319 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      8313964d
  17. Jun 13, 2014
  18. Jun 12, 2014
    • Richard Mudgett's avatar
      AST-2014-007: Fix DOS by consuming the number of allowed HTTP connections. · 4ca5745d
      Richard Mudgett authored
      Simply establishing a TCP connection and never sending anything to the
      configured HTTP port in http.conf will tie up a HTTP connection.  Since
      there is a maximum number of open HTTP sessions allowed at a time you can
      block legitimate connections.
      
      A similar problem exists if a HTTP request is started but never finished.
      
      * Added http.conf session_inactivity timer option to close HTTP
      connections that aren't doing anything.  Defaults to 30000 ms.
      
      * Removed the undocumented manager.conf block-sockets option.  It
      interferes with TCP/TLS inactivity timeouts.
      
      * AMI and SIP TLS connections now have better authentication timeout
      protection.  Though I didn't remove the bizzare TLS timeout polling code
      from chan_sip.
      
      * chan_sip can now handle SSL certificate renegotiations in the middle of
      a session.  It couldn't do that before because the socket was non-blocking
      and the SSL calls were not restarted as documented by the OpenSSL
      documentation.
      
      * Fixed an off nominal leak of the ssl struct in
      handle_tcptls_connection() if the FILE stream failed to open and the SSL
      certificate negotiations failed.
      
      The patch creates a custom FILE stream handler to give the created FILE
      streams inactivity timeout and timeout after a specific moment in time
      capability.  This approach eliminates the need for code using the FILE
      stream to be redesigned to deal with the timeouts.
      
      This patch indirectly fixes most of ASTERISK-18345 by fixing the usage of
      the SSL_read/SSL_write operations.
      
      ASTERISK-23673 #close
      Reported by: Richard Mudgett
      ........
      
      Merged revisions 415841 from http://svn.asterisk.org/svn/asterisk/branches/1.8
      ........
      
      Merged revisions 415854 from http://svn.asterisk.org/svn/asterisk/branches/11
      ........
      
      Merged revisions 415896 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415907 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      4ca5745d
  19. Jun 06, 2014
  20. Jun 05, 2014
  21. Jun 04, 2014
  22. May 28, 2014
    • Matthew Jordan's avatar
      Logger/CLI/etc.: Fix some aesthetic issues; reduce chatty verbose messages · fb5690ce
      Matthew Jordan authored
      This patch addresses some aesthetic issues in Asterisk. These are all just
      minor tweaks to improve the look of the CLI when used in a variety of
      settings. Specifically:
       * A number of chatty verbose messages were removed or demoted to DEBUG
         messages. Verbose messages with a verbosity level of 5 or higher were -
         if kept as verbose messages - demoted to level 4. Several messages
         that were emitted at verbose level 3 were demoted to 4, as announcement
         of dialplan applications being executed occur at level 3 (and so the
         effects of those applications should generally be less).
       * Some verbose messages that only appear when their respective 'debug'
         options are enabled were bumped up to always be displayed.
       * Prefix/timestamping of verbose messages were moved to the verboser
         handlers. This was done to prevent duplication of prefixes when the
         timestamp option (-T) is used with the CLI.
       * Verbose magic is removed from messages before being emitted to
         non-verboser handlers. This prevents the magic in multi-line verbose
         messages (such as SIP debug traces or the output of DumpChan) from
         being written to files.
       * _Slightly_ better support for the "light background" option (-W) was
         added. This includes using ast_term_quit in the output of XML
         documentation help, as well as changing the "Asterisk Ready" prompt to
         bright green on the default background (which stands a better chance of
         being displayed properly than bright white).
      
      Review: https://reviewboard.asterisk.org/r/3547/
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414798 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      fb5690ce
    • Walter Doekes's avatar
      chan_unistim: Unlock mutex in rare OOM condition. · e5194c91
      Walter Doekes authored
      #ASTERISK-23792 #close
      Reported by: Peter Whisker
      
      Review: https://reviewboard.asterisk.org/r/3567/
      ........
      
      Merged revisions 414677 from http://svn.asterisk.org/svn/asterisk/branches/11
      ........
      
      Merged revisions 414678 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414679 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      e5194c91
  23. May 27, 2014
  24. May 22, 2014
  25. May 16, 2014
  26. May 13, 2014
Loading