Skip to content
Snippets Groups Projects
  1. Aug 02, 2013
  2. Aug 01, 2013
  3. Jul 15, 2013
    • Richard Mudgett's avatar
      Replace chan_agent with app_agent_pool. · d43b17a8
      Richard Mudgett authored
      The ill conceived chan_agent is no more.  It is now replaced by
      app_agent_pool.
      
      Agents login using the AgentLogin() application as before.  The
      AgentLogin() application no longer does any authentication.
      Authentication is now the responsibility of the dialplan.  (Besides, the
      authentication done by chan_agent did not match what the voice prompts
      asked for.)
      
      Sample extensions.conf
      [login]
      ; Sample agent 1001 login
      ; Set COLP for in between calls so the agent does not see the last caller COLP.
      exten => 1001,1,Set(CONNECTEDLINE(all)="Agent Waiting" <1001>)
      ; Give the agent DTMF transfer and disconnect features when connected to a caller.
      same => n,Set(CHANNEL(dtmf-features)=TX)
      same => n,AgentLogin(1001)
      same => n,NoOp(AGENT_STATUS is ${AGENT_STATUS})
      same => n,Hangup()
      
      [caller]
      ; Sample caller direct connect to agent 1001
      exten => 800,1,AgentRequest(1001)
      same => n,NoOp(AGENT_STATUS is ${AGENT_STATUS})
      same => n,Hangup()
      
      ; Sample caller going through a Queue to agent 1001
      exten => 900,1,Queue(agent_q)
      same => n,Hangup()
      
      Sample queues.conf
      [agent_q]
      member => Local/800@caller,,SuperAgent,Agent:1001
      
      Under the hood operation overview:
      1) Logged in agents wait for callers in an agents holding bridge.
      2) Caller requests an agent using AgentRequest()
      3) A basic bridge is created, the agent is notified, and caller joins the
         basic bridge to wait for the agent.
      4) The agent is either automatically connected to the caller or must ack
         the call to connect.
      5) The agent is moved from the agents holding bridge to the basic bridge.
      6) The agent and caller talk.
      7) The connection is ended by either party.
      8) The agent goes back to the agents holding bridge.
      
      To avoid some locking issues with the agent holding bridge, I needed to
      make some changes to the after bridge callback support.  The after bridge
      callback is now a list of requested callbacks with the last to be added
      the only active callback.  The after bridge callback for failed callbacks
      will always happen in the channel thread when the channel leaves the
      bridging system or is destroyed.
      
      (closes issue ASTERISK-21554)
      Reported by: Matt Jordan
      
      Review: https://reviewboard.asterisk.org/r/2657/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394417 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      d43b17a8
  4. Jul 04, 2013
  5. Jul 03, 2013
  6. Jun 17, 2013
    • Matthew Jordan's avatar
      Update Asterisk's CDRs for the new bridging framework · 6258bbe7
      Matthew Jordan authored
      This patch is the initial push to update Asterisk's CDR engine for the new
      bridging framework. This patch guts the existing CDR engine and builds the new
      on top of messages coming across Stasis. As changes in channel state and bridge
      state are detected, CDRs are built and dispatched accordingly. This
      fundamentally changes CDRs in a few ways.
      (1) CDRs are now *very* reflective of the actual state of channels and bridges.
          This means CDRs track well with what an actual channel is doing - which
          is useful in transfer scenarios (which were previously difficult to pin
          down). It does, however, mean that CDRs cannot be 'fooled'. Previous
          behavior in Asterisk allowed for CDR applications, channels, and other
          properties to be spoofed in parts of the code - this no longer works.
      (2) CDRs have defined behavior in multi-party scenarios. This behavior will not
          be what everyone wants, but it is a defined behavior and as such, it is
          predictable.
      (3) The CDR manipulation functions and applications have been overhauled. Major
          changes have been made to ResetCDR and ForkCDR in particular. Many of the
          options for these two applications no longer made any sense with the new
          framework and the (slightly) more immutable nature of CDRs.
      
      There are a plethora of other changes. For a full description of CDR behavior,
      see the CDR specification on the Asterisk wiki.
      
      (closes issue ASTERISK-21196)
      
      Review: https://reviewboard.asterisk.org/r/2486/
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      6258bbe7
  7. Jun 10, 2013
    • Matthew Jordan's avatar
      Add announce-to-first-user option for app_queue · c2e29abc
      Matthew Jordan authored
      In r386792, the ability to play prompts to the first caller in a call queue was
      added. While this is arguably a bug fix for those who expect the first caller
      to continue receiving prompts while the agent is dialed, it has the side effect
      of preventing the first caller from hearing the agent immediately upon
      bridging. This may not be a problem for those who really want this option, but
      for those who didn't care whether or not the first caller in queue heard their
      position, it was an issue.
      
      This patch disables the ability for the first caller in the queue to hear
      prompts and adds a new option, announce-to-first-user, to queues.conf. Those
      who the behavior can enable it by setting this value to True.
      
      Note that if we ever implement the ability to have the prompts be stopped
      upon bridging, this option can be removed.
      
      (closes issue ASTERISK-21782)
      Reported by: Remi Quezada
      ........
      
      Merged revisions 391215 from http://svn.asterisk.org/svn/asterisk/branches/1.8
      ........
      
      Merged revisions 391241 from http://svn.asterisk.org/svn/asterisk/branches/11
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391245 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      c2e29abc
  8. Jun 06, 2013
    • Richard Mudgett's avatar
      Reimplement bridging and DTMF features related channel variables in the bridging core. · bad8caa8
      Richard Mudgett authored
      * The channel variable ATTENDED_TRANSFER_COMPLETE_SOUND is no longer
      channel driver specific.  If the channel variable is set on the
      transferrer channel, the sound will be played to the target of an attended
      transfer.
      
      * The channel variable BRIDGEPEER becomes a comma separated list of peers
      in a multi-party bridge.  The BRIDGEPEER value can have a maximum of 10
      peers listed.  Any more peers in the bridge will not be included in the
      list.  BRIDGEPEER is not valid in holding bridges like parking since those
      channels do not talk to each other even though they are in a bridge.
      
      * The channel variable BRIDGEPVTCALLID is only valid for two party bridges
      and will contain a value if the BRIDGEPEER's channel driver supports it.
      
      * The channel variable DYNAMIC_PEERNAME is redundant with BRIDGEPEER and
      is removed.  The more useful DYNAMIC_WHO_ACTIVATED gives the channel name
      that activated the dynamic feature.
      
      * The channel variables DYNAMIC_FEATURENAME and DYNAMIC_WHO_ACTIVATED are
      set only on the channel executing the dynamic feature.  Executing a
      dynamic feature on the bridge peer in a multi-party bridge will execute it
      on all peers of the activating channel.
      
      (closes issue ASTERISK-21555)
      Reported by: Matt Jordan
      
      Review: https://reviewboard.asterisk.org/r/2582/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      bad8caa8
  9. May 21, 2013
  10. Apr 03, 2013
  11. Jan 18, 2013
  12. Jan 14, 2013
    • Automerge script's avatar
      Merged revisions 379021,379023 via svnmerge from · 0d3dfad9
      Automerge script authored
      file:///srv/subversion/repos/asterisk/trunk
      
      ................
        r379021 | dlee | 2013-01-14 09:29:22 -0600 (Mon, 14 Jan 2013) | 15 lines
        
        Fix XML encoding of 'identity display' in NOTIFY messages, continued.
        
        When r378933 was merged into 1.8, it should have also escaped
        remote_display, since it will have the same XML encoding problem when
        the caller/callee roles are reversed.
        
        (closes issue ABE-2902)
        Reported by: Guenther Kelleter
        ........
        
        Merged revisions 379001 from http://svn.asterisk.org/svn/asterisk/branches/1.8
        ........
        
        Merged revisions 379020 from http://svn.asterisk.org/svn/asterisk/branches/11
      ................
        r379023 | dlee | 2013-01-14 09:58:01 -0600 (Mon, 14 Jan 2013) | 20 lines
        
        Masquerades are an insane implementation detail within Asterisk. It generates
        a number of useless and confusing events, and manipulates channels in a way
        that semantically doesn't make sense. I've given a fairly thorough review of
        masquerade code and its usage on the wiki at
        https://wiki.asterisk.org/wiki/x/IwBRAQ.
        
        While ultimately it makes the most sense to abandon masquerades altogether,
        it will take some time to completely irradicate. Even then, there may always
        be code that's not worth rewriting to get rid of the masquerade.
        
        This patch does two things to make masquerades slightly less insane:
         * When swapping the names of the original and clone channel, only emit a
           single rename event of original -> original<ZOMBIE>. The original code
           issued three rename events to accomplish the same end.
         * In addition to swapping the names of the channels, also swap their
           uniqueid's. This allows the 'Uniqueid' field to be used as a stable
           identifier for a channel from and external interface, such as AMI.
        
        Review: https://reviewboard.asterisk.org/r/2266/
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/team/mmichelson/threadpool@379032 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      0d3dfad9
    • David M. Lee's avatar
      Gently reduce masquerade insanity · d3bb2506
      David M. Lee authored
      Masquerades are an insane implementation detail within Asterisk. It generates
      a number of useless and confusing events, and manipulates channels in a way
      that semantically doesn't make sense. I've given a fairly thorough review of
      masquerade code and its usage on the wiki at
      https://wiki.asterisk.org/wiki/x/IwBRAQ.
      
      While ultimately it makes the most sense to abandon masquerades altogether,
      it will take some time to completely irradicate. Even then, there may always
      be code that's not worth rewriting to get rid of the masquerade.
      
      This patch does two things to make masquerades slightly less insane:
       * When swapping the names of the original and clone channel, only emit a
         single rename event of original -> original<ZOMBIE>. The original code
         issued three rename events to accomplish the same end.
       * In addition to swapping the names of the channels, also swap their
         uniqueid's. This allows the 'Uniqueid' field to be used as a stable
         identifier for a channel from and external interface, such as AMI.
      
      Review: https://reviewboard.asterisk.org/r/2266/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@379023 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      d3bb2506
  13. Jan 09, 2013
  14. Jan 08, 2013
    • Richard Mudgett's avatar
      app_queue: Fix multiple calls to a queue member that is in only one queue. · 8ed2c74f
      Richard Mudgett authored
      When ringinuse=no queue members can receive more than one call if these
      calls happen at nearly the same time.
      
      * Fix so a queue member does not receive more than one call from a queue.
      
      NOTE: This fix does not prevent multiple calls to a member if the member
      is in more than one queue.
      
      * Did some refactoring to eliminate some code redundancy.
      
      (issue ASTERISK-16115)
      Reported by: nik600
      Patches:
            jira_asterisk_16115_single_q_v1.8.patch (license #5621) patch uploaded by rmudgett
            Modified
      
      * Revert the -r341580 and -r341599 changes adding the queues.conf
      check_state_unknown option as it was added in an attempt to fix this
      problem.  The fix did not need to be optional.  The fix should not have
      tried to explicitly set the device state.  Setting the device state by
      something other than the device introduces a race condition.  I also could
      not see how the change would be effective other than delaying the
      app_queue code long enough for the device state to propagate to app_queue.
      ........
      
      Merged revisions 378663 from http://svn.asterisk.org/svn/asterisk/branches/1.8
      ........
      
      Merged revisions 378683 from http://svn.asterisk.org/svn/asterisk/branches/10
      ........
      
      Merged revisions 378687 from http://svn.asterisk.org/svn/asterisk/branches/11
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      8ed2c74f
  15. Dec 14, 2012
    • Automerge script's avatar
      Merged revisions 378063-378064 via svnmerge from · d4aeeecf
      Automerge script authored
      file:///srv/subversion/repos/asterisk/trunk
      
      ........
        r378063 | jrose | 2012-12-14 16:34:18 -0600 (Fri, 14 Dec 2012) | 8 lines
        
        Features: BRIDGE_FEATURES variable automixmonitor support and use proper party
        
        BRIDGE_FEATURES did not previously support the automixmonitor feature. Now it
        does. In addition, the BRIDGE_FEATURES variable would not apply features to
        the proper party based on whether the feature option letter was in caps or
        in lowercase (both ways would apply it to the caller). Now uppercase applies
        to the caller while lowercase applies to the callee (like with the dial option)
      ........
        r378064 | rmudgett | 2012-12-14 16:45:03 -0600 (Fri, 14 Dec 2012) | 4 lines
        
        chan_agent: Remove some duplicated code.
        
        No need to check for an agent twice.  Santa does that.
      ........
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/team/mmichelson/threadpool@378066 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      d4aeeecf
    • Jonathan Rose's avatar
      Features: BRIDGE_FEATURES variable automixmonitor support and use proper party · ae655031
      Jonathan Rose authored
      BRIDGE_FEATURES did not previously support the automixmonitor feature. Now it
      does. In addition, the BRIDGE_FEATURES variable would not apply features to
      the proper party based on whether the feature option letter was in caps or
      in lowercase (both ways would apply it to the caller). Now uppercase applies
      to the caller while lowercase applies to the callee (like with the dial option)
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378063 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      ae655031
  16. Nov 28, 2012
  17. Nov 05, 2012
  18. Oct 29, 2012
    • Mark Michelson's avatar
      Make evaluation of channel variables consistently case-sensitive. · da85f848
      Mark Michelson authored
      Due to inconsistencies in how variable names were evaluated, the
      decision was made to make all evaluations case-sensitive. See the
      UPGRADE.txt file or https://wiki.asterisk.org/wiki/display/AST/Case+Sensitivity
      for more details.
      
      (closes issue ASTERISK-20163)
      reported by Matt Jordan
      
      Review: https://reviewboard.asterisk.org/r/2160
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375442 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      da85f848
    • Matthew Jordan's avatar
      Ensure that CDRs for a caller in a Queue that is not answered is NO ANSWER. · 1eb14dbf
      Matthew Jordan authored
      When a caller enters a queue and no queue member answers the call, the current
      behaviour can be a little odd depending on the paused status of the queue
      members.  If any queue member is paused, but not all, the CDR disposition
      will be BUSY.  If all queue members are paused, then the CDR disposition is
      based instead on the disposition of the call prior to entering the Queue.
      
      This patch modifies the behaviour in the following ways:
      * If no queue members are paused, the CDR disposition is whatever the
        disposition was prior to going into Queue.  If the call was answered this
        will be ANSWERED; otherwise, it is NO ANSWER.
      * If some queue members are pused, the CDR result is NO ANSWER. (This is a
        change in behaviour, as the result would previously have been BUSY)
      * If all queue members are paused, the CDR result is whatever the result was
        prior to going into Queue.  This is the same as the behaviour prior to this
        patch.
      * If the caller hangs up, times out, or presses '*' with the 'h' option, the
        CDR disposition is again not set and is dependent on whether or not the
        caller was Answered prior to entering Queue.
      
      This patch was based on one provided by Thomas Arimont, but has been modified
      to accomodate findings by the reviewers.
      
      Review: https://reviewboard.asterisk.org/r/2064/
      
      (closes issue AST-906)
      Reported by: Thomas Arimont
      
      (closes issue ASTERISK-17776)
      Reported by: Attila Megyeri
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375416 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      1eb14dbf
  19. Oct 18, 2012
  20. Sep 28, 2012
    • Richard Mudgett's avatar
      Add pause one second W dial modifier. · b5138fcc
      Richard Mudgett authored
      * The following dialplan applications now recognize 'W' to pause sending
      DTMF for one second in addition to the previously existing 'w' that paused
      sending DTMF for half a second.  Dial, ExternalIVR, and SendDTMF.
      
      * The chan_dahdi analog port dialing and deferred DTMF dialing for PRI now
      distinguishes between 'w' and 'W'.  The 'w' pauses dialing for half a
      second.  The 'W' pauses dialing for one second.
      
      * Created dahdi_dial_str() in chan_dahdi that eliminated a lot of
      duplicated dialing code and diagnostic messages for the channel driver.
      
      (closes issue ASTERISK-20039)
      Reported by: Jeremiah Gowdy
      Patches:
            jgowdy-wait-6-22-2012.diff (license #5621) patch uploaded by Jeremiah Gowdy
            Expanded patch to add support in chan_dahdi.
      Tested by: rmudgett
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374030 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      b5138fcc
  21. Sep 11, 2012
  22. Sep 04, 2012
  23. Aug 29, 2012
  24. Aug 11, 2012
  25. Jul 23, 2012
  26. Jul 20, 2012
  27. Jul 07, 2012
    • Joshua Colp's avatar
      Add a new unified Jingle, Google Jingle, and Google Talk channel driver... · a3fa37b8
      Joshua Colp authored
      Add a new unified Jingle, Google Jingle, and Google Talk channel driver written from scratch called chan_motif.
      
      This channel driver is a replacement for both chan_gtalk and chan_jingle but adds additional features not found in either.
      These features include full configuration reload, video, full codec support, bidirectional cause code mapping, hold,
      unhold, and ringing indication. It is also compliant with the current published Jingle and Google Jingle specifications.
      The original Google Talk protocol is also supported for Google Voice interoperability.
      
      You may ask yourself though where the name motif comes from... and I would say to you... music!
      
      motif: a perceivable or salient recurring fragment or succession of notes
      
      Sorta like a jingle!
      
      Review: https://reviewboard.asterisk.org/r/1917/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369769 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      a3fa37b8
  28. Jun 12, 2012
  29. Jun 04, 2012
  30. May 14, 2012
    • Kinsey Moore's avatar
      Commit framework for HANGUPCAUSE (replacement for SIP_CAUSE) · b5a6de76
      Kinsey Moore authored
      This is the starting point for the Asterisk 11: Who Hung Up work and provides
      a framework which will allow channel drivers to report the types of hangup
      cause information available in SIP_CAUSE without incurring the overhead of the
      MASTER_CHANNEL dialplan function. The initial implementation only includes
      cause generation for chan_sip and does not include cause code translation
      utilities.
      
      This change deprecates SIP_CAUSE and replaces its method of reporting cause
      codes with the new framework. This change also deprecates the 'storesipcause'
      option in sip.conf.
      
      Review: https://reviewboard.asterisk.org/r/1822/
      (Closes issue SWP-4221)
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366408 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      b5a6de76
  31. May 09, 2012
  32. Apr 20, 2012
  33. Apr 12, 2012
  34. Mar 20, 2012
Loading