[Home]

Summary:ASTERISK-03442: cannot transfer calls picked up by callback agents
Reporter:David Trcka (dtrcka)Labels:
Date Opened:2005-02-07 03:33:07.000-0600Date Closed:2011-06-07 14:10:30
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I can easily transfer a call coming directly to SIP channel, but can't transfer a call coming into queue and picked up by callback agent. 'Transfer' button does nothing, '#' button tries to start recording.
Tried both Queue(testq) and Queue(testq,tT).
Comments:By: Mark Spencer (markster) 2005-02-07 09:05:31.000-0600

This is a configuration issue.  If you map the '#' key to record you cannot use it for transfer obviously.  See /etc/asterisk/features.conf and if you think there is still a bug, please confer with a bug marshall in #asterisk before reopening.
By: Anthony Minessale (anthm) 2005-02-07 18:49:56.000-0600

<redder86> anthm: are you there? I would like http://bugs.digium.com/bug_view_page.php?bug_id=0003518 reopened.
<anthm> i have to go
<anthm> i can press reopen for you if you want bu then explain why
<redder86> okay
<redder86> the problem is with SIP transfers, not # transfers
<redder86> mark misunderstood the person
By: Lee Howard (faxguy) 2005-02-07 18:51:35.000-0600

The "transfer" button is a SIP transfer and has nothing to do with "#" transfers and shouldn't be interfering with recording.  I can confirm that transferring a call picked up out of a Queue with SIP transfers does not work.
By: Mark Spencer (markster) 2005-02-08 00:30:36.000-0600

Transfering a callback agent with SIP is not supported.  This has been hashed before on the bug tracker.  Only #-style transfer is supported.
By: k3v (k3v) 2005-02-08 00:36:11.000-0600

I have battled similar problems from pre-1.0, and still continue today.  It seems to be a design issue with the pseudo agent channel, except in my case the call is dropped on transfer.

In other cases I've heard of transfers working, but the agent channel is never freed.  I ended up tossing chan_agent in favor of some dialplan magic, Local/${agent}@context, some astdb and dynamic agents.  It actually works much better for me, and new features are simple to add (e.g. more wrap-up time request).

These chan_agent issues that come up seem to resonate back to ASTERISK-2322.  I'm going to work on real agents for app_queue when I get time, unless someone else already is.