<![CDATA[Problems with attendand transfer]]>Hi,

I'm testing FOP2 2.20 with Asterisk 1.6.2.11 and I'm having problems with attendand transfer (only blind transfer works).

voip*CLI> manager show command Atxfer
Action: Atxfer
Synopsis: Attended transfer
Privilege: call,all
Description: Attended transfer.
Variables: (Names marked with * are required)
*Channel: Transferer's channel
*Exten: Extension to transfer to
*Context: Context to transfer to
*Priority: Priority to transfer to
ActionID: Optional Action id for message matching.

fop2.cfg:
; Force blind transfer on asterisk 1.6
blind_transfer = 0

; Force supervised transfer on asterisk 1.4
; requires the atxfer manager backport patch
supervised_transfer = 1

I started fop2 with debug level 5 and receive that messages:

192.168.12.101 <= <msg data="15|atxfer|4|9d651a79f726a088cffb2f3aa802cd6d" />

192.168.12.1 <- Response: Success
192.168.12.1 <- Message: Atxfer successfully queued
192.168.12.1 <- Server: 0

But the transfer don't work. Nothing happens...

Without this I can't use FOP2 and I need to fix it to buy the software.

Can you help me ?

Regards,

Marcelo H. Terres

]]>http://localhost:4567/topic/644/problems-with-attendand-transferRSS for NodeTue, 27 Oct 2026 12:43:34 GMTThu, 10 Feb 2011 17:16:32 GMT60<![CDATA[Reply to Problems with attendand transfer on Fri, 11 Feb 2011 13:52:22 GMT]]>Hi.

Does extension 5500 in context ramais exists?

yes

Was the channel SIP/9999-000088a4 active at the time of the command?

yes

If so, then it is an asterisk bug, you will probably need to update. There are a bunch of versions (semi latest versions, in >1.6 and .18, with broken AMI redirects, perhaps the atxfer is also affected.

I'll take a look in the changelogs.

For the full log to be useful, you might need to increase the debug and verbose level to the max (core set verbose 10, >core set debug 10).

I did that but I didn't find 5500 in logs.

Regards,

Marcelo H. Terres

]]>http://localhost:4567/post/2797http://localhost:4567/post/2797Fri, 11 Feb 2011 13:52:22 GMT<![CDATA[Reply to Problems with attendand transfer on Fri, 11 Feb 2011 13:03:28 GMT]]>Does extension 5500 in context ramais exists? Was the channel SIP/9999-000088a4 active at the time of the command? If so, then it is an asterisk bug, you will probably need to update. There are a bunch of versions (semi latest versions, in 1.6 and .18, with broken AMI redirects, perhaps the atxfer is also affected. For the full log to be useful, you might need to increase the debug and verbose level to the max (core set verbose 10, core set debug 10).

]]>http://localhost:4567/post/2796http://localhost:4567/post/2796Fri, 11 Feb 2011 13:03:28 GMT<![CDATA[Reply to Problems with attendand transfer on Fri, 11 Feb 2011 12:35:04 GMT]]>Hi again.

Using debug level 511 and doing the same test I received this messages:

** MAIN AMI event received...
** MAIN Processing command received from flash clients...

192.168.12.101 <= <msg data="15|atxfer|4|833e31c9ce6a6caecf9f4226e90f8733" />

-- PROCESS_FLASH_COMMAND origen 15 accion atxfer destino 4

-- PROCESS_FLASH_COMMAND password 833e31c9ce6a6caecf9f4226e90f8733

VALIDAR USUARIO 9999

VALIDAR USUARIO 9999 OK con clave regular (192.168.12.101)

Validation ok, have all permissions

ATXFER using native atxfer in AMI for SIP/9999-000088a4

192.168.12.1 -> Action: Atxfer
192.168.12.1 -> Channel: SIP/9999-000088a4
192.168.12.1 -> Exten: 5500
192.168.12.1 -> Context: ramais
192.168.12.1 -> Priority: 1
192.168.12.1 -> Async: True

** MAIN End of block from voip.local.empresa.com.br

192.168.12.1 <- Response: Success
192.168.12.1 <- Message: Atxfer successfully queued
192.168.12.1 <- Server: 0

** MAIN AMI event received...
** MAIN No 'Event' nor 'End'. Erasing block...

I search for 5500 in Asterisk full and I didn't found anything about it (just the peer registration).

Any tips ?

Regards,

Marcelo H. Terres

]]>http://localhost:4567/post/2795http://localhost:4567/post/2795Fri, 11 Feb 2011 12:35:04 GMT<![CDATA[Reply to Problems with attendand transfer on Thu, 10 Feb 2011 19:07:10 GMT]]>Increase debug to 511 to see the actual atxfer command sent and the asterisk response. You are getting a success queued command in asterisk, so it seems it was sent correctly, but there is no details on your snippet. If the command that fop2 is sending is correct, but it does not work, then it is an asterisk problem. In any case, increase debug and look for all relevant events and commands that are sent in look for clues. You might also need to look at the asterisk full log.

]]>http://localhost:4567/post/2794http://localhost:4567/post/2794Thu, 10 Feb 2011 19:07:10 GMT