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.
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.
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
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.
Comments
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,
Edit: Included more complete capture.