Skip to content
Snippets Groups Projects
  1. Jul 23, 2009
    • Kevin P. Fleming's avatar
      Rework of T.38 negotiation and UDPTL API to address interoperability problems · 0a6e06c7
      Kevin P. Fleming authored
      Over the past couple of months, a number of issues with Asterisk
      negotiating (and successfully completing) T.38 sessions with various
      endpoints have been found. This patch attempts to address many of
      them, primarily focused around ensuring that the endpoints'
      MaxDatagram size is honored, and in addition by ensuring that T.38
      session parameter negotiation is performed correctly according to the
      ITU T.38 Recommendation.
      
      The major changes here are:
      
      1) T.38 applications in Asterisk (app_fax) only generate/receive IFP
      packets, they do not ever work with UDPTL packets. As a result of
      this, they cannot be allowed to generate packets that would overflow
      the other endpoints' MaxDatagram size after the UDPTL stack adds any
      error correction information. With this patch, the application is told
      the maximum *IFP* size it can generate, based on a calculation using
      the far end MaxDatagram size and the active error correction mode on
      the T.38 session. The same is true for sending *our* MaxDatagram size
      to the remote endpoint; it is computed from the value that the
      application says it can accept (for a single IFP packet) combined with
      the active error correction mode.
      
      2) All treatment of T.38 session parameters as 'capabilities' in
      chan_sip has been removed; these parameters are not at all like
      audio/video stream capabilities. There are strict rules to follow for
      computing an answer to a T.38 offer, and chan_sip now follows those
      rules, using the desired parameters from the application (or channel)
      that wants to accept the T.38 negotiation.
      
      3) chan_sip now stores and forwards ast_control_t38_parameters
      structures for tracking 'our' and 'their' T.38 session parameters;
      this greatly simplifies negotiation, especially for pass-through
      calls.
      
      4) Since T.38 negotiation without specifying parameters or receiving
      the final negotiated parameters is not very worthwhile, the
      AST_CONTROL_T38 control frame has been removed. A note has been added
      to UPGRADE.txt about this removal, since any out-of-tree applications
      that use it will no longer function properly until they are upgraded
      to use AST_CONTROL_T38_PARAMETERS.
      
      Review: https://reviewboard.asterisk.org/r/310/
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      0a6e06c7
  2. Jul 17, 2009
  3. Jun 30, 2009
  4. Jun 27, 2009
  5. Apr 24, 2009
    • Russell Bryant's avatar
      Convert the ast_channel data structure over to the astobj2 framework. · cba19c8a
      Russell Bryant authored
      There is a lot that could be said about this, but the patch is a big 
      improvement for performance, stability, code maintainability, 
      and ease of future code development.
      
      The channel list is no longer an unsorted linked list.  The main container 
      for channels is an astobj2 hash table.  All of the code related to searching 
      for channels or iterating active channels has been rewritten.  Let n be 
      the number of active channels.  Iterating the channel list has gone from 
      O(n^2) to O(n).  Searching for a channel by name went from O(n) to O(1).  
      Searching for a channel by extension is still O(n), but uses a new method 
      for doing so, which is more efficient.
      
      The ast_channel object is now a reference counted object.  The benefits 
      here are plentiful.  Some benefits directly related to issues in the 
      previous code include:
      
      1) When threads other than the channel thread owning a channel wanted 
         access to a channel, it had to hold the lock on it to ensure that it didn't 
         go away.  This is no longer a requirement.  Holding a reference is 
         sufficient.
      
      2) There are places that now require less dealing with channel locks.
      
      3) There are places where channel locks are held for much shorter periods 
         of time.
      
      4) There are places where dealing with more than one channel at a time becomes 
         _MUCH_ easier.  ChanSpy is a great example of this.  Writing code in the 
         future that deals with multiple channels will be much easier.
      
      Some additional information regarding channel locking and reference count 
      handling can be found in channel.h, where a new section has been added that 
      discusses some of the rules associated with it.
      
      Mark Michelson also assisted with the development of this patch.  He did the 
      conversion of ChanSpy and introduced a new API, ast_autochan, which makes it 
      much easier to deal with holding on to a channel pointer for an extended period 
      of time and having it get automatically updated if the channel gets masqueraded.
      Mark was also a huge help in the code review process.
      
      Thanks to David Vossel for his assistance with this branch, as well.  David 
      did the conversion of the DAHDIScan application by making it become a wrapper 
      for ChanSpy internally.
      
      The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
      
      Review: http://reviewboard.digium.com/r/203/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      cba19c8a
  6. Apr 02, 2009
  7. Mar 16, 2009
  8. Feb 27, 2009
  9. Feb 17, 2009
    • Russell Bryant's avatar
      Merge a large set of updates to the Asterisk indications API. · 4ec30136
      Russell Bryant authored
      This patch includes a number of changes to the indications API.  The primary
      motivation for this work was to improve stability.  The object management
      in this API was significantly flawed, and a number of trivial situations could
      cause crashes.
      
      The changes included are:
      
      1) Remove the module res_indications.  This included the critical functionality
         that actually loaded the indications configuration.  I have seen many people
         have Asterisk problems because they accidentally did not have an
         indications.conf present and loaded.  Now, this code is in the core,
         and Asterisk will fail to start without indications configuration.
      
         There was one part of res_indications, the dialplan applications, which did
         belong in a module, and have been moved to a new module, app_playtones.
      
      2) Object management has been significantly changed.  Tone zones are now
         managed using astobj2, and it is no longer possible to crash Asterisk by
         issuing a reload that destroys tone zones while they are in use.
      
      3) The API documentation has been filled out.
      
      4) The API has been updated to follow our naming conventions.
      
      5) Various bits of code throughout the tree have been updated to account
         for the API update.
      
      6) Configuration parsing has been mostly re-written.
      
      7) "Code cleanup"
      
      The code is from svn/asterisk/team/russell/indications/.
      
      Review: http://reviewboard.digium.com/r/149/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176627 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      4ec30136
  10. Nov 29, 2008
  11. Nov 25, 2008
  12. Nov 21, 2008
  13. Nov 19, 2008
  14. Nov 14, 2008
    • Mark Michelson's avatar
      Fix some refcounting in app_queue.c and change the · cf6c66de
      Mark Michelson authored
      hashing used by app_queue.c to be case-insensitive.
      This is accomplished by adding a new case-insensitive
      hashing function.
      
      This was necessary to prevent bad refcount errors
      (and potential crashes) which would occur due to the
      fact that queues were initially read from the config
      file in a case-sensitive manner. Then, when a user
      issued a CLI command or manager action, we allowed
      for case-insensitive input and used that input to 
      directly try to find the queue in the hash table. The result
      was either that we could not find a queue that was input or
      worse, we would end up hashing to a completely bogus value
      based on the input.
      
      This commit resolves the problem presented in
      issue #13703. However, that issue was reported against
      1.6.0. Since this fix introduces a behavior change, I am
      electing to not place this same fix in to the 1.6.0 or 1.6.1
      branches, and instead will opt for a change which does not
      change behavior.
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@156883 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      cf6c66de
  15. Oct 17, 2008
  16. Oct 07, 2008
  17. Aug 13, 2008
  18. Aug 11, 2008
  19. Aug 05, 2008
  20. Jul 28, 2008
  21. Jul 17, 2008
  22. Jun 28, 2008
  23. Jun 24, 2008
  24. Jun 15, 2008
  25. Jun 11, 2008
  26. Jun 05, 2008
  27. May 25, 2008
  28. May 15, 2008
  29. May 09, 2008
  30. May 05, 2008
  31. May 01, 2008
  32. Apr 29, 2008
  33. Mar 26, 2008
  34. Mar 05, 2008
Loading