[Home]

Summary:ASTERISK-20402: Unable to cancel (features.conf) attended transfer
Reporter:Matt Riddell (zx81)Labels:
Date Opened:2012-09-10 11:50:24Date Closed:2014-11-08 19:01:22.000-0600
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_agent Resources/res_features
Versions:SVN Frequency of
Occurrence
Constant
Related
Issues:
Environment:Debian 6.0, 64 BitAttachments:( 0) debug_with_mysql_removed
( 1) features.conf.diff
Description:1. Agent logs in using AgentLogin
2. Call goes to Queue that agent is a member of
3. Agent presses ## to transfer call (attended transfer as defined in features.conf)
4. Agent types number to transfer to
5. New call leg starts
6. Voicemail answers so agent wants to disconnect call and return to customer (presses * as defined in features.conf)
XX BUG XX
7. The call is disconnected and the agent is back in the queue and the customer is talking to voicemail.

What should happen is that if you want the customer to talk to the voicemail the agent should hang up.

== agents.conf:

agent => 0000,6053,SmoothOperator Agent

== extensions.conf

[internal]
exten => 500,1,AgentLogin()
exten => 123,1,Answer()
exten => 123,n,Set(TRANSFER_CONTEXT=outbound_crm)
exten => 123,n,Queue(so_crm_2,t)

[outbound_crm]
exten => _X.,1,Dial(SIP/1${EXTEN}@xxxxx,,T)

== features.conf

[general]
atxfernoanswertimeout = 60

[featuremap]
atxfer => ##
disconnect => *
Comments:By: Matt Riddell (zx81) 2012-09-11 10:29:48.037-0500

Is there anything else you need from me on this one?

By: Matt Riddell (zx81) 2012-09-11 14:37:07

Debug log attached with MySQL details removed (they took up most of the log)

By: Matt Riddell (zx81) 2012-09-11 15:29:04.993-0500

Worked with Paul on #asterisk-dev to try out various combinations of h an H in both dial and queue to no avail.

By: Matt Riddell (zx81) 2012-09-13 11:51:38.773-0500

Hi, did you manage to reproduce it ok?

By: Paul Belanger (pabelanger) 2012-09-14 17:15:43.827-0500

Don't expect a develop to look at this until the issue is triage.  Digium sprints usually happen once every 4 weeks.  Add on top of that the 850 issue before this one.

Just a heads up.

By: Matt Riddell (zx81) 2012-09-14 17:35:01.477-0500

Heh yeah just posted a $500 bounty on Asterisk-Biz :-)

-- Posted from Bugbox for iPhone

By: Rusty Newton (rnewton) 2012-09-15 16:04:19.535-0500

Matt, what was the latest version that had this behaving appropriately for you?

By: Rusty Newton (rnewton) 2012-09-15 16:20:01.839-0500

To confirm, referencing your post on asterisk-biz

{quote}
Already sorted - looks like a documentation change.

For the list - agents.conf defaults to using * to disconnect a call (as does features.conf).
{quote}

It sounds like the * feature in chan_agent was being detected before the * feature defined in features.conf ?

By: Matt Riddell (zx81) 2012-09-15 16:55:41.553-0500

Yeah will test Monday and submit doc change

-- Posted from Bugbox for iPhone

By: Matt Riddell (zx81) 2012-09-17 09:18:25.900-0500

Update the features.conf file to explain about the interaction with agents.conf

By: Matt Jordan (mjordan) 2012-09-17 09:57:35.424-0500

So, that's an incredibly frustrating - and difficult to debug - configuration option conflict.

Documentation is a plus, but I'd support changing the default in agents.conf to something other than '*' in a new version of Asterisk.

By: Matt Riddell (zx81) 2012-09-17 10:06:10.153-0500

Yeah, 100% agree - I looked at this for ages and couldn't figure out what was going on.

I then included other people all to no avail.

It wasn't till I posted a bounty that someone pointed out they'd come across the same problem.

By: Matt Riddell (zx81) 2012-09-17 10:11:20.871-0500

It's just set with a define but it is set to be a char.

#define DEFAULT_ENDDTMF '*'

followed by

static char enddtmf = DEFAULT_ENDDTMF;

There's not currently support for checking multi character codes.

By: Matt Jordan (mjordan) 2014-11-08 18:56:13.387-0600

So the good news is that {{chan_agent}} is gone in 12, and its replacement - {{app_agent_pool}} - handles disconnects differently. So... this ends up being just a documentation issue.

I know this is quite old, but I'm going to go ahead and push in the documentation patch you provided.