Transfer of calls from queues fails in 1.2.13

Hi -

Since upgrading from 1.2.4 to 1.2.13, we’ve found that we can no longer transfer the call:
(i) At all from Aastra 480i phones;
(ii) If it’s on hold on Snom 360 or 320 phones.

In both cases the call is just dumped and the target extension is left with a dead call leg connected to nothing on the Asterisk server.

Transfer of calls which don’t come from queues - i.e. those which Asterisk connected directly to a SIP extension when they came in - works fine as it always has.

[Transfers are done using the Xfer / Transfer buttons on the relevant phones.]

Can anyone shed light on this?

After testing with versions between 1.2.4 and 1.2.13, I’ve found that it was working up to and including 1.2.8 and then broke in 1.2.9.

And the specific code which broke it is in channel.c. This was added to ast_channel_masquerade(…) in version 1.2.9:

[code] /* each of these channels may be sitting behind a channel proxy (i.e. chan_agent)
and if so, we don’t really want to masquerade it, but its proxy */
if (original->_bridge && (original->_bridge != ast_bridged_channel(original)))
final_orig = original->_bridge;

    if (clone->_bridge && (clone->_bridge != ast_bridged_channel(clone)))
            final_clone = clone->_bridge;

[/code]

I want to report this as a bug, but I’m not quite sure what supporting documentation to provide to show how it fails. Can anyone help with that?

Hi

Have you tried both settings on the 480! to do with transfer ?

sip cancel after blind transfer: 1 or 0

[quote=“ianplain”]Hi

Have you tried both settings on the 480! to do with transfer ?

sip cancel after blind transfer: 1 or 0[/quote]

Makes no difference. Nor do any of the transfer settings for Snom phones.

I’ll just deal with patching Asterisk for the moment. Until someone can either explain how to configure correct behaviour or acknowledge that it’s a bug…

[quote=“srd”][quote=“ianplain”]Hi

Have you tried both settings on the 480! to do with transfer ?

sip cancel after blind transfer: 1 or 0[/quote][/quote]

Makes no difference. Nor do any of the transfer settings for Snom phones.

I’ll just deal with patching Asterisk for the moment. Until someone can either explain how to configure correct behaviour or acknowledge that it’s a bug…[/quote

We have the same problem and the only workaround was to do blind transfers. That seems to work. This bug has been submitted:

[/url]http://bugs.digium.com/view.php?id=8064

my phone would have melted with the traffic if this was a bug. all my Asterisk installs are > 1.2.9 and all use either 480i or Snom 360 or both … and no reports of transfer issues have emerged yet.

what firmware versions are you using ?

[quote=“baconbuttie”]my phone would have melted with the traffic if this was a bug. all my Asterisk installs are > 1.2.9 and all use either 480i or Snom 360 or both … and no reports of transfer issues have emerged yet.

what firmware versions are you using ?[/quote]

But are you using standard Asterisk call queuing and having agents try to transfer calls to other extensions? I’m not sure about Snom firmware. 1.3.something for the Aastras and have now tried 1.4.

I assume you are using the transfer built in to the phones, have you tried using asterisk inbuilt transfer or attended transfer?

Just a thought.

Mike.

Hi
Having read the Bug report, Its now clearer. This is a generic queue problem with agentcallback. it seems from the bug its fine for normal agents.