Skip to content
Snippets Groups Projects
  1. Jan 20, 2011
  2. Jan 19, 2011
  3. Jan 18, 2011
    • Richard Mudgett's avatar
      Merged revisions 302318 via svnmerge from · 8cd1ac53
      Richard Mudgett authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ........
        r302318 | rmudgett | 2011-01-18 16:04:14 -0600 (Tue, 18 Jan 2011) | 1 line
        
        Use the expanded format type instead of plain int.
      ........
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302319 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      8cd1ac53
    • Matthew Nicholson's avatar
      Merged revisions 302314 via svnmerge from · 785e3a14
      Matthew Nicholson authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ................
        r302314 | mnicholson | 2011-01-18 15:43:21 -0600 (Tue, 18 Jan 2011) | 18 lines
        
        Merged revisions 302313 via svnmerge from 
        https://origsvn.digium.com/svn/asterisk/branches/1.6.2
        
        ................
          r302313 | mnicholson | 2011-01-18 15:40:03 -0600 (Tue, 18 Jan 2011) | 11 lines
          
          Merged revisions 302311 via svnmerge from 
          https://origsvn.digium.com/svn/asterisk/branches/1.4
          
          ........
            r302311 | mnicholson | 2011-01-18 15:35:03 -0600 (Tue, 18 Jan 2011) | 4 lines
            
            URI encode the user part of the contact header.
            
            ABE-2705
          ........
        ................
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302315 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      785e3a14
    • Jeff Peeler's avatar
      Merged revisions 302266 via svnmerge from · b1f9f1e7
      Jeff Peeler authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ................
        r302266 | jpeeler | 2011-01-18 14:19:57 -0600 (Tue, 18 Jan 2011) | 34 lines
        
        Merged revisions 302265 via svnmerge from 
        https://origsvn.digium.com/svn/asterisk/branches/1.6.2
        
        ........
          r302265 | jpeeler | 2011-01-18 14:13:52 -0600 (Tue, 18 Jan 2011) | 27 lines
          
          Convert device state callbacks to ao2 objects to fix a deadlock in chan_sip.
          
          Lock scenario presented here:
          Thread 1
           holds ast_rdlock_contexts &conlock
           holds handle_statechange hints
           holds handle_statechange hint
            waiting for cb_extensionstate
             Locked Here: chan_sip.c line 7428 (find_call)
          Thread 2
           holds handle_request_do &netlock
           holds find_call sip_pvt_ptr
            waiting for ast_rdlock_contexts &conlock
             Locked Here: pbx.c line 9911 (ast_rdlock_contexts)
          
          Chan_sip has an established locking order of locking the sip_pvt and then
          getting the context lock. So the as stated by the summary, the operations in
          thread 2 have been modified to no longer require the context lock.
          
          (closes issue #18310)
          Reported by: one47
          Patches: 
                statecbs_ao2.mk2.patch uploaded by one47 (license 23),
                modified by me
          
          Review: https://reviewboard.asterisk.org/r/1072/
        ........
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302270 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      b1f9f1e7
    • Russell Bryant's avatar
      Merged revisions 302267 via svnmerge from · 519b766c
      Russell Bryant authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ........
        r302267 | russell | 2011-01-18 14:19:57 -0600 (Tue, 18 Jan 2011) | 5 lines
        
        Don't enable AO2_DEBUG by default if AST_DEVMODE is on.
        
        AO2_DEBUG is not important and is causing a false compiler warning to be
        generated on my Ubuntu Natty dev box.
      ........
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      519b766c
    • Richard Mudgett's avatar
      Merged revisions 302174 via svnmerge from · a05aeff3
      Richard Mudgett authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ................
        r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
        
        Merged revisions 302173 via svnmerge from 
        https://origsvn.digium.com/svn/asterisk/branches/1.6.2
        
        ................
          r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
          
          Merged revisions 302172 via svnmerge from 
          https://origsvn.digium.com/svn/asterisk/branches/1.4
          
          ........
            r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
            
            Issues with DTMF triggered attended transfers.
            
            Issue #17999
            1) A calls B. B answers.
            2) B using DTMF dial *2 (code in features.conf for attended transfer).
            3) A hears MOH. B dial number C
            4) C ringing. A hears MOH.
            5) B hangup. A still hears MOH. C ringing.
            6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
            For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
            
            Problem: When A and B hangup, C is still ringing.
            
            Issue #18395
            SIP call limit of B is 1
            1. A call B, B answered
            2. B *2(atxfer) call C
            3. B hangup, C ringing
            4. Timeout waiting for C to answer
            5. Recall to B fails because B has reached its call limit.
            
            Because B reached its call limit, it cannot do anything until the transfer
            it started completes.
            
            Issue #17273
            Same scenario as issue 18395 but party B is an FXS port.  Party B cannot
            do anything until the transfer it started completes.  If B goes back off
            hook before C answers, B hears ringback instead of the expected dialtone.
            
            **********
            Note for the issue #17273 and #18395 fix:
            
            DTMF attended transfer works within the channel bridge.  Unfortunately,
            when either party A or B in the channel bridge hangs up, that channel is
            not completely hung up until the transfer completes.  This is a real
            problem depending upon the channel technology involved.
            
            For chan_dahdi, the channel is crippled until the hangup is complete.
            Either the channel is not useable (analog) or the protocol disconnect
            messages are held up (PRI/BRI/SS7) and the media is not released.
            
            For chan_sip, a call limit of one is going to block that endpoint from any
            further calls until the hangup is complete.
            
            For party A this is a minor problem.  The party A channel will only be in
            this condition while party B is dialing and when party B and C are
            conferring.  The conversation between party B and C is expected to be a
            short one.  Party B is either asking a question of party C or announcing
            party A.  Also party A does not have much incentive to hangup at this
            point.
            
            For party B this can be a major problem during a blonde transfer.  (A
            blonde transfer is our term for an attended transfer that is converted
            into a blind transfer.  :)) Party B could be the operator.  When party B
            hangs up, he assumes that he is out of the original call entirely.  The
            party B channel will be in this condition while party C is ringing, while
            attempting to recall party B, and while waiting between call attempts.
            
            WARNING:
            The ATXFER_NULL_TECH conditional is a hack to fix the problem.  It will
            replace the party B channel technology with a NULL channel driver to
            complete hanging up the party B channel technology.  The consequences of
            this code is that the 'h' extension will not be able to access any channel
            technology specific information like SIP statistics for the call.
            
            ATXFER_NULL_TECH is not defined by default.
            **********
            
            (closes issue #17999)
            Reported by: iskatel
            Tested by: rmudgett
            JIRA SWP-2246
            
            (closes issue #17096)
            Reported by: gelo
            Tested by: rmudgett
            JIRA SWP-1192
            
            (closes issue #18395)
            Reported by: shihchuan
            Tested by: rmudgett
            
            (closes issue #17273)
            Reported by: grecco
            Tested by: rmudgett
            
            Review: https://reviewboard.asterisk.org/r/1047/
          ........
        ................
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      a05aeff3
  4. Jan 17, 2011
  5. Jan 14, 2011
  6. Jan 13, 2011
  7. Jan 12, 2011
Loading