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

[Pavel Troller]

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.

With regards, Pavel Troller