Skip to content
Snippets Groups Projects
  1. Apr 14, 2011
    • Richard Mudgett's avatar
      Add Device State Information CCSS for Generic Devices. · ae2926b5
      Richard Mudgett authored
      Add Asterisk Device State information and callbacks to the Call Completion
      Supplemental Services for generic agents.
      
      There are currently not many devices that have native support for CCSS.
      Even as the devices become available there may be other reasons why one
      may choose to not take advantage of the native abilities and stick with
      the generic implementation.  The generic implementation is quite capable
      and could be greatly enhanced by adding device state capabilities.  A
      phone could then subscribe to the device state with a BLF key in
      conjunction with Asterisk hints.
      
      The advantages of the device state information would allow a single button
      to: request CCSS, cancel a CCSS request, and display the current state of
      a CCSS request.
      
      For example, you may have a single button that when not lit, there is no
      active CCSS request.  When you press that button, the dialplan can query
      the DEVICE_STATE() associated with that caller to determine whether they
      should be calling CallCompletionRequest() or CallCompletionCancel().  If
      there is currently a pending request, then the dialplan would cancel it.
      This also has the advantage of showing the true state of a request, which
      is an asynchronous call, even when CallCompletionRequest() thinks it was
      successful.  The actual request could ultimately fail.  Once lit, further
      feedback can be provided to the caller about the current state of their
      request since it will be updated by the CCSS State Machine as appropriate.
      
      The DEVICE_STATE mapping is configurable since the BLF being used on a
      given phone type may vary.  The idea is to allow some level of
      customization as to the phone's behavior.
      
      As an example, you may want the BLF key to go solid once you have
      requested a callback.  You may then want the LED to blink (typically
      ringing) when either the callback is in process, which is a visual
      indication that the incoming call is the desired callback.  You may want
      it to blink when the callee is ready but you are busy, giving you a visual
      indication that the target is available as you may want to get off the
      line so that the callback can be successful.
      
      Device state information is sent back via the ast_devstate_prov_add()
      callback for any generic CCSS device as it traverses through the state
      machine.  You simply provide a map between CC_STATE values and the
      corresponding AST_DEVICE state values.
      
      You could then generate hints against these states similar to what is
      possible today with Custom Devstates or MeetMe states.  For example, you
      may have an extension 3000 that is currently associated with device
      SIP/3000.  You could then create a feature code for that extension that
      may look something like:
      
      exten => *823000,hint,ccss:sip/3000
      
      You would then subscribe a BLF button to *823000 which would point to the
      dialplan that handled CCSS requests/cancels using the available
      DEVICE_STATE() information about ccss:sip/3000 to make the decision about
      what to do.
      
      (closes issue #18788)
      Reported by: p_lindheimer
      Patches:
            ccss.trunk.18788.patch uploaded by p lindheimer (license 558)
            Modified with final reviewboard comments.
      Tested by: p_lindheimer, loloski
      
      Review: https://reviewboard.asterisk.org/r/1105/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@313744 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      ae2926b5
  2. Apr 13, 2011
    • Richard Mudgett's avatar
      Merged revisions 313588 via svnmerge from · c16d39ea
      Richard Mudgett authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ................
        r313588 | rmudgett | 2011-04-13 11:31:50 -0500 (Wed, 13 Apr 2011) | 55 lines
        
        Merged revisions 313579 via svnmerge from 
        https://origsvn.digium.com/svn/asterisk/branches/1.6.2
        
        ................
          r313579 | rmudgett | 2011-04-13 11:29:49 -0500 (Wed, 13 Apr 2011) | 48 lines
          
          Merged revisions 313545 via svnmerge from 
          https://origsvn.digium.com/svn/asterisk/branches/1.4
          
          ........
            r313545 | rmudgett | 2011-04-13 11:21:24 -0500 (Wed, 13 Apr 2011) | 41 lines
            
            Asterisk does not hangup a channel after endpoint hangs up.
            
            If the call that the dialplan started an AGI script for is hungup while
            the AGI script is in the middle of a command then the AGI script is not
            notified of the hangup.  There are many AGI Exec commands that this can
            happen with.  The reported applications have been: Background, Wait, Read,
            and Dial.  Also the AGI Get Data command.
            
            * Don't wait on the Asterisk channel after it has hung up.  The channel is
            likely to never need servicing again.
            
            * Restored the AGI script's ability to return the AGI_RESULT_HANGUP value
            in run_agi().  It previously only could return AGI_RESULT_SUCCESS or
            AGI_RESULT_FAILURE after the DeadAGI and AGI applications were merged.
            
            (closes issue #17954)
            Reported by: mn3250
            Patches:
                  issue17954_v1.8.patch uploaded by rmudgett (license 664)
                  issue17954_v1.6.2.patch uploaded by rmudgett (license 664)
                  issue17954_v1.4.patch uploaded by rmudgett (license 664)
            Tested by: rmudgett
            JIRA SWP-2171
            
            (closes issue #18492)
            Reported by: devmod
            Tested by: rmudgett
            JIRA SWP-2761
            
            (closes issue #18935)
            Reported by: nvitaly
            Tested by: astmiv, rmudgett
            JIRA SWP-3216
            
            (closes issue #17393)
            Reported by: siby
            Tested by: rmudgett
            JIRA SWP-2727
            
            Review: https://reviewboard.asterisk.org/r/1165/
          ........
        ................
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@313606 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      c16d39ea
  3. Apr 11, 2011
  4. Apr 07, 2011
  5. Apr 05, 2011
  6. Apr 01, 2011
    • Richard Mudgett's avatar
      Merged revisions 312461 via svnmerge from · 75594e6e
      Richard Mudgett authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ........
        r312461 | rmudgett | 2011-04-01 16:31:39 -0500 (Fri, 01 Apr 2011) | 25 lines
        
        CallCompletionRequest()/CallCompletionCancel() exit non-zero if fail.
        
        The CallCompletionRequest()/CallCompletionCancel() dialplan applications
        exit nonzero on normal failure conditions.  The nonzero exit causes the
        dialplan to hangup immediately.  The dialplan author has no opportunity to
        report success/failure to the user.
        
        * Made always return zero so the dialplan can continue.
        
        * Made set CC_REQUEST_RESULT/CC_REQUEST_REASON and
        CC_CANCEL_RESULT/CC_CANCEL_REASON channel variables respectively.  Also
        documented the values set.
        
        * Reduced the warning about no core instance in CallCompletionCancel() to
        a debug message.  It is a normal event and should not be output at the
        WARNING level.
        
        (closes issue #18763)
        Reported by: p_lindheimer
        Patches:
              ccss.patch uploaded by p lindheimer (license 558) Modified
        Tested by: p_lindheimer, rmudgett
        
        JIRA SWP-3042
      ........
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@312462 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      75594e6e
    • Jonathan Rose's avatar
      New Feature for chan_dahdi. 4 length pattern matching. · 846cfa0e
      Jonathan Rose authored
      In chan_dahdi.conf, the user can now use length 4 patterns in addition to the usual length 2 patterns.  The s
      ntax remains the same and the method used to track the pattern history will only change when using the length
       4 patterns.
      
      (closes issue SWP-3250)
      Code:
              jrose
              rmudgett
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@312384 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      846cfa0e
    • Tilghman Lesher's avatar
      Merged revisions 312286,312288 via svnmerge from · 3731fd9c
      Tilghman Lesher authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ................
        r312286 | tilghman | 2011-04-01 05:44:33 -0500 (Fri, 01 Apr 2011) | 2 lines
        
        Reload must react correctly against a possibly changed table, so dropping the conditional reload flag.
      ................
        r312288 | tilghman | 2011-04-01 05:58:45 -0500 (Fri, 01 Apr 2011) | 21 lines
        
        Merged revisions 312287 via svnmerge from 
        https://origsvn.digium.com/svn/asterisk/branches/1.6.2
        
        ................
          r312287 | tilghman | 2011-04-01 05:51:24 -0500 (Fri, 01 Apr 2011) | 14 lines
          
          Merged revisions 312285 via svnmerge from 
          https://origsvn.digium.com/svn/asterisk/branches/1.4
          
          ........
            r312285 | tilghman | 2011-04-01 05:36:42 -0500 (Fri, 01 Apr 2011) | 7 lines
            
            Found some leaking file descriptors while looking at ast_FD_SETSIZE dead code.
            
            (issue #18969)
             Reported by: oej
             Patches: 
                   20110315__issue18969__14.diff.txt uploaded by tilghman (license 14)
          ........
        ................
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@312289 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      3731fd9c
  7. Mar 17, 2011
  8. Mar 16, 2011
  9. Mar 15, 2011
  10. Mar 14, 2011
  11. Mar 11, 2011
  12. Mar 10, 2011
  13. Mar 07, 2011
  14. Mar 05, 2011
  15. Mar 02, 2011
  16. Mar 01, 2011
  17. Feb 28, 2011
  18. Feb 24, 2011
  19. Feb 23, 2011
  20. Feb 22, 2011
    • David Vossel's avatar
      Media Project Phase2: SILK 8khz-24khz, SLINEAR 8khz-192khz, SPEEX 32khz, hd... · d760e81f
      David Vossel authored
      Media Project Phase2: SILK 8khz-24khz, SLINEAR 8khz-192khz, SPEEX 32khz, hd audio ConfBridge, and other stuff
      
      -Functional changes
      1. Dynamic global format list build by codecs defined in codecs.conf
      2. SILK 8khz, 12khz, 16khz, and 24khz with custom attributes defined in codecs.conf
      3. Negotiation of SILK attributes in chan_sip.
      4. SPEEX 32khz with translation
      5. SLINEAR 8khz, 12khz, 24khz, 32khz, 44.1khz, 48khz, 96khz, 192khz with translation
         using codec_resample.c
      6. Various changes to RTP code required to properly handle the dynamic format list
         and formats with attributes.
      7. ConfBridge now dynamically jumps to the best possible sample rate.  This allows
         for conferences to take advantage of HD audio (Which sounds awesome)
      8. Audiohooks are no longer limited to 8khz audio, and most effects have been
         updated to take advantage of this such as Volume, DENOISE, PITCH_SHIFT.
      9. codec_resample now uses its own code rather than depending on libresample.
      
      -Organizational changes
      Global format list is moved from frame.c to format.c
      Various format specific functions moved from frame.c to format.c
      
      Review: https://reviewboard.asterisk.org/r/1104/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@308582 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      d760e81f
    • Andrew Latham's avatar
      Use ast_debug for console logging · 736133f8
      Andrew Latham authored
      Guessed the log levels based on info that level 3
      is the soft roof.  Can we create a page / document
      to define the levels?
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@308527 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      736133f8
  21. Feb 21, 2011
  22. Feb 19, 2011
  23. Feb 15, 2011
    • Richard Mudgett's avatar
      Merged revisions 307879 via svnmerge from · b2ef13cb
      Richard Mudgett authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ........
        r307879 | rmudgett | 2011-02-15 10:13:55 -0600 (Tue, 15 Feb 2011) | 37 lines
        
        No response sent for SIP CC subscribe/resubscribe request.
        
        Asterisk does not send a response if we try to subscribe for call
        completion after we have received a 180 Ringing.  You can only subscribe
        for call completion when the call has been cleared.
        
        When we receive the 180 Ringing, for this call, its call-completion state
        is 'CC_AVAILABLE'.  If we then send a subscribe message to Asterisk, it
        trys to change the call-completion state to 'CC_CALLER_REQUESTED'.
        Because this is an invalid state change, it just ignores the message.  The
        only state Asterisk will accept our subscribe message is in the
        'CC_CALLER_OFFERED' state.
        
        Asterisk will go into the 'CC_CALLER_OFFERED' when the SIP client clears
        the call by sending a CANCEL.
        
        Asterisk should always send a response.  Even if its a negative one.
        
        
        The fix is to allow for the CCSS core to notify a CC agent that a failure
        has occurred when CC is requested.  The "ack" callback is replaced with a
        "respond" callback.  The "respond" callback has a parameter indicating
        either a successful response or a specific type of failure that may need
        to be communicated to the requester.
        
        (closes issue #18336)
        Reported by: GeorgeKonopacki
        Tested by: mmichelson, rmudgett
        
        JIRA SWP-2633
        
        (closes issue #18337)
        Reported by: GeorgeKonopacki
        Tested by: mmichelson
        
        JIRA SWP-2634
      ........
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@307883 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      b2ef13cb
  24. Feb 10, 2011
  25. Feb 09, 2011
Loading