Well, i have solved the dialing problem from local channel…
But, now i have observed that, it starts playing the file before actually phone is picked up… It receives the Zap channel answered, don’t how can it be happened as i have not pickedup the phone…?
Is it consider the ringing as a answered state, if so then how can i get the actually phone pick up event? (this is not the issue in case of softphone, it gets the answered event only when we accept the call, so why is it so in case of PSTN lines?) How can i solve this problem?
I want that the file should be played only when the phone is picked up.
My Dial plan is same i posted before…
Manager Api
Action: originate
channel: local/@tutorial
exten: s
context: default
priority: 1
the thing about analogue ZAP , which you are using i.e. FXO/FXS, is that call call status is other such things are problematic, unlike SIP and E1/T1. So yes, Asterisk thinks the call is ‘ANSWERED’ maybe 2-3 seconds after you dial a ZAP channel. I’m afraid you stuck with this. As far as I know, if you connecting to a ZAP device (like a premicell or something) via an FXO/FXS port, you can tell asterisk to only see the channel as ‘ANSWERED’ buy polarity switches. So in the zapata , put answeronplarityswitch=yes, then if the ZAP device sends a porality change on answer, only then will Asterisk asnswer the channel and play your file.
Or maybe you can put some sort of delay, to cater for the person to answer the call.
I have enabled that opetion, answeronpolarityswitch=yes…
But still there is no luck. I think i need to specify the switch type, is there any standard way to detect it?
Or How can i solve this problem?
Following are the debug logs i got…
-- Executing Dial("Local/457@tutorial-64f7,2", "Zap/g1/457|10|r") in new sta
ck
Dec 30 16:26:03 DEBUG[8816]: app_queue.c:490 changethread: Device ‘Local/457@tut
orial’ changed to state ‘2’ (In use) but we don’t care because they’re not a mem
ber of any queue.
Dec 30 16:26:03 DEBUG[8815]: chan_zap.c:7575 zt_request: Using channel 1
Dec 30 16:26:03 DEBUG[8815]: dsp.c:1621 ast_dsp_set_busy_pattern: dsp busy patte
rn set to 0,0
Dec 30 16:26:03 DEBUG[8782]: devicestate.c:187 do_state_change: Changing state f
or Zap/1 - state 2 (In use)
Dec 30 16:26:03 DEBUG[8817]: app_queue.c:490 changethread: Device ‘Zap/1’ change
d to state ‘2’ (In use) but we don’t care because they’re not a member of any queue.
Dec 30 16:26:03 DEBUG[8815]: chan_zap.c:1914 zt_call: Dialing '457’
Dec 30 16:26:03 DEBUG[8815]: chan_zap.c:1986 zt_call: Deferring dialing…
Dec 30 16:26:03 DEBUG[8782]: channel.c:777 channel_find_locked: Avoiding initial
deadlock for ‘Zap/1-1’
– Called g1/457
Dec 30 16:26:03 DEBUG[8782]: devicestate.c:187 do_state_change: Changing state f
or Zap/1 - state 2 (In use)
Dec 30 16:26:03 DEBUG[8818]: app_queue.c:490 changethread: Device ‘Zap/1’ change
d to state ‘2’ (In use) but we don’t care because they’re not a member of any queue.
Dec 30 16:26:04 DEBUG[8815]: chan_zap.c:4351 __zt_exception: Exception on 22, channel 1
Dec 30 16:26:04 DEBUG[8815]: chan_zap.c:3539 zt_handle_event: Got event Hook Transition Complete(12) on channel 1 (index 0)
Dec 30 16:26:05 DEBUG[8815]: chan_zap.c:4351 __zt_exception: Exception on 22, channel 1
Dec 30 16:26:05 DEBUG[8815]: chan_zap.c:3539 zt_handle_event: Got event Dial Complete(9) on channel 1 (index 0)
Dec 30 16:26:05 DEBUG[8815]: chan_zap.c:1403 zt_enable_ec: Enabled echo cancellation on channel 1 Dec 30 16:26:05 DEBUG[8815]: chan_zap.c:3623 zt_handle_event: Done dialing, but waiting for progress detection before doing more…
– Zap/1-1 answered Local/457@tutorial-64f7,2
Dec 30 16:26:05 DEBUG[8815]: channel.c:2409 set_format: Set channel Zap/1-1 to w
rite format slin
Dec 30 16:26:05 DEBUG[8815]: channel.c:2409 set_format: Set channel Zap/1-1 to r
ead format slin
Dec 30 16:26:05 DEBUG[8782]: devicestate.c:187 do_state_change: Changing state f
or Zap/1 - state 2 (In use)
According to this log, the asterisk tries to detect the callprogress but it fails to do so, and consider that Zap channel is answered as soon as it detects the ring…