Transfer bug on Asterisk 1.4.38, 1.6.2.15, and 1.8.0/1

I recommend this be a sticky post for a month or so, or at least until the current buggy versions of Asterisk are behind us.

There is a bug affecting currently released versions of Asterisk 1.4, 1.6 and 1.8 that causes blind transfers using SIP protocol and manager transfers (including from Flash Operator Panel and any adjunct application that may use the manager) to simply hang up the call. A few problems posted on these forums in the last month have been resolved by addresing this bug.

See https://issues.asterisk.org/view.php?id=18185

This bug has been in 1.4 since 1.4.38-rc1; in 1.6 since 1.6.2.15-rc1; and in 1.8 since 1.8.0-rc4. The current -rc1 versions, as of this writing, have the fix: 1.4.39-rc1, 1.6.2.16-rc1, and 1.8.2-rc1.

Unfortunately because the fixes are at RC stage, folks may be reluctant to upgrade.

This is a particularly bad bug because it affects all the current versions of Asterisk, including what many people think of as the “super-stable” version, 1.4. It is also kind of sneaky because it’s hard to spot using debug logging.

Asterisk 1.4.39, 1.6.2.16, and 1.8.2 are now up on the [URL=http://downloads.asterisk.org/pub/telephony/asterisk/]downloads page[/URL].

Recently update from 1.6 branch to 1.8 branch leaves this issue exposed.

Looks like is present in trunk branch too.

THIS TICKET has the “workaround” patch to solve it. Applied to 1.8.1.1 make things work again.

I have the bug here even with version 1.4.39 RC1 on two different machines.

Does exhibit with half attended transfert. The call is cut when hanging up.

It’s a pitty to see this after 3 major version and 39 minor version.

Developer claims to have fixed it in 1.4.39-rc1, according to changelog:

[quote]2010-11-22 18:46 +0000 [r295790] Richard Mudgett [email protected]

* main/channel.c, main/pbx.c, apps/app_macro.c,
  include/asterisk/channel.h, include/asterisk/frame.h: The channel
  redirect function (CLI or AMI) hangs up the call instead of
  redirecting the call. [/quote]

If you are sure it is the same bug you should report your findings to Digium, but a number of others have reported that 1.4.39-rc1 fixed their issues (myself included), so I am not sure you are really seeing the same bug.

I thought it was fixed. But today i discovered this at a client site and confirmed here in the office as well.

I cannot reproduce it every time here, but at a client site it is reproductible every time, with Kirk Polycom DECT phones and a KWS300 DECT base station.

The bug did exhibit just after upgrade from 1.2 to 1.4.39 RC1.

After some investigations, it is not related to 1.4.39 RC1. Same problem with 1.4.25.1.

It seems that Polycom has a problem on KWS300 DECT base station. The station cannot accept fast enough the second call sent by Asterisk 1.4 during the half attended transfer. Then it reject the call.

After some investigations, i’ve found another reseller who had the same problem with Polycom base stations. He was not able to get support neither from Polycom through their french agents.

We’ll switch to Aastra DECT base stations for next purchases. Aastra seems really more efficient on the Asterisk compatibility side.

Last, i can confirm the 1.4.38 bug. It was present here with Aastra 57i phones. 1.4.39 RC1 solved it.

Any estimates on when 1.4.39rc1 will be released from Release Candidate? I have instructed my users to use attended transfers which seem to be working currently.

It is also my understanding that this bug indirectly affects fax detection in some cases since the calls is affectively tranfered in these cases resulting in the bug being encountered.

If I’m not mistaken, there has been some confusion on this resulting in concerns that faxing might be broken on 2.8 when it turns out that the issue is related to Fax and this problem described.

Given that, I’ll be glad to mark this as sticky for now.

Feel free to ping me in the future if you happen to come across this post and realized that it’s ‘stickiness’ has is not a bit old…