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?