Skip to content
Snippets Groups Projects
  1. Jan 06, 2014
  2. Jan 05, 2014
  3. Jan 04, 2014
  4. Jan 03, 2014
  5. Jan 02, 2014
  6. Dec 31, 2013
  7. Dec 30, 2013
  8. Dec 24, 2013
  9. Dec 23, 2013
  10. Dec 21, 2013
  11. Dec 20, 2013
  12. Dec 19, 2013
    • Scott Griepentrog's avatar
      security_events: log events with descriptive names · efd7c407
      Scott Griepentrog authored
      This patch updates the log messages to include descriptive
      names for event types.  This is an improvement over having
      only cryptic type numbers.
      
      (closes issue ASTERISK-22909)
      Reported by: outtolunc
      Review: https://reviewboard.asterisk.org/r/3081/
      Patches:
           svn_security_events.c.names.diff.txt uploaded by outtolunc (license 5198)
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404387 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      efd7c407
    • Richard Mudgett's avatar
      Put notice in CHANGES as well as UPGRADE.txt. · dbead14c
      Richard Mudgett authored
      ........
      
      Merged revisions 404375 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404376 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      dbead14c
    • Joshua Colp's avatar
      res_pjsip: Ignore 401/407 responses for transactions and dialogs we don't know about. · 433c6f01
      Joshua Colp authored
      Under normal conditions it is unlikely we will ever receive a response for a transaction
      or dialog we don't know about but if any are received ignore them.
      ........
      
      Merged revisions 404371 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404372 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      433c6f01
    • Joshua Colp's avatar
      res_pjsip_session: Fix SDP negotiation when resending an INVITE with authentication. · 8402cd4c
      Joshua Colp authored
      The process for resending an INVITE with authentication involves restarting the UAC
      session. We were incorrectly passing in that a new offer is being sent, causing the
      SDP negotiation to get into a (technically speaking) funky state.
      ........
      
      Merged revisions 404369 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404370 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      8402cd4c
    • Mark Michelson's avatar
      Fix a deadlock that occurred due to a conflict of masquerades. · 1b91ee6c
      Mark Michelson authored
      For the explanation, here is a copy-paste of the review board explanation:
      
      Initially, it was discovered that performing an attended transfer of a
      multiparty bridge with a PJSIP channel would cause a deadlock. A PBX thread
      started a masquerade and reached the point where it was calling the fixup()
      callback on the "original" channel. For chan_pjsip, this involves pushing a
      synchronous task to the session's serializer. The problem was that a task ahead
      of the fixup task was also attempting to perform a channel masquerade. However,
      since masquerades are designed in a way to only allow for one to occur at a
      time, the task ahead of the fixup could not continue until the masquerade
      already in progress had completed. And of course, the masquerade in progress
      could not complete until the task ahead of the fixup task had completed.
      Deadlock.
      
      The initial fix was to change the fixup task to be asynchronous. While this
      prevented the deadlock from occurring, it had the frightful side effect of
      potentially allowing for tasks in the session's serializer to operate on a
      zombie channel.
      
      Taking a step back from this particular deadlock, it became clear that the
      problem was not really this one particular issue but that masquerades
      themselves needed to be addressed. A PJSIP attended transfer operation calls
      ast_channel_move(), which attempts to both set up and execute a masquerade. The
      problem was that after it had set up the masquerade, the PBX thread had swooped
      in and tried to actually perform the masquerade. Looking at changes that had
      been made to Asterisk 12, it became clear that there never is any time now that
      anyone ever wants to set up a masquerade and allow for the channel thread to
      actually perform the masquerade. Everyone always is calling ast_channel_move(),
      performs the masquerade itself before returning.
      
      In this patch, I have removed all blocks of code from channel.c that will
      attempt to perform a masquerade if ast_channel_masq() returns true. Now, there
      is no distinction between setting up a masquerade and performing the
      masquerade. It is one operation. The only remaining checks for
      ast_channel_masq() and ast_channel_masqr() are in ast_hangup() since we do not
      want to interrupt a masquerade by hanging up the channel. Instead, now
      ast_hangup() will wait for a masquerade to complete before moving forward with
      its operation.
      
      The ast_channel_move() function has been modified to basically in-line the
      logic that used to be in ast_channel_masquerade(). ast_channel_masquerade() has
      been killed off for real. ast_channel_move() now has a lock associated with it
      that is used to prevent any simultaneous moves from occurring at once. This
      means there is no need to make sure that ast_channel_masq() or
      ast_channel_masqr() are already set on a channel when ast_channel_move() is
      called. It also means the channel container lock is not pulling double duty by
      both keeping the container locked and preventing multiple masquerades from
      occurring simultaneously.
      
      The ast_do_masquerade() function has been renamed to do_channel_masquerade()
      and is now internal to channel.c. The function now takes explicit arguments of
      which channels are involved in the masquerade instead of a single channel.
      While it probably is possible to do some further refactoring of this method, I
      feel that I would be treading dangerously. Instead, all I did was change some
      comments that no longer are true after this changeset.
      
      The other more minor change introduced in this patch is to res_pjsip.c to make
      ast_sip_push_task_synchronous() run the task in-place if we are already a SIP
      servant thread. This is related to this patch because even when we isolate the
      channel masquerade to only running in the SIP servant thread, we would still
      deadlock when the fixup() callback is reached since we would essentially be
      waiting forever for ourselves to finish before actually running the fixup. This
      makes it so the fixup is run without having to push a task into a serializer at
      all.
      
      (closes issue ASTERISK-22936)
      Reported by Jonathan Rose
      
      Review: https://reviewboard.asterisk.org/r/3069
      ........
      
      Merged revisions 404356 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404368 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      1b91ee6c
Loading