Retrieving call after successful attended transfer


Can anyone help me with the following at all?

I can’t work out how to implement this scenario:

Incoming caller A is picked up by extension B
Extension B does an attended transfer to extension C
Extension C picks up and says they don’t want the call and hangs up

Ideally, caller A should be reconnected to extsnsion B but at the moment caller A is just dropped.

Any help would be valuable,

What kind of call transfer are you using? The one integrated in Asterisk or the one that is handled by the IP Phone itself?

If you are using call transfer via IP Phone, this defnititly is a IP phone issue. I could do the described procedure on more or less an IP Phone I got my hands on.

Hi, thanks for the reply.

I’m using the asterisk transfer becasue there are two models of IP phone in use and I wanted to be able to supply a procedure to the staff that covered all of them.

I’m sure that the solution in asterisk should be quite simple but with all of the possible configurations and ways of doing things, I can’t see the wood for the trees.

Hi all,
I am having the same issue!

asterisk 1.8
A = extenal caller
B = dect cordless connected through an AAstra cell adapter
C = snom 300/320 firmware 7


  1. A calls B
  2. B answers and tries to transfer (attended) A to C
  3. C answers B and tells B that he doesn’t want to talk with A and then hangups the call
    what happens is that all calls are disconnected while i’m expecting that A is re-connected to B.

if i B is another snom 300/320 intead of a dect cordless everything works as expected.

any ideas?
thank you.

This is a bug in 1.8 cert 1

fixing it means patching or updating asterisk, If the build is asterisknow this isnt as simple as it sounds.

basicly its a recompile of asterisk from source which also means compiling dahdi as well

Which bug are you referencing? The current -cert of 1.8 is 1.8.11-cert7, an upgrade is just a yum update away.

This was a trasnsfer bug in cert1 which is what asterisknow is built with. Like you I would have thought that a yum update would have worked. It didnt, It failed for MANY reasons.

The test install was a fresh download of asterisknow.

If you think that AsteriskNow’s core Asterisk should be able to be updated by yum to cert7 Im happy to try again and see if it does. It would be much simpler. But my inital test it failed bigtime.

Just downloaded the 2.0.2 x86_64 ISO and installed it. It came with -cert1. Did a yum update and now I’m on -cert7.

Interesting , this is teh 32 bit iso but should be no different.

Ill reload and try it. basicly from memory it had issues with the voicemail storage.

wont be till tomorrow now.

Something in the upgrade process had issues, or there’s some voicemail storage issue in cert7?

Ill rebuild a lab box and test, Did you have freepbx and dahdi installed and a card installed ?

FreePBX yes. No cards installed; just on a VM.

thank you all.

my pbx is an asterisk- compiled from sources on an i686 2.6.35-28-generic-pae Ubuntu 10.10
is this version affected by that “transfer bug” you’re talking about?

i think no dahdi installed.

should i update?

again, thanks.


Ok ive done a yum update and the bug is still there.

A calls B
B presses *2 and dials C
C answers but doesn’t want call
If they hangup all calls are dropped
If B presses ** to disconnect call to C, B is Disconnected and call is connected A-C
Both cases this isnt what’s wanted.

There is a fix for this that came out as soon as it was noted in cert1 not sure why its not in cert7 yet…

looks like its a patch job as originally described

Ok cert 7 still has the Bug

recompiled from source… and applied patch to features.c and its fixed. attended transfers work as expected.

The modified features.c is at if anyone is interested.
We have had this modification in production use since May.

Is this bug also present in more recent mainline 1.8 releases? Is there an issue id on the issue tracker?

Hi Malcolm
Im not sure, not tested against mainline releases. and to be honest I haven’t time to test. if you have got 1.8 box to hand its an easy test.

a calls b, b presses *2 calls C, C answers then hangs up, a and b should be reconnected. is calls drop bug is there.

I did search the issues tracker found which seems to be it but this hasnt either been merged into cert7 or its not fixed

Yeah, that’s not in the 1.8.11-certX cycle. There’s a 1.8.15-certX cycle coming up, but it’s still just a branch with no releases.

looks like its fixed in the 1.8.15 cert … &r1=363428 branch

i compiled and it fixed everithing. at least for me :wink: