If you want the call to "ring" longer than the telco would allow you will need to answer the call first but I find this approach very suboptimal. I would adjust the call forward no answer times on the carrier side so you can have consistant cdrs and normal flow of progress instead of hacks. Mike On Jan 3, 2010, at 12:21 AM, "Joseph L. Casale" <jcasale@activenetwerx.com
wrote:
It seems it was permissions problems which were causing the audio issues for me, I was attempting to run a manually compiled instance of freeswitch with the stock init scripts.
Apparently, setting the udev rules to freeswitch/daemon as fs runs won't work. I got it running finally tonight as a user and group 'freeswitch' but not till after I tried the zaptel release from the wiki's reco which didn't work until the perms issue was discovered. I am sure I can go back to using Digiums Dahdi package for Centos.
So last question. W/ Asterisk, I had to answer the dahdi line so the far end didn't activate the call forward on no answer. Would it be safe in assuming this needs to be replicated here as well. If so, do I understand this right if I do this:
<include> <extension name="openzap_in"> <condition field="source" expression="mod_openzap"> <action application="set" data="domain_name=$${domain}"/> <action application="ring_ready"/> <action application="transfer" data="2000 XML default"/> </condition> </extension> </include>
So that I can ring the call group for its preset time which surely exceeds that of the call-forward from the telco?
Thanks! jlc
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch- users http://www.freeswitch.org