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.
-
10 years ago
-
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 startThe 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,
-
9 years agoEdited 9 years ago by 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.
-
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.
