Attended transfer delay?

[Porta_Phone]

Hi,

We are using Asterisk with Cisco SPA514G latest firmware and I have noticed long delays when doing attended transfer calls.

Blind transfers are working fine, and I have tested the attended transfer with  2 other phone brand, and I do not get delays.

Could it be an option in the phone that could cause such a delay? I have made a small video showing the problem. You can see the running time on the LCD. Sometimes it takes more than 4 seconds before the call is actually transferred.

https://youtu.be/p2CmTNloKSo

[Dan Lukes]

It may or may not be phone's issue. Delay can be caused by SIP switch as well. Regardless the other brands of phones are not facing the issue. It may be matter of SIP requests content or transport protocol used.

Catch the SIP packets between phone and switch. It may reveal more about the issue. In may help to identify device causing them as well.

[Porta_Phone]

Hi,

For anyone having this problem, here's the setting to modify in the Cisco phone to fix it:

Make sure Blind_Attn-Xfer_Enable is set to no.

<Blind_Attn-Xfer_Enable_1_ group="Ext_1/Call_Feature_Settings">No</Blind_Attn-Xfer_Enable_1_>

No more delay, it is now fast as lighning to make attended transfer.

I think the default is no anyway, but if it ever happened to anyone using Asterisk, they won't have to go nuts finding the problem.

It was Mandatory in our case that the phone performs the attended transfer, because directmedia between phones will not work if Asterisk is doing the transfer (Dial with T command...) .

[Dan Lukes]

I'm unsure you identified true issue cause and I'm unsure the"solution" you mentioned have relationship to it.

The attended transfer mean you will wait until transfer target will pickup the call before transfer will be completed. The video show you initiated attended transfer but you put handset to the cradle before transfer target answered.

So you claimed attended transfer, but then act like the transfer is blind.

I'm unsure how phone and Asterisk solve such mishandling. It's why I asked the SIP dialog capture.

You didn't provided the one and you didn't mentioned firmware versions. neither the version you has been running 11 months ago, nor the version you are running now. So the "solution" you described may be just coincidental ...

[Porta_Phone]

I'm running version 13.6 PJSIP and firmware 7.5.7 (Latest firmware did not help either) and SIP dialog capture did not show anything wrong. Same behavior with Chansip driver.

The video is just to show the delay, I know what an attended transfer is, it was doing the exact same thing if I waited for the transfer target ton pickup.

I had the problem through many versions of Asterisks. Could also be a bug on their side, but I cannot prove it with what I have right now.

If anyone on this forum  can set this setting to yes and confirm it's doing the same thing,

it could help prove that Asterisk is not handling it right .

[Dan Lukes]

The phone is waiting for something, and the cause can be narrowed by SIP dialog analysis. Unfortunately, you decided not to disclose details.

So just note to others:

1. such solution can't be used if you wish to use blind transfer as well

2. We can transfer with no delay even with blind transfer enabled (and Asterisk soft switch). As I can't repeat the issue, I can't analyze it by self.

Comment has been edited not to cause confusion. See later comment for details.

[Porta_Phone]

Blind transfer are working fine on my side with the setting to no.

I can get SIP dialog for the transferor and the asterisk side, would that be enough?

[Dan Lukes]

So sorry I has been badly inattentive. You said "Blind Attn-Xfer Enable" but I followed the behavior of "Blind Transfer Serv" option instead. Thus my conclusions has been out of topic badly.

The Blind Attn-Xfer Enable doesn't enable/disable blind transfer service - it change the method of transfer.

It can be Yes, which ends the current call leg and blind transfers to the new call leg, or No, which refers the other call leg to the current call leg.

It seems the first method is incompatible with PJSIP stack. It works for me even with Yes, but we use legacy Asterisk SIP stack instead of PJSIP one.

Sorry once more for confusion I caused.