Transfer from dialbox

[kevinmusker]

We are experiencing an issue with the dialbox on FOP2. When not in a call, the dialbox works as expected and originates a call. When in an active call, using the dialbox fails to initiate a transfer. Clicking the transfer button works as expected.

Using the javascript console, I see the command being sent via the flash object:

flash send <msg data="6|dial|4008|4e3ff625440add245d32b85d2693bbf1" />

Running the server with debug level 2, it looks like when using the dialbox, the active channel is not being set.

When the transfer button is clicked:

127.0.0.1 -> Action: Atxfer
127.0.0.1 -> Channel: SIP/4605-00000138
127.0.0.1 -> Exten: 4008
127.0.0.1 -> Context: from-internal
127.0.0.1 -> Priority: 1
127.0.0.1 -> Async: True

When using the dialbox:

127.0.0.1 -> Action: Atxfer
127.0.0.1 -> Channel:
127.0.0.1 -> Exten: 4008
127.0.0.1 -> Context: from-internal
127.0.0.1 -> Priority: 1
127.0.0.1 -> Async: True

I'm not sure if this makes any difference, but we are running asterisk 1.6.2 and freepbx 2.8.0.2 in user/device mode.

Thanks for your help.

[nicolas]

Do you have

callevents=yes

set in sip.conf or derivatives? If not, add it and try again. Recent FreePBX versions have the option of adding sip settings from the web gui (Tools - SIP Settings). Some older versions require you to set the event in sip_general_custom.conf or similar.

[kevinmusker]

Hi Nicolás,

I checked, and we have callevents=yes specified in sip_general_custom.conf. I also checked the rest of the asterisk config files to make sure that we weren't setting it to 'no' somewhere else.

Interestingly, the dial box has stopped working completely now. When I enter an extension into the dial box and hit Enter, I can see in firebug that the flash command is being sent, but nothing happens after that - no call is originated. When running fop2_server with devuglevel 2, I don't see any output for the dialbox commands any more.

Thanks for your help.

[nicolas]

Hi,

Try adding "all" both to read/write in /etc/asterisk/manager.conf. When debugging use level 15 to see the whole ami-fop2-webclient stream.

[kevinmusker]

Hi,

We have a dedicated AMI user set up with 'all' for read and write.

Running fop2_server with debuglevel 15 gives the following output when using the dial box:

10.0.28.248 <= <msg data="6|dial|4008|3779e1ed97121b000bd42c3d75ced8b4" />

When using the dial button, I get this

10.0.28.248 <= <msg data="6|originate|8|3779e1ed97121b000bd42c3d75ced8b4" />

127.0.0.1 -> Action: Originate
127.0.0.1 -> Channel: SIP/14502
127.0.0.1 -> Exten: 4008
127.0.0.1 -> Context: from-internal
127.0.0.1 -> Priority: 1
127.0.0.1 -> CallerID: Reception 1 <4006>
127.0.0.1 -> Async: True

127.0.0.1 <- Response: Success
127.0.0.1 <- Message: Originate successfully queued
127.0.0.1 <- Server: 0

.....

10.0.28.248 => { 'btn': '6@GENERAL', 'cmd': 'settimer', 'data': '0@UP', 'slot': '1' }

10.0.28.248 => { 'btn': '6@GENERAL', 'cmd': 'state', 'data': 'RINGING', 'slot': '1' }

10.0.28.248 => { 'btn': '6@GENERAL', 'cmd': 'settext', 'data': '4006 Reception 1', 'slot': '1' }

It looks like fop2_server may be dropping the dial request without contacting asterisk at all. Its also the same if I try to dial a non-extension number, such as an external line.

[nicolas]

In that log, fop2 is trying to originate (create a new call), it is not doing a transfer attempt.

The originate was successful , after that you have to review your asterisk logs/config on why the originate did not work. If the phone was on a call, then it is not detecting that it is indeed on a BRIDGED call, fop2 knows that for sure if you have callevents=yes and all mananger events are received. You will have to check again if you have that:

asterisk -rx "sip show settings" | grep -i call

Be sure also that you are not using event_mask in fop2.cfg, and that you are receiving all events in the manager (You must see a Dial event when the original call was made , before a transfer is attempted).

Best regards,

[kevinmusker]

Sorry, I confused things as I'm experiencing a second issue which means that I can't test the original problem.

I'll post a new topic, and come back to this one when I can reproduce it.