[asterisk-bugs] [JIRA] (ASTERISK-26715) app_queue member will not receive any new calls after doing a transfer if wrapuptime = greater than 0

[Richard Mudgett (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-26715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Mudgett updated ASTERISK-26715:
---------------------------------------

    Description: 
To reproduce edit queues.conf
wrapuptime = 10
Dynamic member answers a call and transfers caller to any extension.
Member will not receive a new call from queue until all parties involved in transfer hangup.

This commit has caused the regression.
{noformat}
2016-04-21 15:35 +0000 [79d7284b8b]  Kevin Harwell <kharwell at digium.com>

	* app_queue: queue members can receive multiple calls

	  It was possible for a queue member that is a member of at least 2 or more
	  queues to receive mulitiple calls at the same time. This happened because
	  of a race between when a member was being rung and when the device state
	  notified the other queue(s) member object of the state change.

	  This patch makes it so when a queue member is being rung it gets added to
	  a global pool of queue members. If that same member is tried again, e.g.
	  from another queue, and it is found to already exist in the pending member
	  container then it will not ring that member.

	  ASTERISK-16115 #close

	  Change-Id: Ice45a1c95b9f6f15d8a9fa709c5e5c84ffd29780
{noformat}


  was:
To reproduce edit queues.conf
wrapuptime = 10
Dynamic member answers a call and transfers caller to any extension.
Member will not receive a new call from queue until all parties involved in transfer hangup.

This commit has caused the regression.

2016-04-21 15:35 +0000 [79d7284b8b]  Kevin Harwell <kharwell at digium.com>

	* app_queue: queue members can receive multiple calls

	  It was possible for a queue member that is a member of at least 2 or more
	  queues to receive mulitiple calls at the same time. This happened because
	  of a race between when a member was being rung and when the device state
	  notified the other queue(s) member object of the state change.

	  This patch makes it so when a queue member is being rung it gets added to
	  a global pool of queue members. If that same member is tried again, e.g.
	  from another queue, and it is found to already exist in the pending member
	  container then it will not ring that member.

	  ASTERISK-16115 #close

	  Change-Id: Ice45a1c95b9f6f15d8a9fa709c5e5c84ffd29780


> app_queue member will not receive any new calls after doing a transfer if wrapuptime = greater than 0
> -----------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-26715
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26715
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_queue
>    Affects Versions: 11.25.1
>            Reporter: David Brillert
>
> To reproduce edit queues.conf
> wrapuptime = 10
> Dynamic member answers a call and transfers caller to any extension.
> Member will not receive a new call from queue until all parties involved in transfer hangup.
> This commit has caused the regression.
> {noformat}
> 2016-04-21 15:35 +0000 [79d7284b8b]  Kevin Harwell <kharwell at digium.com>
> 	* app_queue: queue members can receive multiple calls
> 	  It was possible for a queue member that is a member of at least 2 or more
> 	  queues to receive mulitiple calls at the same time. This happened because
> 	  of a race between when a member was being rung and when the device state
> 	  notified the other queue(s) member object of the state change.
> 	  This patch makes it so when a queue member is being rung it gets added to
> 	  a global pool of queue members. If that same member is tried again, e.g.
> 	  from another queue, and it is found to already exist in the pending member
> 	  container then it will not ring that member.
> 	  ASTERISK-16115 #close
> 	  Change-Id: Ice45a1c95b9f6f15d8a9fa709c5e5c84ffd29780
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)