Drag and Drop Broken on 2.28

[nic.eastman]

We recently upgraded to 2.28 from 2.27. We had enabled drag transfers and those settings are intact, but FOP is dropping calls when we try to transfer using drag and drop now.

[nicolas]

FOP 2.28 will try to use the native transfer features of asterisk, try starting fop2 in debug mode and see what happens when the transfers are attempted:

service fop2 stop
cd /usr/local/fop2
script capture.log
./fop2_server -X 511
(log into fop2, try to dragtransfer)
ctrl-c
exit
service fop2 start

The look for "xfer" or similar in the capture.log file and see what follows to your attempts, it might give us an idea of what could be wrong.

Best regards,

[nic.eastman]

Sorry for the slow response, and to resurrect this now. This is an excerpt from the capture.

192.168.2.1:50836    <= <msg data="1_13|dragatxfer|12|b1f1ee9ae177272ee3da1ca87c1a6f29" />

-- PROCESS_FLASH_COMMAND origen 1_13 accion dragatxfer destino 12 password b1f1ee9ae177272ee3da1ca87c1a6f29

VALIDAR USUARIO 111@GENERAL

validate password using key Ucs2n5Xamqtn6GF3V2sN

VALIDAR USUARIO 111 OK con clave regular (192.168.2.1:50836)

Validation ok, have transfer permissions for all buttons (0) 12

It's blessed into class FOP2::Extension

boton por canal SIP/112 esta blessed
++ GET CALL SLOT for 1 is defined, returning SIP/112-0003262b

++ GET SERVER for SIP/112 = localhost

It's blessed into class FOP2::Extension

It's blessed into class FOP2::Extension

ATXFER a extension destino is Local (Local/112@from-queue-0004675f), query BRIDGEPEER to Asterisk

127.0.0.1            -> Action: GetVar
127.0.0.1            -> Variable: BRIDGEPEER
127.0.0.1            -> Channel: SIP/112-0003262b
127.0.0.1            -> ActionID: getvar!atxfer!111!from-internal

127.0.0.1            <- Response: Success
127.0.0.1            <- ActionID: getvar!atxfer!111!from-internal
127.0.0.1            <- Variable: BRIDGEPEER
127.0.0.1            <- Value: Local/112@from-queue-0004675f;2

!! Ignoring response as it does not have Event

Edit: Included more complete capture.

[nicolas]

Anything after that? For what I can see, the channel that is returned for performing the transfer is a Local/xx type channel. That is usually not good, as Asterisk tends to fail in some cases if you attempt a redirect using the proxy channel instead of the real one. Anyways, there is more information below the bit you pasted that is important to see what is actually happening.