Click To Call + Busy Destination == Immediate Hangup

I wanted to confirm that this is an Asterisk issue before reporting it to the Asterisk team and not configuration/FreePBX.

When using a click-to-call solution (such as iSymphony’s built in dialer), and the destination is busy, my phone will hang up as soon as I pick it off the receiver.

Is this normal?

That would be a bug with iSymphony not anything in FreePBX or Asterisk. Would have to look at how they originate the call.

Is there another manager I can use to emulate this behavior (click to call via bridging two calls) outside of iSymphony or rolling my own (would rather not right now) to confirm this isn’t a bug with the x64 build of FreePBX and that it is some odd behavior with iSymphony?

I figured they just did an AsteriskAPI call like every other click-to-call setup would (and hence this bug would exist regardless of what I use to initiate the call), but I’m not familiar with them.

I’m curious with testing because our current phone system (Zultys) also contains a bug with this (except it will ring indefinitely). Wanted to puff out my chest about how Asterisk handles this properly. :wink:

Its all in the dialplan and the originate. I would contact iSymphony about it.

Correct me if I’m wrong, dial plans don’t come into play in extension-to-extension dialing (assuming you’re not using dial plans to call into remote boxes and their extensions), correct?

Is there a way to bridge two phones in a click-to-call environment from the AsteriskCLI? Or will I just need to write myself a dirty PHP script to see if I can replicate this outside of iSymphony?

Edit: passed this thread onto iSymphony, only thing that would bug us in production I can find so far.

Dialplan is used for all calls regardless of where they go. I recommend contacting i9 as it is a bug with there software.

i9’s comments:

It looks as if your iSymphony configuration is proper and should be sending the origination down the proper route. Based on the Asterisk trace the dial plan in hanging up the call due to a no answer state. Form what I can tell iSymphony is performing the call properly, however I do not have enough knowledge of the FreePBX dial plan to dig any further.

You may want to revisit this issue with the FreePBX team. If Tony or any of the other members of the team need to get hold of me on this issue they can. They have my contact information. You may also want to post this trace in the FreePBX forum.

– Executing [s@macro-dial-one:46] ExecIf(“Local/1000@from-internal-0dde;1”, “1?Set(DIALSTATUS=NOANSWER)”) in new stack
– Executing [s@macro-dial-one:47] NoOp(“Local/1000@from-internal-0dde;1”, “Returned from dial-one with nothing to call and DIALSTATUS: NOANSWER”) in new stack
– Executing [s@macro-dial-one:48] MacroExit(“Local/1000@from-internal-0dde;1”, “”) in new stack
– Executing [s@macro-exten-vm:15] GotoIf(“Local/1000@from-internal-0dde;1”, “0?exit”) in new stack
– Executing [s@macro-exten-vm:16] Set(“Local/1000@from-internal-0dde;1”, “SV_DIALSTATUS=NOANSWER”) in new stack
– Executing [s@macro-exten-vm:17] GosubIf(“Local/1000@from-internal-0dde;1”, “0?docfu,1()”) in new stack
– Executing [s@macro-exten-vm:18] GosubIf(“Local/1000@from-internal-0dde;1”, “0?docfb,1()”) in new stack
– Executing [s@macro-exten-vm:19] Set(“Local/1000@from-internal-0dde;1”, “DIALSTATUS=NOANSWER”) in new stack
– Executing [s@macro-exten-vm:20] ExecIf(“Local/1000@from-internal-0dde;1”, “0?MacroExit()”) in new stack
– Executing [s@macro-exten-vm:21] GotoIf(“Local/1000@from-internal-0dde;1”, “1?s-NOANSWER,1”) in new stack
– Goto (macro-exten-vm,s-NOANSWER,1)
– Executing [s-NOANSWER@macro-exten-vm:1] GotoIf(“Local/1000@from-internal-0dde;1”, “0?exit,1”) in new stack
– Executing [s-NOANSWER@macro-exten-vm:2] PlayTones(“Local/1000@from-internal-0dde;1”, “congestion”) in new stack
– Executing [s-NOANSWER@macro-exten-vm:3] Congestion(“Local/1000@from-internal-0dde;1”, “10”) in new stack
– Executing [h@macro-dial-one:1] Macro(“Local/1000@from-internal-0dde;2”, “hangupcall,”) in new stack
– Executing [s@macro-hangupcall:1] GotoIf(“Local/1000@from-internal-0dde;2”, “1?theend”) in new stack
– Goto (macro-hangupcall,s,3)
– Executing [s@macro-hangupcall:3] Hangup(“Local/1000@from-internal-0dde;2”, “”) in new stack
== Spawn extension (macro-hangupcall, s, 3) exited non-zero on ‘Local/1000@from-internal-0dde;2’ in macro ‘hangupcall’
== Spawn extension (macro-dial-one, h, 1) exited non-zero on ‘Local/1000@from-internal-0dde;2’
== Spawn extension (macro-dial-one, s, 42) exited non-zero on ‘Local/1000@from-internal-0dde;2’ in macro ‘dial-one’
== Spawn extension (macro-exten-vm, s, 14) exited non-zero on ‘Local/1000@from-internal-0dde;2’ in macro ‘exten-vm’
== Spawn extension (ext-local, 1000, 2) exited non-zero on ‘Local/1000@from-internal-0dde;2’
== Spawn extension (macro-exten-vm, s-NOANSWER, 3) exited non-zero on ‘Local/1000@from-internal-0dde;1’ in macro ‘exten-vm’
== Spawn extension (from-internal, 1001, 2) exited non-zero on ‘Local/1000@from-internal-0dde;1’

I’m 99% sure this is going to be reproducible on any click to call software that bridges two calls, being as it seems that Asterisk is hanging up the busy endpoint before I pick up my phone, hence the dead line on pick-up. However I wanted to confirm this is an Asterisk Core bug before passing it onto them.


I mean basically, if you guys set a virtual extension to do nothing but reply busy to incoming calls, and use click to call software to complete the call via bridging two calls, what kind of behavior do you get?

Tested iSYmphony clicking another users extension and got their voicemail just fine.

Disable their voicemail feature, you want to make the PBX return a busy signal when you call their extension to simulate calling a busy line externally using click-to-call but eliminates any possibility of anything outside of the PBX causing it’s odd behavior.

When you pick up your phone, the call will be dropped, you wont hear a busy signal or a message from the PBX.

Were you able to replicate this behavior?