Attended transfer does not show up in QueueMetrics

[stroba]

Hi,

When I make an attended transfer (defined in features.conf on Asterisk) I don´t see the call in QueueMetrics. Can this be done?

Regards,
stroba

[QueueMetrics]

Sad to tell, but this is by design in Asterisk. Worse still, the agent is not freed until the call is completed.....  :'(so do not use attended transfers.

[stroba]

I think you´re wrong. I´m using Asterisk version 1.4.12 and my agent can receive new calls immediately after he has made the attended transfer.

[QueueMetrics]

Are you using AgentCallBack or Local/XXX channels?

[stroba]

AgentCallback

[QueueMetrics]

In any case I have a feeling that it will not work because Asterisk does not generate the correct queue_log entries.

[kjos]

I have same experience with this. I am using Local/XXX@context as dynamic agents for the queues and this is discovered :
If members are added as LocalXXX@context/n, after attended call transfer, the agent is still blocked until the call is ended between the callee and the transfered extension.
If members are added without "/n" suffix, then they are available immediately after the call is transfered.
But in both situations, there is no record in queue_log that the call is transfered.
Another thing, if I try to monitor ( online with ChanSpy ), than in the first case ( with "/n", the call can be monitored,  otherwise ChanSpy connects to some non-existing channel and there is deaf line. To monitor the call, I have to ChanSpy the SIP extension directly instead of the Local channel.
This is, for me, problem with the asterisk PBX, some bug or probably problem with some parameter into the config files.

[QueueMetrics]

I think this is how Asterisk works more than a QM issue. 
If there is no logging in the queue_log, QM cannot pick the information up.

[revolution]

a little something i should point out...

keep in mind that a transfer isn't THAT different than a call... (i.e. you can't transfer to a number that isn't even in the same context... that is... if your phone is in context qm_internal and my phone is in my_internal -- you can't dial or transfer to me if one context isn't included in the other)... so maybe look into evaluating the length of the calling number (assuming you're using an internal ext scheme of say four numbers) and possibly assigning a variable of 'transfer' and then passing that to queuedial.agi...

seems to work fine for me... i.e. QM picks up the transfer etc. but then again who am I to say what should and should not be done.

[QueueMetrics]

This looks really interesting...  would you like to share your configuration?

[revolution]

This looks really interesting...  would you like to share your configuration?

no problem... send me a PM telling me what you'd like to see (i.e. just extensions.conf? or???) and the email you'd like me to send it to

[QueueMetrics]

I think that you could post here the relevant part f your extensions.conf and add a little explanation (maybe in a new topic).