Skip to content
Snippets Groups Projects
  1. Feb 21, 2015
  2. Feb 20, 2015
  3. Feb 19, 2015
  4. Feb 17, 2015
    • Richard Mudgett's avatar
      res_pjsip_refer: Fix crash from a REFER and BYE collision. · 09bfe4b2
      Richard Mudgett authored
      Analyzing a one-off crash on a busy system showed that processing a REFER
      request had a NULL session channel pointer.  The only way I can think of
      that could cause this is if an outgoing BYE transaction overlapped the
      incoming REFER transaction in a collision.  Asterisk sends a BYE while the
      phone sends a REFER to complete an attended transfer.
      
      * Made check the session channel pointer before processing an incoming
      REFER request in res_pjsip_refer.
      
      * Fixed similar crash potential for res_pjsip supplement incoming request
      processing for res_pjsip_sdp_rtp INFO, res_pjsip_caller_id INVITE/UPDATE,
      res_pjsip_messaging MESSAGE, and res_pjsip_send_to_voicemail REFER
      messages.
      
      * Made res_pjsip_messaging respond to a message body too large with a 413
      instead of ignoring it.
      
      ASTERISK-24700 #close
      Reported by: Zane Conkle
      
      Review: https://reviewboard.asterisk.org/r/4417/
      ........
      
      Merged revisions 431898 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431899 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      09bfe4b2
  5. Feb 16, 2015
  6. Feb 15, 2015
  7. Feb 14, 2015
  8. Feb 13, 2015
    • Richard Mudgett's avatar
      res_pjsip_session: Fix double re-INVITE collision crash. · f00ebf0a
      Richard Mudgett authored
      A multi-asterisk box setup with direct media enabled would occasionally
      crash when two re-INVITE collisions on a call leg happen in a row.
      
      The re-INVITE logic only had one timer struct to defer the re-INVITE.
      When the second collision happens the timer struct is overwritten and put
      into the timer heap again.  Resources for the first timer are leaked and
      the heap has two positions occupied by the same timer struct.  Now the
      heap ordering is potentially corrupted, the timer will fire twice, and any
      resources allocated for the second timer will be released twice.
      
      * The solution is to put the collided re-INVITE into the delayed requests
      queue with all the other delayed requests and cherry pick the next request
      that can come off the queue when an event happens.
      
      * Changed to put delayed BYE requests at the head of the delayed queue.
      There is no sense in processing delayed UPDATEs and re-INVITEs when a BYE
      has been requested.
      
      * Made the start of a BYE request flush the delayed requests queue to
      prevent a delayed request from overlapping the BYE transaction.  I saw a
      few cases where a delayed re-INVITE got started after the BYE transaction
      started.
      
      * Changed the delayed_request struct to use an enum instead of a string
      for the request method.  Cherry picking the queue is easier with an enum
      than string comparisons and the compiler can warn if a switch statement
      does not cover all defined enum values.
      
      * Improved the debug output to give more information.  It helps to know
      which channel is involved with an endpoint.  Trunks can have many channels
      associated with the endpoint at the same time.
      
      ASTERISK-24727 #close
      Reported by: Mark Michelson
      
      Review: https://reviewboard.asterisk.org/r/4414/
      ........
      
      Merged revisions 431734 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431735 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      f00ebf0a
  9. Feb 12, 2015
    • Matthew Jordan's avatar
      ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis app · 29f66b04
      Matthew Jordan authored
      This patch adds a new feature to ARI to redirect a channel to another server,
      and fixes a few bugs in PJSIP's handling of the Transfer dialplan
      application/ARI redirect capability.
      
      *New Feature*
      A new operation has been added to the ARI channels resource, redirect. With
      this, a channel in a Stasis application can be redirected to another endpoint
      of the same underlying channel technology.
      
      *Bug fixes*
      In the process of writing this new feature, two bugs were fixed in the PJSIP
      stack:
      (1) The existing .transfer channel callback had the limitation that it could
          only transfer channels to a SIP URI, i.e., you had to pass
          'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is
          still supported, it is somewhat unintuitive - particularly in a world full
          of endpoints. As such, we now also support specifying the PJSIP endpoint to
          transfer to.
      (2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by
          updating its Contact header. Alas, that resulted in the forwarding
          destination set by the dialplan application/ARI resource/whatever being
          rewritten with very incorrect information. Hence, we now don't bother
          updating an outgoing response if it is a 302. Since this took a looong time
          to find, some additional debug statements have been added to those modules
          that update the Contact headers.
      
      Review: https://reviewboard.asterisk.org/r/4316/
      
      ASTERISK-24015 #close
      Reported by: Private Name
      
      ASTERISK-24703 #close
      Reported by: Matt Jordan
      ........
      
      Merged revisions 431717 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      29f66b04
  10. Feb 11, 2015
  11. Feb 10, 2015
    • George Joseph's avatar
      res_pjsip_config_wizard: Add ability to auto-create hints. · 49161d8d
      George Joseph authored
      Looking at the Super Awesome Company sample reminded me that creating hints is 
      just plain gruntwork.  So you can now have the pjsip conifg wizard auto-create 
      them for you.
      
      Specifying 'hint_exten' in the wizard will create 
      'exten => <hint_exten>,hint/PJSIP/<wizard_id>'
      in whatever is specified for 'hint_context'.
      
      Specifying 'hint_application' in the wizard will create
      'exten => <hint_exten>,1,<hint_application>'
      in whatever is specified for 'hint_context'.
      
      The default for 'hint_context' is the endpoint's context.
      There's no default for 'hint_application'.  If not specified, no app is added.
      There's no default for 'hint_exten'.  If not specified, neither the hint itself 
      nor the application will be created.
      
      Some may think this is the slippery slope to users.conf but hints are a basic 
      necessity for phones unlike voicemail, manager, etc that users.conf creates.
      
      Tested-by: George Joseph
      Review: https://reviewboard.asterisk.org/r/4383/
      ........
      
      Merged revisions 431643 from http://svn.asterisk.org/svn/asterisk/branches/13
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431644 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      49161d8d
  12. Feb 09, 2015
  13. Feb 08, 2015
  14. Feb 06, 2015
  15. Feb 04, 2015
  16. Jan 31, 2015
Loading