[asterisk-dev] A problem with attended transfer in 1.6.1.12

[Leif Madsen]

Pavel Troller wrote:
> Hi!
>   In 1.6.1.12, the following call scenario seems broken for me:
>   1) There is a call between two parties.
>   2) One of the parties dials the "Attended transfer" feature. The other party
>      is put on hold.
>   3) The transferer dials a valid extension. A ringing tone is heard and the
>      extension is rung.
>   4) Now, the transferer hangs up, attempting a blind transfer (according to
>      the documentation, it should work). 
>   In this moment, asterisk starts to consume 100% of CPU, the held party is
> still on hold, the called party is still ringing. If the called party answers,
> the new call is bridged and CPU usage goes back to normal. If the called party
> doesn't answer, after a timeout the call is returned to the transferer (which
> is rung back) and the situation also normalizes.
> 
> I've studied the problem and it seems to be in ast_feature_request_and_dial()
> routine. It has a parameter called igncallerstate, which is set to 1 when this
> routine is called by builtin_atxfer(). There is a while loop in the routine,
> which seems to be going crazy when the caller hangs up but the above variable
> prevents to detect this condition and terminate the loop.
> 
> I fixed the problem by supplying 0 instead of 1 for igncallerstate from
> builtin_atxfer(). Now, when the transferer hangs up, the other party is unheld,
> it starts to hear the ringing tone instead of MOH and when the extension
> eventually answers, a normal conversation is started. However, I don't know
> whether this fix is proper - it definitely changes the behaviour of "blind
> atxfer" :-) but fixes a problem.

I think this may have just been filed yesterday under this bug, as it sounds 
quite similar:  https://issues.asterisk.org/view.php?id=16563

If you could put your comments there if they are appropriate, that would be much 
appreciated so the issue can be tracked and eventually fixed.

Thanks!
Leif Madsen.