Hello everyone. I know, poor form to reply to my own message, but some of the problems I have solved. On 10/28/2011 01:49 AM, Trever L. Adams wrote:
I have a span of 4 FXS modules. They are all configured to use context Internal-FXS. Channel 5 will dial. All the others won't even stop sending the dialtone when one attempts to dial.
Channel 5 can call channels 1-3 (there is no 4 at the moment, I have tried it where 4 isn't used and 5 becomes 4, same problem), but if 5 hangs up, the called channel continues to ring.
zt.conf has echo_cancellation_level at 16. Yet, I constantly get messages like: Disable echo cancel for 1:5 This was caused by me not having tones.conf in the right place. All of this is fixed now. Except that the called channel still continues to ring. It often looks like this: 2011-10-28 16:42:03.627167 [INFO] mod_dialplan_xml.c:336 Processing <0000000000>->1005 in context Internal-FXS 2011-10-28 16:42:03.627167 [INFO] ftmod_zt.c:655 Setting echo cancel to 32 taps for 1:5 2011-10-28 16:42:03.627167 [NOTICE] switch_channel.c:915 New Channel FreeTDM/1:5/ [0e792586-01b6-11e1-b8e9-d3b08c8655be] 2011-10-28 16:42:03.627167 [INFO] ftmod_zt.c:655 Setting echo cancel to 32 taps for 1:5 2011-10-28 16:42:03.627167 [NOTICE] mod_freetdm.c:2079 Ring-Ready FreeTDM/1:5/! 2011-10-28 16:42:04.147140 [NOTICE] mod_freetdm.c:1069 Ring-Ready FreeTDM/1:3/1005! 2011-10-28 16:42:04.147140 [NOTICE] switch_ivr_originate.c:483 Ring Ready FreeTDM/1:3/1005! 2011-10-28 16:42:05.627153 [ERR] ftmod_zt.c:1188 [s1c5][1:5] Failed to process event from channel 2011-10-28 16:42:09.627161 [ERR] ftmod_zt.c:1188 [s1c5][1:5] Failed to process event from channel 2011-10-28 16:42:11.627143 [ERR] ftmod_zt.c:1188 [s1c5][1:5] Failed to process event from channel 2011-10-28 16:42:15.627170 [ERR] ftmod_zt.c:1188 [s1c5][1:5] Failed to process event from channel 2011-10-28 16:42:17.627157 [ERR] ftmod_zt.c:1188 [s1c5][1:5] Failed to process event from channel 2011-10-28 16:42:20.687138 [NOTICE] mod_freetdm.c:2157 Hangup FreeTDM/1:3/1005 [CS_EXECUTE] [NORMAL_CLEARING] 2011-10-28 16:42:20.687138 [NOTICE] switch_ivr_originate.c:3167 Hangup FreeTDM/1:5/ [CS_CONSUME_MEDIA] [ORIGINATOR_CANCEL]
Freeswitch seems to think it is hanging up both legs, but the one continues to ring. The dahdi module I am using is opvxa1200. This is an 8 port analog card from OpenVox. 2 ports are FXO 6 are FXS. The dahdi package I am using is from openvox: openvox_dahdi-linux-complete-2.5.0.1+2.5.0.1.tar.gz. I am not sure if the bug is in FreeSwitch or the openvox/dahdi stuff.
I get messages like this continually: [ERR] ftmod_zt.c:1188 [s1c2][1:2] Failed to process event from channel
I am still getting too many of the above.
Finally, with the help of someone on this list I now have my call screening setup to work for the appropriate caller id names and numbers when it has been blocked. The problem is, the screening part completely fails.
These are the actions from the file, which are only slightly modified from the example at http://wiki.freeswitch.org/wiki/Dialplan_XML#Example_13:_Call_Screening . It asks for your name, it records. But it doesn't give ANYTHING to the dialed party.
<action application="set" data="call_screen_filename=/tmp/${caller_id_number}-name.wav"/> <action application="answer"/> <action application="sleep" data="1000"/> <action application="phrase" data="voicemail_record_name"/> <action application="playback" data="tone_stream://%(500, 0, 640)"/> <action application="set" data="playback_terminators=#*0123456789"/> <action application="record" data="${call_screen_filename} 7 200 2"/> <action application="set" data="group_confirm_key=1"/> <action application="set" data="fail_on_single_reject=true"/> <action application="set" data="group_confirm_file=phrase:screen_confirm:${call_screen_filename}"/> <action application="set" data="continue_on_fail=true"/> <action application="bridge" data="FreeTDM/1/1:_:FreeTDM/1/2:_:FreeTDM/1/3:_:FreeTDM/1/4:_:FreeTDM/1/5:_:FreeTDM/1/6"/> <action application="voicemail" data="default $${domain} ${dialed_number}"/> <action application="hangup"/>
I don't think the problem is the phrase:screen_confirm as I have tried removing it. I do set dialed_number to my phone number at the top of this extension so it is set.
It should be noted that all calls to this FXO port are routed as the action above shows. The non-blocked-caller_id route has the exact same bridge line.
Am I just plain missing something about the FreeTDM module? Is it this broken?
Any help would be greatly appreciated.
Trever
I haven't yet tried the call screening now that things are working MUCH better. I will be trying that in the next 72 hours. If anyone can see any obvious mistakes, I would love to know before hand. Thank you, Trever P.S. FreeSwitch is really neat. I am loving it. I just have these few problems. -- "God is real, unless declared integer." -- Unknown