Skip to content
Snippets Groups Projects
  1. Apr 21, 2011
  2. Apr 18, 2011
    • Richard Mudgett's avatar
      Problems with ISDN MWI to phones. · 37274c73
      Richard Mudgett authored
      The "controlling user number" is always the number of the voice mail box
      which is identical with the subscriber number itself.  This number which
      is listed in the ISDN phone MWI menu cannot be called back to contact the
      voice mail box.  The controlling user number should be made configurable.
      
      JIRA ABE-2738
      JIRA SWP-2846
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@314116 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      37274c73
  3. 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
  4. Apr 13, 2011
  5. Apr 05, 2011
  6. Mar 31, 2011
  7. Mar 17, 2011
  8. Mar 07, 2011
  9. Mar 04, 2011
  10. Feb 24, 2011
  11. 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
  12. Feb 10, 2011
  13. Feb 08, 2011
  14. Feb 07, 2011
  15. Feb 04, 2011
    • Richard Mudgett's avatar
      Add ISDN display ie text handling options to chan_dahdi.conf. · a8aeb04a
      Richard Mudgett authored
      The display ie handling can be controlled independently in the send and
      receive directions with the following options:
      
      * Block display text data.
      
      * Use display text in SETUP/CONNECT messages for name.
      
      * Use display text for COLP name updates (FACILITY/NOTIFY as appropriate).
      
      * Pass arbitrary display text during a call.  Sent in INFORMATION
      messages.  Received from any message that the display text was not used as
      a name.
      
      If the display options are not set then the options default to legacy
      behavior.
      
      The arbitrary display text is exchanged between bridged channels using the
      AST_FRAME_TEXT frame type.
      
      To send display text from the dialplan use the SendText() application when
      the arbitrary display text option is enabled.
      
      JIRA SWP-2688
      JIRA ABE-2693
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306396 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      a8aeb04a
  16. Feb 03, 2011
  17. Feb 02, 2011
  18. Feb 01, 2011
  19. Jan 31, 2011
  20. Jan 27, 2011
  21. Jan 26, 2011
  22. Jan 20, 2011
  23. Jan 19, 2011
  24. Jan 17, 2011
  25. Jan 13, 2011
  26. Jan 11, 2011
  27. Jan 04, 2011
  28. Dec 31, 2010
  29. Dec 21, 2010
  30. Dec 17, 2010
  31. Dec 08, 2010
  32. Nov 22, 2010
  33. Nov 18, 2010
  34. Nov 17, 2010
  35. Nov 08, 2010
Loading