Hi All, Have a situation where I have a call between a SIP phone and a FreeTDM channel. Pushing *3 on the analog FreeTDM phone is detected and this is bound to a dialplan extension (attended transfer) that does a read(): <action application="read" data="3 3 'tone_stream://%(10000,0,350,440)' digits 30000 #"/> However pushing further digits on the analog phone ie. extension number of phone we wish to do an attended transfer to , doesn't result in the DTMF being detected. Note that this all works the other way around ie. using the SIP phone. When the *3 digits are pushed on the analog phone I see the logs report: ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF * (debug = 0) mod_freetdm.c:702 Queuing DTMF [*] in channel FreeTDM/2:1/ ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF 4 (debug = 0) mod_freetdm.c:702 Queuing DTMF [4] in channel FreeTDM/2:1/ When the further keys are pushed ftdm_io reports nothing. I have tried inserting a start_dtmf before the read() but it had no effect. Any thoughts as to why DTMF isn't being seen from the analog phone after the read()? Cheers Shane
I'm guessing the bind digits in your analog card was set to listen for this sequence on the a-leg given if the call was being routed from the IP side to the analog side. Try changing that to listen on the b-leg. On 5/9/12, Shane Harrison <shane@longwhitecloud.com> wrote:
Hi All,
Have a situation where I have a call between a SIP phone and a FreeTDM channel. Pushing *3 on the analog FreeTDM phone is detected and this is bound to a dialplan extension (attended transfer) that does a read(): <action application="read" data="3 3 'tone_stream://%(10000,0,350,440)' digits 30000 #"/>
However pushing further digits on the analog phone ie. extension number of phone we wish to do an attended transfer to , doesn't result in the DTMF being detected. Note that this all works the other way around ie. using the SIP phone.
When the *3 digits are pushed on the analog phone I see the logs report:
ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF * (debug = 0) mod_freetdm.c:702 Queuing DTMF [*] in channel FreeTDM/2:1/
ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF 4 (debug = 0)
mod_freetdm.c:702 Queuing DTMF [4] in channel FreeTDM/2:1/
When the further keys are pushed ftdm_io reports nothing.
I have tried inserting a start_dtmf before the read() but it had no effect. Any thoughts as to why DTMF isn't being seen from the analog phone after the read()?
Cheers Shane
Thanks. I am currently using bind_meta_app (set to both legs) already rather than bind_digits. I'll give bind_digits a shot and see if it behaves differently. Note that I do detect the initial *3 digits and because bind_meta_app is both legs, this is successful no matter which direction the call is setup from. However once the dialplan moves to the extension the *3 is bound to, digits are no longer received. The worrying thing for me is that ftdm_io.c doesn't even write to the log that it has received them (nor freetdm above that of course which is understandable) and I am surprised that the read() influences that since it works prior on the *3 digits. Cheers Shane On Thu, May 10, 2012 at 10:22 AM, curriegrad2004 <curriegrad2004@gmail.com>wrote:
I'm guessing the bind digits in your analog card was set to listen for this sequence on the a-leg given if the call was being routed from the IP side to the analog side.
Try changing that to listen on the b-leg.
On 5/9/12, Shane Harrison <shane@longwhitecloud.com> wrote:
Hi All,
Have a situation where I have a call between a SIP phone and a FreeTDM channel. Pushing *3 on the analog FreeTDM phone is detected and this is bound to a dialplan extension (attended transfer) that does a read(): <action application="read" data="3 3 'tone_stream://%(10000,0,350,440)' digits 30000 #"/>
However pushing further digits on the analog phone ie. extension number of phone we wish to do an attended transfer to , doesn't result in the DTMF being detected. Note that this all works the other way around ie. using the SIP phone.
When the *3 digits are pushed on the analog phone I see the logs report:
ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF * (debug = 0) mod_freetdm.c:702 Queuing DTMF [*] in channel FreeTDM/2:1/
ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF 4 (debug = 0)
mod_freetdm.c:702 Queuing DTMF [4] in channel FreeTDM/2:1/
When the further keys are pushed ftdm_io reports nothing.
I have tried inserting a start_dtmf before the read() but it had no effect. Any thoughts as to why DTMF isn't being seen from the analog phone after the read()?
Cheers Shane
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040 +64 4 5703870 Extn 875 +64 21 608919 (mobile) "Solving your problems with the right technology"
apologies for telling you the wrong thing. I was replying you from my phone btw :P Yeah, bind_meta_app is the app you would use, but try changing it to point to the b-leg, not the a-leg On Wed, May 9, 2012 at 4:12 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote:
Thanks. I am currently using bind_meta_app (set to both legs) already rather than bind_digits. I'll give bind_digits a shot and see if it behaves differently.
Note that I do detect the initial *3 digits and because bind_meta_app is both legs, this is successful no matter which direction the call is setup from. However once the dialplan moves to the extension the *3 is bound to, digits are no longer received.
The worrying thing for me is that ftdm_io.c doesn't even write to the log that it has received them (nor freetdm above that of course which is understandable) and I am surprised that the read() influences that since it works prior on the *3 digits.
Cheers Shane
On Thu, May 10, 2012 at 10:22 AM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
I'm guessing the bind digits in your analog card was set to listen for this sequence on the a-leg given if the call was being routed from the IP side to the analog side.
Try changing that to listen on the b-leg.
On 5/9/12, Shane Harrison <shane@longwhitecloud.com> wrote:
Hi All,
Have a situation where I have a call between a SIP phone and a FreeTDM channel. Pushing *3 on the analog FreeTDM phone is detected and this is bound to a dialplan extension (attended transfer) that does a read(): <action application="read" data="3 3 'tone_stream://%(10000,0,350,440)' digits 30000 #"/>
However pushing further digits on the analog phone ie. extension number of phone we wish to do an attended transfer to , doesn't result in the DTMF being detected. Note that this all works the other way around ie. using the SIP phone.
When the *3 digits are pushed on the analog phone I see the logs report:
ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF * (debug = 0) mod_freetdm.c:702 Queuing DTMF [*] in channel FreeTDM/2:1/
ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF 4 (debug = 0)
mod_freetdm.c:702 Queuing DTMF [4] in channel FreeTDM/2:1/
When the further keys are pushed ftdm_io reports nothing.
I have tried inserting a start_dtmf before the read() but it had no effect. Any thoughts as to why DTMF isn't being seen from the analog phone after the read()?
Cheers Shane
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040
+64 4 5703870 Extn 875 +64 21 608919 (mobile)
"Solving your problems with the right technology"
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
and crap, since I wasn't even reading anything here, on the subsequent transfers from your FXO card, enable the in-band DTMF detector that FS has. The details on the in-band DTMF detector is here: http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_start_dtmf But use this with caution, if there is a DTMF detector on the FXO card itself, make sure you disable it before using it. On Wed, May 9, 2012 at 5:26 PM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
apologies for telling you the wrong thing. I was replying you from my phone btw :P
Yeah, bind_meta_app is the app you would use, but try changing it to point to the b-leg, not the a-leg
On Wed, May 9, 2012 at 4:12 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote:
Thanks. I am currently using bind_meta_app (set to both legs) already rather than bind_digits. I'll give bind_digits a shot and see if it behaves differently.
Note that I do detect the initial *3 digits and because bind_meta_app is both legs, this is successful no matter which direction the call is setup from. However once the dialplan moves to the extension the *3 is bound to, digits are no longer received.
The worrying thing for me is that ftdm_io.c doesn't even write to the log that it has received them (nor freetdm above that of course which is understandable) and I am surprised that the read() influences that since it works prior on the *3 digits.
Cheers Shane
On Thu, May 10, 2012 at 10:22 AM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
I'm guessing the bind digits in your analog card was set to listen for this sequence on the a-leg given if the call was being routed from the IP side to the analog side.
Try changing that to listen on the b-leg.
On 5/9/12, Shane Harrison <shane@longwhitecloud.com> wrote:
Hi All,
Have a situation where I have a call between a SIP phone and a FreeTDM channel. Pushing *3 on the analog FreeTDM phone is detected and this is bound to a dialplan extension (attended transfer) that does a read(): <action application="read" data="3 3 'tone_stream://%(10000,0,350,440)' digits 30000 #"/>
However pushing further digits on the analog phone ie. extension number of phone we wish to do an attended transfer to , doesn't result in the DTMF being detected. Note that this all works the other way around ie. using the SIP phone.
When the *3 digits are pushed on the analog phone I see the logs report:
ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF * (debug = 0) mod_freetdm.c:702 Queuing DTMF [*] in channel FreeTDM/2:1/
ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF 4 (debug = 0)
mod_freetdm.c:702 Queuing DTMF [4] in channel FreeTDM/2:1/
When the further keys are pushed ftdm_io reports nothing.
I have tried inserting a start_dtmf before the read() but it had no effect. Any thoughts as to why DTMF isn't being seen from the analog phone after the read()?
Cheers Shane
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040
+64 4 5703870 Extn 875 +64 21 608919 (mobile)
"Solving your problems with the right technology"
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
Thanks for the thoughts. As I said, I am already setting it to both legs - I will try simply trying one leg but am sceptical :-) I also mentioned that I called the start_dtmf just before calling the read so unless I am doing something wrong here..... I'll try and post the XML tonight when I get home. Oh and it is an FXS card not an FXO of course since it has a phone plugged into it. The question still remains though, why is the in-band DTMF detection working for the bind_meta_app digit detection but not after that? Cheers Shane On Thu, May 10, 2012 at 12:28 PM, curriegrad2004 <curriegrad2004@gmail.com>wrote:
and crap, since I wasn't even reading anything here, on the subsequent transfers from your FXO card, enable the in-band DTMF detector that FS has. The details on the in-band DTMF detector is here:
http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_start_dtmf
But use this with caution, if there is a DTMF detector on the FXO card itself, make sure you disable it before using it.
On Wed, May 9, 2012 at 5:26 PM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
apologies for telling you the wrong thing. I was replying you from my phone btw :P
Yeah, bind_meta_app is the app you would use, but try changing it to point to the b-leg, not the a-leg
On Wed, May 9, 2012 at 4:12 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote:
Thanks. I am currently using bind_meta_app (set to both legs) already rather than bind_digits. I'll give bind_digits a shot and see if it behaves differently.
Note that I do detect the initial *3 digits and because bind_meta_app is both legs, this is successful no matter which direction the call is setup from. However once the dialplan moves to the extension the *3 is bound to, digits are no longer received.
The worrying thing for me is that ftdm_io.c doesn't even write to the log that it has received them (nor freetdm above that of course which is understandable) and I am surprised that the read() influences that since it works prior on the *3 digits.
Cheers Shane
On Thu, May 10, 2012 at 10:22 AM, curriegrad2004 < curriegrad2004@gmail.com> wrote:
I'm guessing the bind digits in your analog card was set to listen for this sequence on the a-leg given if the call was being routed from the IP side to the analog side.
Try changing that to listen on the b-leg.
On 5/9/12, Shane Harrison <shane@longwhitecloud.com> wrote:
Hi All,
Have a situation where I have a call between a SIP phone and a
FreeTDM
channel. Pushing *3 on the analog FreeTDM phone is detected and this is bound to a dialplan extension (attended transfer) that does a read(): <action application="read" data="3 3 'tone_stream://%(10000,0,350,440)' digits 30000 #"/>
However pushing further digits on the analog phone ie. extension number of phone we wish to do an attended transfer to , doesn't result in the DTMF being detected. Note that this all works the other way around ie. using the SIP phone.
When the *3 digits are pushed on the analog phone I see the logs report:
ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF * (debug = 0) mod_freetdm.c:702 Queuing DTMF [*] in channel FreeTDM/2:1/
ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF 4 (debug = 0)
mod_freetdm.c:702 Queuing DTMF [4] in channel FreeTDM/2:1/
When the further keys are pushed ftdm_io reports nothing.
I have tried inserting a start_dtmf before the read() but it had no effect. Any thoughts as to why DTMF isn't being seen from the analog phone after the read()?
Cheers Shane
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040
+64 4 5703870 Extn 875 +64 21 608919 (mobile)
"Solving your problems with the right technology"
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040 +64 4 5703870 Extn 875 +64 21 608919 (mobile) "Solving your problems with the right technology"
I just had to laugh at my self for mixing up the 2 again... bind_meta_app is only applicable to that extension that the inbound call was made to. Since you've transferred to another extension, the bind_meta_app won't work anymore because it's not defined in the extension you're transferring to. If you want this to happen, you'd have to manually define that bind_meta_app to those target extensions too. Remember, do this at your own peril - obvious misuse of bind_meta_app can open a huge security hole if you don't know what you're doing :) On Wed, May 9, 2012 at 7:27 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote:
Thanks for the thoughts. As I said, I am already setting it to both legs - I will try simply trying one leg but am sceptical :-)
I also mentioned that I called the start_dtmf just before calling the read so unless I am doing something wrong here..... I'll try and post the XML tonight when I get home. Oh and it is an FXS card not an FXO of course since it has a phone plugged into it.
The question still remains though, why is the in-band DTMF detection working for the bind_meta_app digit detection but not after that?
Cheers Shane
On Thu, May 10, 2012 at 12:28 PM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
and crap, since I wasn't even reading anything here, on the subsequent transfers from your FXO card, enable the in-band DTMF detector that FS has. The details on the in-band DTMF detector is here:
http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_start_dtmf
But use this with caution, if there is a DTMF detector on the FXO card itself, make sure you disable it before using it.
On Wed, May 9, 2012 at 5:26 PM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
apologies for telling you the wrong thing. I was replying you from my phone btw :P
Yeah, bind_meta_app is the app you would use, but try changing it to point to the b-leg, not the a-leg
On Wed, May 9, 2012 at 4:12 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote:
Thanks. I am currently using bind_meta_app (set to both legs) already rather than bind_digits. I'll give bind_digits a shot and see if it behaves differently.
Note that I do detect the initial *3 digits and because bind_meta_app is both legs, this is successful no matter which direction the call is setup from. However once the dialplan moves to the extension the *3 is bound to, digits are no longer received.
The worrying thing for me is that ftdm_io.c doesn't even write to the log that it has received them (nor freetdm above that of course which is understandable) and I am surprised that the read() influences that since it works prior on the *3 digits.
Cheers Shane
On Thu, May 10, 2012 at 10:22 AM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
I'm guessing the bind digits in your analog card was set to listen for this sequence on the a-leg given if the call was being routed from the IP side to the analog side.
Try changing that to listen on the b-leg.
On 5/9/12, Shane Harrison <shane@longwhitecloud.com> wrote:
Hi All,
Have a situation where I have a call between a SIP phone and a FreeTDM channel. Pushing *3 on the analog FreeTDM phone is detected and this is bound to a dialplan extension (attended transfer) that does a read(): <action application="read" data="3 3 'tone_stream://%(10000,0,350,440)' digits 30000 #"/>
However pushing further digits on the analog phone ie. extension number of phone we wish to do an attended transfer to , doesn't result in the DTMF being detected. Note that this all works the other way around ie. using the SIP phone.
When the *3 digits are pushed on the analog phone I see the logs report:
ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF * (debug = 0) mod_freetdm.c:702 Queuing DTMF [*] in channel FreeTDM/2:1/
ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF 4 (debug = 0)
mod_freetdm.c:702 Queuing DTMF [4] in channel FreeTDM/2:1/
When the further keys are pushed ftdm_io reports nothing.
I have tried inserting a start_dtmf before the read() but it had no effect. Any thoughts as to why DTMF isn't being seen from the analog phone after the read()?
Cheers Shane
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040
+64 4 5703870 Extn 875 +64 21 608919 (mobile)
"Solving your problems with the right technology"
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040
+64 4 5703870 Extn 875 +64 21 608919 (mobile)
"Solving your problems with the right technology"
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
Happy for you to laugh at yourself, I'm just happy you are finding some time to take some interest in my problem. Much appreciated. I think some clarity is required here. I am simply trying to do an attended transfer as per the wiki (except I set the bind_meta_app to both legs) http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_att_xfer It works fine for SIP to SIP. For SIP to Freetdm it only works if the SIP is trying to do the transfer. If the FreeTDM is trying to do it ie. push *3 on the phone keypad, then the bind_meta_app works fine and detects the *3 and executes the appropriate extension ie. att_xfer, however the read() in the extension att_xfer does not see the subsequent DTMF pressed on the phone ie. the destination extension number. Cheers Shane On Thu, May 10, 2012 at 2:44 PM, curriegrad2004 <curriegrad2004@gmail.com>wrote:
I just had to laugh at my self for mixing up the 2 again... bind_meta_app is only applicable to that extension that the inbound call was made to. Since you've transferred to another extension, the bind_meta_app won't work anymore because it's not defined in the extension you're transferring to.
If you want this to happen, you'd have to manually define that bind_meta_app to those target extensions too. Remember, do this at your own peril - obvious misuse of bind_meta_app can open a huge security hole if you don't know what you're doing :)
On Wed, May 9, 2012 at 7:27 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote:
Thanks for the thoughts. As I said, I am already setting it to both legs - I will try simply trying one leg but am sceptical :-)
I also mentioned that I called the start_dtmf just before calling the read so unless I am doing something wrong here..... I'll try and post the XML tonight when I get home. Oh and it is an FXS card not an FXO of course since it has a phone plugged into it.
The question still remains though, why is the in-band DTMF detection working for the bind_meta_app digit detection but not after that?
Cheers Shane
On Thu, May 10, 2012 at 12:28 PM, curriegrad2004 < curriegrad2004@gmail.com> wrote:
and crap, since I wasn't even reading anything here, on the subsequent transfers from your FXO card, enable the in-band DTMF detector that FS has. The details on the in-band DTMF detector is here:
http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_start_dtmf
But use this with caution, if there is a DTMF detector on the FXO card itself, make sure you disable it before using it.
On Wed, May 9, 2012 at 5:26 PM, curriegrad2004 <
curriegrad2004@gmail.com>
wrote:
apologies for telling you the wrong thing. I was replying you from my phone btw :P
Yeah, bind_meta_app is the app you would use, but try changing it to point to the b-leg, not the a-leg
On Wed, May 9, 2012 at 4:12 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote:
Thanks. I am currently using bind_meta_app (set to both legs) already rather than bind_digits. I'll give bind_digits a shot and see if it behaves differently.
Note that I do detect the initial *3 digits and because bind_meta_app is both legs, this is successful no matter which direction the call is setup from. However once the dialplan moves to the extension the *3 is bound to, digits are no longer received.
The worrying thing for me is that ftdm_io.c doesn't even write to the log that it has received them (nor freetdm above that of course which is understandable) and I am surprised that the read() influences that since it works prior on the *3 digits.
Cheers Shane
On Thu, May 10, 2012 at 10:22 AM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
I'm guessing the bind digits in your analog card was set to listen
for
this sequence on the a-leg given if the call was being routed from the IP side to the analog side.
Try changing that to listen on the b-leg.
On 5/9/12, Shane Harrison <shane@longwhitecloud.com> wrote: > Hi All, > > Have a situation where I have a call between a SIP phone and a > FreeTDM > channel. Pushing *3 on the analog FreeTDM phone is detected and > this > is > bound to a dialplan extension (attended transfer) that does a > read(): > <action application="read" data="3 3 > 'tone_stream://%(10000,0,350,440)' > digits 30000 #"/> > > However pushing further digits on the analog phone ie. extension > number > of > phone we wish to do an attended transfer to , doesn't result in the > DTMF > being detected. Note that this all works the other way around ie. > using > the SIP phone. > > When the *3 digits are pushed on the analog phone I see the logs > report: > > ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF * (debug = 0) > mod_freetdm.c:702 Queuing DTMF [*] in channel FreeTDM/2:1/ > > ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF 4 (debug = 0) > > mod_freetdm.c:702 Queuing DTMF [4] in channel FreeTDM/2:1/ > > When the further keys are pushed ftdm_io reports nothing. > > I have tried inserting a start_dtmf before the read() but it had no > effect. > Any thoughts as to why DTMF isn't being seen from the analog phone > after > the read()? > > Cheers > Shane >
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040
+64 4 5703870 Extn 875 +64 21 608919 (mobile)
"Solving your problems with the right technology"
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040
+64 4 5703870 Extn 875 +64 21 608919 (mobile)
"Solving your problems with the right technology"
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040 +64 4 5703870 Extn 875 +64 21 608919 (mobile) "Solving your problems with the right technology"
It would be beneficial if you can post the dialplan on how FS handles the part where FreeTDM comes into play. I.e. the dialplan that does the transfer of the FreeTDM call into the default context. This seems to be opening up a can of worms here with FXS cards in FreeTDM... On Wed, May 9, 2012 at 8:39 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote:
Happy for you to laugh at yourself, I'm just happy you are finding some time to take some interest in my problem. Much appreciated.
I think some clarity is required here. I am simply trying to do an attended transfer as per the wiki (except I set the bind_meta_app to both legs) http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_att_xfer
It works fine for SIP to SIP. For SIP to Freetdm it only works if the SIP is trying to do the transfer. If the FreeTDM is trying to do it ie. push *3 on the phone keypad, then the bind_meta_app works fine and detects the *3 and executes the appropriate extension ie. att_xfer, however the read() in the extension att_xfer does not see the subsequent DTMF pressed on the phone ie. the destination extension number.
Cheers Shane
On Thu, May 10, 2012 at 2:44 PM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
I just had to laugh at my self for mixing up the 2 again... bind_meta_app is only applicable to that extension that the inbound call was made to. Since you've transferred to another extension, the bind_meta_app won't work anymore because it's not defined in the extension you're transferring to.
If you want this to happen, you'd have to manually define that bind_meta_app to those target extensions too. Remember, do this at your own peril - obvious misuse of bind_meta_app can open a huge security hole if you don't know what you're doing :)
On Wed, May 9, 2012 at 7:27 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote:
Thanks for the thoughts. As I said, I am already setting it to both legs - I will try simply trying one leg but am sceptical :-)
I also mentioned that I called the start_dtmf just before calling the read so unless I am doing something wrong here..... I'll try and post the XML tonight when I get home. Oh and it is an FXS card not an FXO of course since it has a phone plugged into it.
The question still remains though, why is the in-band DTMF detection working for the bind_meta_app digit detection but not after that?
Cheers Shane
On Thu, May 10, 2012 at 12:28 PM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
and crap, since I wasn't even reading anything here, on the subsequent transfers from your FXO card, enable the in-band DTMF detector that FS has. The details on the in-band DTMF detector is here:
http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_start_dtmf
But use this with caution, if there is a DTMF detector on the FXO card itself, make sure you disable it before using it.
On Wed, May 9, 2012 at 5:26 PM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
apologies for telling you the wrong thing. I was replying you from my phone btw :P
Yeah, bind_meta_app is the app you would use, but try changing it to point to the b-leg, not the a-leg
On Wed, May 9, 2012 at 4:12 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote:
Thanks. I am currently using bind_meta_app (set to both legs) already rather than bind_digits. I'll give bind_digits a shot and see if it behaves differently.
Note that I do detect the initial *3 digits and because bind_meta_app is both legs, this is successful no matter which direction the call is setup from. However once the dialplan moves to the extension the *3 is bound to, digits are no longer received.
The worrying thing for me is that ftdm_io.c doesn't even write to the log that it has received them (nor freetdm above that of course which is understandable) and I am surprised that the read() influences that since it works prior on the *3 digits.
Cheers Shane
On Thu, May 10, 2012 at 10:22 AM, curriegrad2004 <curriegrad2004@gmail.com> wrote: > > I'm guessing the bind digits in your analog card was set to listen > for > this sequence on the a-leg given if the call was being routed from > the > IP side to the analog side. > > Try changing that to listen on the b-leg. > > On 5/9/12, Shane Harrison <shane@longwhitecloud.com> wrote: > > Hi All, > > > > Have a situation where I have a call between a SIP phone and a > > FreeTDM > > channel. Pushing *3 on the analog FreeTDM phone is detected and > > this > > is > > bound to a dialplan extension (attended transfer) that does a > > read(): > > <action application="read" data="3 3 > > 'tone_stream://%(10000,0,350,440)' > > digits 30000 #"/> > > > > However pushing further digits on the analog phone ie. extension > > number > > of > > phone we wish to do an attended transfer to , doesn't result in > > the > > DTMF > > being detected. Note that this all works the other way around > > ie. > > using > > the SIP phone. > > > > When the *3 digits are pushed on the analog phone I see the logs > > report: > > > > ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF * (debug = 0) > > mod_freetdm.c:702 Queuing DTMF [*] in channel FreeTDM/2:1/ > > > > ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF 4 (debug = 0) > > > > mod_freetdm.c:702 Queuing DTMF [4] in channel FreeTDM/2:1/ > > > > When the further keys are pushed ftdm_io reports nothing. > > > > I have tried inserting a start_dtmf before the read() but it had > > no > > effect. > > Any thoughts as to why DTMF isn't being seen from the analog > > phone > > after > > the read()? > > > > Cheers > > Shane > > > > > > _________________________________________________________________________ > Professional FreeSWITCH Consulting Services: > consulting@freeswitch.org > http://www.freeswitchsolutions.com > > FreeSWITCH-powered IP PBX: The CudaTel Communication Server > http://www.cudatel.com > > Official FreeSWITCH Sites > http://www.freeswitch.org > http://wiki.freeswitch.org > http://www.cluecon.com > > 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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040
+64 4 5703870 Extn 875 +64 21 608919 (mobile)
"Solving your problems with the right technology"
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040
+64 4 5703870 Extn 875 +64 21 608919 (mobile)
"Solving your problems with the right technology"
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040
+64 4 5703870 Extn 875 +64 21 608919 (mobile)
"Solving your problems with the right technology"
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
Hi For calls originating from Freetdm extension I simply set up freetdm.conf.xml to use the XML dialplan and context fxs-ports like so: <span name="analogExtns"> <param name="hold-music" value="$${moh_uri}"/> <param name="tonegroup" value="nz"/> <param name="digit-timeout" value="2000"/> <param name="max-digits" value="11"/> <param name="callwaiting" value="true"/> <param name="answer-polarity-reverse" value="false"/> <param name="hangup-polarity-reverse" value="false"/> <!-- FreeSWITCH dialplan type and context to send the calls --> <param name="dialplan" value="XML"/> <param name="context" value="fxs-ports"/> </span> Then dialplan to get it into default context is: <context name="fxs-ports"> <extension name="outbound"> <condition field="destination_number" expression="^(.*)$"> <action application="set" data="toll_allow=local,domestic,international"/> <action application="transfer" data="$1 XML default"/> </condition> </extension> </context> For calls into FreeTDM I have the following dialplan: <extension name="Local_FXS_Extension"> <condition field="destination_number" expression="^(300)$"> <action application="set" data="dialed_extension=300"/> <action application="export" data="dialed_extension=300"/> <!-- bind_meta_app can have these args <key> [a|b|ab] [a|b|o|s] <app> --> <action application="bind_meta_app" data="1 ab s execute_extension::dx XML features"/> <action application="bind_meta_app" data="2 ab s record_session::$${recordings_dir}/archive/${strftime(%Y)}/${strftime(%b)}/${strftime(%d)}/${uuid}.wav"/> <action application="bind_meta_app" data="3 ab s execute_extension::cf XML features"/> <action application="bind_meta_app" data="4 ab s execute_extension::att_xfer XML features"/> <action application="set" data="ringback=${us-ring}"/> <action application="set" data="transfer_ringback=$${hold_music}"/> <action application="set" data="call_timeout=30"/> <!-- <action application="set" data="sip_exclude_contact=${network_addr}"/> --> <action application="set" data="hangup_after_bridge=true"/> <!--<action application="set" data="continue_on_fail=NORMAL_TEMPORARY_FAILURE,USER_BUSY,NO_ANSWER,TIMEOUT,NO_ROUTE_DESTINATION"/> --> <action application="set" data="continue_on_fail=true"/> <action application="hash" data="insert/${domain_name}-call_return/300/${caller_id_number}"/> <action application="hash" data="insert/${domain_name}-last_dial_ext/300/${uuid}"/> <action application="set" data="called_party_callgroup=${user_data(300@${domain_name} var callgroup)}"/> <!--<action application="export" data="nolocal:sip_secure_media=${user_data(300@${domain_name} var sip_secure_media)}"/>--> <action application="hash" data="insert/${domain_name}-last_dial/${called_party_callgroup}/${uuid}"/> <action application="bridge" data="freetdm/2/1"/> <action application="answer"/> <action application="sleep" data="1000"/> <!--<action application="bridge" data="loopback/app=voicemail:default ${domain_name} ${dialed_extension}"/>--> <action application="voicemail" data="default ${domain_name} 300"/> </condition> </extension> Cheers Shane On Fri, May 11, 2012 at 2:07 AM, curriegrad2004 <curriegrad2004@gmail.com>wrote:
It would be beneficial if you can post the dialplan on how FS handles the part where FreeTDM comes into play. I.e. the dialplan that does the transfer of the FreeTDM call into the default context. This seems to be opening up a can of worms here with FXS cards in FreeTDM...
On Wed, May 9, 2012 at 8:39 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote:
Happy for you to laugh at yourself, I'm just happy you are finding some time to take some interest in my problem. Much appreciated.
I think some clarity is required here. I am simply trying to do an attended transfer as per the wiki (except I set the bind_meta_app to both legs) http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_att_xfer
It works fine for SIP to SIP. For SIP to Freetdm it only works if the SIP is trying to do the transfer. If the FreeTDM is trying to do it ie. push *3 on the phone keypad, then the bind_meta_app works fine and detects the *3 and executes the appropriate extension ie. att_xfer, however the read() in the extension att_xfer does not see the subsequent DTMF pressed on the phone ie. the destination extension number.
Cheers Shane
On Thu, May 10, 2012 at 2:44 PM, curriegrad2004 < curriegrad2004@gmail.com> wrote:
I just had to laugh at my self for mixing up the 2 again... bind_meta_app is only applicable to that extension that the inbound call was made to. Since you've transferred to another extension, the bind_meta_app won't work anymore because it's not defined in the extension you're transferring to.
If you want this to happen, you'd have to manually define that bind_meta_app to those target extensions too. Remember, do this at your own peril - obvious misuse of bind_meta_app can open a huge security hole if you don't know what you're doing :)
On Wed, May 9, 2012 at 7:27 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote:
Thanks for the thoughts. As I said, I am already setting it to both legs - I will try simply trying one leg but am sceptical :-)
I also mentioned that I called the start_dtmf just before calling the read so unless I am doing something wrong here..... I'll try and post the XML tonight when I get home. Oh and it is an FXS card not an FXO of
course
since it has a phone plugged into it.
The question still remains though, why is the in-band DTMF detection working for the bind_meta_app digit detection but not after that?
Cheers Shane
On Thu, May 10, 2012 at 12:28 PM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
and crap, since I wasn't even reading anything here, on the
subsequent
transfers from your FXO card, enable the in-band DTMF detector that FS has. The details on the in-band DTMF detector is here:
http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_start_dtmf
But use this with caution, if there is a DTMF detector on the FXO card itself, make sure you disable it before using it.
On Wed, May 9, 2012 at 5:26 PM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
apologies for telling you the wrong thing. I was replying you from my phone btw :P
Yeah, bind_meta_app is the app you would use, but try changing it to point to the b-leg, not the a-leg
On Wed, May 9, 2012 at 4:12 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote: > Thanks. I am currently using bind_meta_app (set to both legs) > already > rather than bind_digits. I'll give bind_digits a shot and see if it > behaves > differently. > > Note that I do detect the initial *3 digits and because > bind_meta_app > is > both legs, this is successful no matter which direction the call is > setup > from. However once the dialplan moves to the extension the *3 is > bound > to, > digits are no longer received. > > The worrying thing for me is that ftdm_io.c doesn't even write to > the > log > that it has received them (nor freetdm above that of course which is > understandable) and I am surprised that the read() influences that > since it > works prior on the *3 digits. > > Cheers > Shane > > > > On Thu, May 10, 2012 at 10:22 AM, curriegrad2004 > <curriegrad2004@gmail.com> > wrote: >> >> I'm guessing the bind digits in your analog card was set to listen >> for >> this sequence on the a-leg given if the call was being routed from >> the >> IP side to the analog side. >> >> Try changing that to listen on the b-leg. >> >> On 5/9/12, Shane Harrison <shane@longwhitecloud.com> wrote: >> > Hi All, >> > >> > Have a situation where I have a call between a SIP phone and a >> > FreeTDM >> > channel. Pushing *3 on the analog FreeTDM phone is detected and >> > this >> > is >> > bound to a dialplan extension (attended transfer) that does a >> > read(): >> > <action application="read" data="3 3 >> > 'tone_stream://%(10000,0,350,440)' >> > digits 30000 #"/> >> > >> > However pushing further digits on the analog phone ie. extension >> > number >> > of >> > phone we wish to do an attended transfer to , doesn't result in >> > the >> > DTMF >> > being detected. Note that this all works the other way around >> > ie. >> > using >> > the SIP phone. >> > >> > When the *3 digits are pushed on the analog phone I see the logs >> > report: >> > >> > ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF * (debug = 0) >> > mod_freetdm.c:702 Queuing DTMF [*] in channel FreeTDM/2:1/ >> > >> > ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF 4 (debug = 0) >> > >> > mod_freetdm.c:702 Queuing DTMF [4] in channel FreeTDM/2:1/ >> > >> > When the further keys are pushed ftdm_io reports nothing. >> > >> > I have tried inserting a start_dtmf before the read() but it had >> > no >> > effect. >> > Any thoughts as to why DTMF isn't being seen from the analog >> > phone >> > after >> > the read()? >> > >> > Cheers >> > Shane >> > >> >> >> >>
>> Professional FreeSWITCH Consulting Services: >> consulting@freeswitch.org >> http://www.freeswitchsolutions.com >> >> FreeSWITCH-powered IP PBX: The CudaTel Communication Server >> http://www.cudatel.com >> >> Official FreeSWITCH Sites >> http://www.freeswitch.org >> http://wiki.freeswitch.org >> http://www.cluecon.com >> >> 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 > > > > > -- > Paragon Electronic Design Ltd > L6 Crest House > 92 Queens Drive > P0 Box 30449 > Lower Hutt 5040 > > +64 4 5703870 Extn 875 > +64 21 608919 (mobile) > > "Solving your problems with the right technology" > > > >
> Professional FreeSWITCH Consulting Services: > consulting@freeswitch.org > http://www.freeswitchsolutions.com > > FreeSWITCH-powered IP PBX: The CudaTel Communication Server > http://www.cudatel.com > > Official FreeSWITCH Sites > http://www.freeswitch.org > http://wiki.freeswitch.org > http://www.cluecon.com > > 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 >
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040
+64 4 5703870 Extn 875 +64 21 608919 (mobile)
"Solving your problems with the right technology"
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040
+64 4 5703870 Extn 875 +64 21 608919 (mobile)
"Solving your problems with the right technology"
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040 +64 4 5703870 Extn 875 +64 21 608919 (mobile) "Solving your problems with the right technology"
I would try adding <action application="start_dtmf" /> right before the bridge action for the dialplan for your FreeTDM FXS extensions. You may want to also apply the bind_meta_app actions on the dialplan for your FreeTDM outgoing calls for features like attended transfer to work. Hope this helps On Thu, May 10, 2012 at 12:55 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote:
Hi
For calls originating from Freetdm extension I simply set up freetdm.conf.xml to use the XML dialplan and context fxs-ports like so: <span name="analogExtns"> <param name="hold-music" value="$${moh_uri}"/> <param name="tonegroup" value="nz"/> <param name="digit-timeout" value="2000"/> <param name="max-digits" value="11"/> <param name="callwaiting" value="true"/> <param name="answer-polarity-reverse" value="false"/> <param name="hangup-polarity-reverse" value="false"/>
<!-- FreeSWITCH dialplan type and context to send the calls --> <param name="dialplan" value="XML"/> <param name="context" value="fxs-ports"/> </span>
Then dialplan to get it into default context is:
<context name="fxs-ports"> <extension name="outbound"> <condition field="destination_number" expression="^(.*)$"> <action application="set" data="toll_allow=local,domestic,international"/> <action application="transfer" data="$1 XML default"/> </condition> </extension> </context>
For calls into FreeTDM I have the following dialplan:
<extension name="Local_FXS_Extension"> <condition field="destination_number" expression="^(300)$"> <action application="set" data="dialed_extension=300"/> <action application="export" data="dialed_extension=300"/> <!-- bind_meta_app can have these args <key> [a|b|ab] [a|b|o|s] <app> --> <action application="bind_meta_app" data="1 ab s execute_extension::dx XML features"/> <action application="bind_meta_app" data="2 ab s record_session::$${recordings_dir}/archive/${strftime(%Y)}/${strftime(%b)}/${strftime(%d)}/${uuid}.wav"/> <action application="bind_meta_app" data="3 ab s execute_extension::cf XML features"/> <action application="bind_meta_app" data="4 ab s execute_extension::att_xfer XML features"/> <action application="set" data="ringback=${us-ring}"/> <action application="set" data="transfer_ringback=$${hold_music}"/> <action application="set" data="call_timeout=30"/> <!-- <action application="set" data="sip_exclude_contact=${network_addr}"/> --> <action application="set" data="hangup_after_bridge=true"/> <!--<action application="set" data="continue_on_fail=NORMAL_TEMPORARY_FAILURE,USER_BUSY,NO_ANSWER,TIMEOUT,NO_ROUTE_DESTINATION"/> --> <action application="set" data="continue_on_fail=true"/> <action application="hash" data="insert/${domain_name}-call_return/300/${caller_id_number}"/> <action application="hash" data="insert/${domain_name}-last_dial_ext/300/${uuid}"/> <action application="set" data="called_party_callgroup=${user_data(300@${domain_name} var callgroup)}"/> <!--<action application="export" data="nolocal:sip_secure_media=${user_data(300@${domain_name} var sip_secure_media)}"/>--> <action application="hash" data="insert/${domain_name}-last_dial/${called_party_callgroup}/${uuid}"/> <action application="bridge" data="freetdm/2/1"/> <action application="answer"/> <action application="sleep" data="1000"/> <!--<action application="bridge" data="loopback/app=voicemail:default ${domain_name} ${dialed_extension}"/>--> <action application="voicemail" data="default ${domain_name} 300"/> </condition> </extension>
Cheers Shane
On Fri, May 11, 2012 at 2:07 AM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
It would be beneficial if you can post the dialplan on how FS handles the part where FreeTDM comes into play. I.e. the dialplan that does the transfer of the FreeTDM call into the default context. This seems to be opening up a can of worms here with FXS cards in FreeTDM...
On Wed, May 9, 2012 at 8:39 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote:
Happy for you to laugh at yourself, I'm just happy you are finding some time to take some interest in my problem. Much appreciated.
I think some clarity is required here. I am simply trying to do an attended transfer as per the wiki (except I set the bind_meta_app to both legs) http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_att_xfer
It works fine for SIP to SIP. For SIP to Freetdm it only works if the SIP is trying to do the transfer. If the FreeTDM is trying to do it ie. push *3 on the phone keypad, then the bind_meta_app works fine and detects the *3 and executes the appropriate extension ie. att_xfer, however the read() in the extension att_xfer does not see the subsequent DTMF pressed on the phone ie. the destination extension number.
Cheers Shane
On Thu, May 10, 2012 at 2:44 PM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
I just had to laugh at my self for mixing up the 2 again... bind_meta_app is only applicable to that extension that the inbound call was made to. Since you've transferred to another extension, the bind_meta_app won't work anymore because it's not defined in the extension you're transferring to.
If you want this to happen, you'd have to manually define that bind_meta_app to those target extensions too. Remember, do this at your own peril - obvious misuse of bind_meta_app can open a huge security hole if you don't know what you're doing :)
On Wed, May 9, 2012 at 7:27 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote:
Thanks for the thoughts. As I said, I am already setting it to both legs - I will try simply trying one leg but am sceptical :-)
I also mentioned that I called the start_dtmf just before calling the read so unless I am doing something wrong here..... I'll try and post the XML tonight when I get home. Oh and it is an FXS card not an FXO of course since it has a phone plugged into it.
The question still remains though, why is the in-band DTMF detection working for the bind_meta_app digit detection but not after that?
Cheers Shane
On Thu, May 10, 2012 at 12:28 PM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
and crap, since I wasn't even reading anything here, on the subsequent transfers from your FXO card, enable the in-band DTMF detector that FS has. The details on the in-band DTMF detector is here:
http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_start_dtmf
But use this with caution, if there is a DTMF detector on the FXO card itself, make sure you disable it before using it.
On Wed, May 9, 2012 at 5:26 PM, curriegrad2004 <curriegrad2004@gmail.com> wrote: > apologies for telling you the wrong thing. I was replying you from > my > phone btw :P > > Yeah, bind_meta_app is the app you would use, but try changing it > to > point to the b-leg, not the a-leg > > On Wed, May 9, 2012 at 4:12 PM, Shane Harrison > <shane.harrison@paragon.co.nz> wrote: >> Thanks. I am currently using bind_meta_app (set to both legs) >> already >> rather than bind_digits. I'll give bind_digits a shot and see if >> it >> behaves >> differently. >> >> Note that I do detect the initial *3 digits and because >> bind_meta_app >> is >> both legs, this is successful no matter which direction the call >> is >> setup >> from. However once the dialplan moves to the extension the *3 is >> bound >> to, >> digits are no longer received. >> >> The worrying thing for me is that ftdm_io.c doesn't even write to >> the >> log >> that it has received them (nor freetdm above that of course which >> is >> understandable) and I am surprised that the read() influences >> that >> since it >> works prior on the *3 digits. >> >> Cheers >> Shane >> >> >> >> On Thu, May 10, 2012 at 10:22 AM, curriegrad2004 >> <curriegrad2004@gmail.com> >> wrote: >>> >>> I'm guessing the bind digits in your analog card was set to >>> listen >>> for >>> this sequence on the a-leg given if the call was being routed >>> from >>> the >>> IP side to the analog side. >>> >>> Try changing that to listen on the b-leg. >>> >>> On 5/9/12, Shane Harrison <shane@longwhitecloud.com> wrote: >>> > Hi All, >>> > >>> > Have a situation where I have a call between a SIP phone and a >>> > FreeTDM >>> > channel. Pushing *3 on the analog FreeTDM phone is detected >>> > and >>> > this >>> > is >>> > bound to a dialplan extension (attended transfer) that does a >>> > read(): >>> > <action application="read" data="3 3 >>> > 'tone_stream://%(10000,0,350,440)' >>> > digits 30000 #"/> >>> > >>> > However pushing further digits on the analog phone ie. >>> > extension >>> > number >>> > of >>> > phone we wish to do an attended transfer to , doesn't result >>> > in >>> > the >>> > DTMF >>> > being detected. Note that this all works the other way around >>> > ie. >>> > using >>> > the SIP phone. >>> > >>> > When the *3 digits are pushed on the analog phone I see the >>> > logs >>> > report: >>> > >>> > ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF * (debug = 0) >>> > mod_freetdm.c:702 Queuing DTMF [*] in channel FreeTDM/2:1/ >>> > >>> > ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF 4 (debug = 0) >>> > >>> > mod_freetdm.c:702 Queuing DTMF [4] in channel FreeTDM/2:1/ >>> > >>> > When the further keys are pushed ftdm_io reports nothing. >>> > >>> > I have tried inserting a start_dtmf before the read() but it >>> > had >>> > no >>> > effect. >>> > Any thoughts as to why DTMF isn't being seen from the analog >>> > phone >>> > after >>> > the read()? >>> > >>> > Cheers >>> > Shane >>> > >>> >>> >>> >>> >>> _________________________________________________________________________ >>> Professional FreeSWITCH Consulting Services: >>> consulting@freeswitch.org >>> http://www.freeswitchsolutions.com >>> >>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server >>> http://www.cudatel.com >>> >>> Official FreeSWITCH Sites >>> http://www.freeswitch.org >>> http://wiki.freeswitch.org >>> http://www.cluecon.com >>> >>> 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 >> >> >> >> >> -- >> Paragon Electronic Design Ltd >> L6 Crest House >> 92 Queens Drive >> P0 Box 30449 >> Lower Hutt 5040 >> >> +64 4 5703870 Extn 875 >> +64 21 608919 (mobile) >> >> "Solving your problems with the right technology" >> >> >> >> >> _________________________________________________________________________ >> Professional FreeSWITCH Consulting Services: >> consulting@freeswitch.org >> http://www.freeswitchsolutions.com >> >> FreeSWITCH-powered IP PBX: The CudaTel Communication Server >> http://www.cudatel.com >> >> Official FreeSWITCH Sites >> http://www.freeswitch.org >> http://wiki.freeswitch.org >> http://www.cluecon.com >> >> 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 >>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040
+64 4 5703870 Extn 875 +64 21 608919 (mobile)
"Solving your problems with the right technology"
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040
+64 4 5703870 Extn 875 +64 21 608919 (mobile)
"Solving your problems with the right technology"
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040
+64 4 5703870 Extn 875 +64 21 608919 (mobile)
"Solving your problems with the right technology"
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
Thanks, I'll give that a go. But it doesn't make sense to me because after the bridge action I am receiving DTMF OK from the Freetdm module. As for the bind_meta_app actions for outgoing - yes probably a good idea if I want to transfer after making an outgoing call out a trunk. Cheers Shane On Fri, May 11, 2012 at 11:48 AM, curriegrad2004 <curriegrad2004@gmail.com>wrote:
I would try adding <action application="start_dtmf" /> right before the bridge action for the dialplan for your FreeTDM FXS extensions. You may want to also apply the bind_meta_app actions on the dialplan for your FreeTDM outgoing calls for features like attended transfer to work.
Hope this helps
On Thu, May 10, 2012 at 12:55 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote:
Hi
For calls originating from Freetdm extension I simply set up freetdm.conf.xml to use the XML dialplan and context fxs-ports like so: <span name="analogExtns"> <param name="hold-music" value="$${moh_uri}"/> <param name="tonegroup" value="nz"/> <param name="digit-timeout" value="2000"/> <param name="max-digits" value="11"/> <param name="callwaiting" value="true"/> <param name="answer-polarity-reverse" value="false"/> <param name="hangup-polarity-reverse" value="false"/>
<!-- FreeSWITCH dialplan type and context to send the calls --> <param name="dialplan" value="XML"/> <param name="context" value="fxs-ports"/> </span>
Then dialplan to get it into default context is:
<context name="fxs-ports"> <extension name="outbound"> <condition field="destination_number" expression="^(.*)$"> <action application="set" data="toll_allow=local,domestic,international"/> <action application="transfer" data="$1 XML default"/> </condition> </extension> </context>
For calls into FreeTDM I have the following dialplan:
<extension name="Local_FXS_Extension"> <condition field="destination_number" expression="^(300)$"> <action application="set" data="dialed_extension=300"/> <action application="export" data="dialed_extension=300"/> <!-- bind_meta_app can have these args <key> [a|b|ab] [a|b|o|s] <app> --> <action application="bind_meta_app" data="1 ab s execute_extension::dx XML features"/> <action application="bind_meta_app" data="2 ab s
record_session::$${recordings_dir}/archive/${strftime(%Y)}/${strftime(%b)}/${strftime(%d)}/${uuid}.wav"/>
<action application="bind_meta_app" data="3 ab s execute_extension::cf XML features"/> <action application="bind_meta_app" data="4 ab s execute_extension::att_xfer XML features"/> <action application="set" data="ringback=${us-ring}"/> <action application="set"
data="transfer_ringback=$${hold_music}"/>
<action application="set" data="call_timeout=30"/> <!-- <action application="set" data="sip_exclude_contact=${network_addr}"/> --> <action application="set" data="hangup_after_bridge=true"/> <!--<action application="set"
data="continue_on_fail=NORMAL_TEMPORARY_FAILURE,USER_BUSY,NO_ANSWER,TIMEOUT,NO_ROUTE_DESTINATION"/>
--> <action application="set" data="continue_on_fail=true"/> <action application="hash" data="insert/${domain_name}-call_return/300/${caller_id_number}"/> <action application="hash" data="insert/${domain_name}-last_dial_ext/300/${uuid}"/> <action application="set" data="called_party_callgroup=${user_data(300@${domain_name} var callgroup)}"/> <!--<action application="export" data="nolocal:sip_secure_media=${user_data(300@${domain_name} var sip_secure_media)}"/>--> <action application="hash"
data="insert/${domain_name}-last_dial/${called_party_callgroup}/${uuid}"/>
<action application="bridge" data="freetdm/2/1"/> <action application="answer"/> <action application="sleep" data="1000"/> <!--<action application="bridge" data="loopback/app=voicemail:default ${domain_name} ${dialed_extension}"/>--> <action application="voicemail" data="default ${domain_name}
300"/>
</condition> </extension>
Cheers Shane
On Fri, May 11, 2012 at 2:07 AM, curriegrad2004 <
curriegrad2004@gmail.com>
wrote:
It would be beneficial if you can post the dialplan on how FS handles the part where FreeTDM comes into play. I.e. the dialplan that does the transfer of the FreeTDM call into the default context. This seems to be opening up a can of worms here with FXS cards in FreeTDM...
On Wed, May 9, 2012 at 8:39 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote:
Happy for you to laugh at yourself, I'm just happy you are finding
some
time to take some interest in my problem. Much appreciated.
I think some clarity is required here. I am simply trying to do an attended transfer as per the wiki (except I set the bind_meta_app to both legs) http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_att_xfer
It works fine for SIP to SIP. For SIP to Freetdm it only works if the SIP is trying to do the transfer. If the FreeTDM is trying to do it ie. push *3 on the phone keypad, then the bind_meta_app works fine and detects the *3 and executes the appropriate extension ie. att_xfer, however the read() in the extension att_xfer does not see the subsequent DTMF pressed on the phone ie. the destination extension number.
Cheers Shane
On Thu, May 10, 2012 at 2:44 PM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
I just had to laugh at my self for mixing up the 2 again... bind_meta_app is only applicable to that extension that the inbound call was made to. Since you've transferred to another extension, the bind_meta_app won't work anymore because it's not defined in the extension you're transferring to.
If you want this to happen, you'd have to manually define that bind_meta_app to those target extensions too. Remember, do this at your own peril - obvious misuse of bind_meta_app can open a huge security hole if you don't know what you're doing :)
On Wed, May 9, 2012 at 7:27 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote:
Thanks for the thoughts. As I said, I am already setting it to
both
legs - I will try simply trying one leg but am sceptical :-)
I also mentioned that I called the start_dtmf just before calling the read so unless I am doing something wrong here..... I'll try and post the XML tonight when I get home. Oh and it is an FXS card not an FXO of course since it has a phone plugged into it.
The question still remains though, why is the in-band DTMF detection working for the bind_meta_app digit detection but not after that?
Cheers Shane
On Thu, May 10, 2012 at 12:28 PM, curriegrad2004 <curriegrad2004@gmail.com> wrote: > > and crap, since I wasn't even reading anything here, on the > subsequent > transfers from your FXO card, enable the in-band DTMF detector that > FS > has. The details on the in-band DTMF detector is here: > > http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_start_dtmf > > But use this with caution, if there is a DTMF detector on the FXO > card > itself, make sure you disable it before using it. > > On Wed, May 9, 2012 at 5:26 PM, curriegrad2004 > <curriegrad2004@gmail.com> > wrote: > > apologies for telling you the wrong thing. I was replying you from > > my > > phone btw :P > > > > Yeah, bind_meta_app is the app you would use, but try changing it > > to > > point to the b-leg, not the a-leg > > > > On Wed, May 9, 2012 at 4:12 PM, Shane Harrison > > <shane.harrison@paragon.co.nz> wrote: > >> Thanks. I am currently using bind_meta_app (set to both legs) > >> already > >> rather than bind_digits. I'll give bind_digits a shot and see if > >> it > >> behaves > >> differently. > >> > >> Note that I do detect the initial *3 digits and because > >> bind_meta_app > >> is > >> both legs, this is successful no matter which direction the call > >> is > >> setup > >> from. However once the dialplan moves to the extension the *3 is > >> bound > >> to, > >> digits are no longer received. > >> > >> The worrying thing for me is that ftdm_io.c doesn't even write to > >> the > >> log > >> that it has received them (nor freetdm above that of course which > >> is > >> understandable) and I am surprised that the read() influences > >> that > >> since it > >> works prior on the *3 digits. > >> > >> Cheers > >> Shane > >> > >> > >> > >> On Thu, May 10, 2012 at 10:22 AM, curriegrad2004 > >> <curriegrad2004@gmail.com> > >> wrote: > >>> > >>> I'm guessing the bind digits in your analog card was set to > >>> listen > >>> for > >>> this sequence on the a-leg given if the call was being routed > >>> from > >>> the > >>> IP side to the analog side. > >>> > >>> Try changing that to listen on the b-leg. > >>> > >>> On 5/9/12, Shane Harrison <shane@longwhitecloud.com> wrote: > >>> > Hi All, > >>> > > >>> > Have a situation where I have a call between a SIP phone and a > >>> > FreeTDM > >>> > channel. Pushing *3 on the analog FreeTDM phone is detected > >>> > and > >>> > this > >>> > is > >>> > bound to a dialplan extension (attended transfer) that does a > >>> > read(): > >>> > <action application="read" data="3 3 > >>> > 'tone_stream://%(10000,0,350,440)' > >>> > digits 30000 #"/> > >>> > > >>> > However pushing further digits on the analog phone ie. > >>> > extension > >>> > number > >>> > of > >>> > phone we wish to do an attended transfer to , doesn't result > >>> > in > >>> > the > >>> > DTMF > >>> > being detected. Note that this all works the other way around > >>> > ie. > >>> > using > >>> > the SIP phone. > >>> > > >>> > When the *3 digits are pushed on the analog phone I see the > >>> > logs > >>> > report: > >>> > > >>> > ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF * (debug = 0) > >>> > mod_freetdm.c:702 Queuing DTMF [*] in channel FreeTDM/2:1/ > >>> > > >>> > ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF 4 (debug = 0) > >>> > > >>> > mod_freetdm.c:702 Queuing DTMF [4] in channel FreeTDM/2:1/ > >>> > > >>> > When the further keys are pushed ftdm_io reports nothing. > >>> > > >>> > I have tried inserting a start_dtmf before the read() but it > >>> > had > >>> > no > >>> > effect. > >>> > Any thoughts as to why DTMF isn't being seen from the analog > >>> > phone > >>> > after > >>> > the read()? > >>> > > >>> > Cheers > >>> > Shane > >>> > > >>> > >>> > >>> > >>> > >>>
> >>> Professional FreeSWITCH Consulting Services: > >>> consulting@freeswitch.org > >>> http://www.freeswitchsolutions.com > >>> > >>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server > >>> http://www.cudatel.com > >>> > >>> Official FreeSWITCH Sites > >>> http://www.freeswitch.org > >>> http://wiki.freeswitch.org > >>> http://www.cluecon.com > >>> > >>> 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 > >> > >> > >> > >> > >> -- > >> Paragon Electronic Design Ltd > >> L6 Crest House > >> 92 Queens Drive > >> P0 Box 30449 > >> Lower Hutt 5040 > >> > >> +64 4 5703870 Extn 875 > >> +64 21 608919 (mobile) > >> > >> "Solving your problems with the right technology" > >> > >> > >> > >> > >>
> >> Professional FreeSWITCH Consulting Services: > >> consulting@freeswitch.org > >> http://www.freeswitchsolutions.com > >> > >> FreeSWITCH-powered IP PBX: The CudaTel Communication Server > >> http://www.cudatel.com > >> > >> Official FreeSWITCH Sites > >> http://www.freeswitch.org > >> http://wiki.freeswitch.org > >> http://www.cluecon.com > >> > >> 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 > >> > > > >
> Professional FreeSWITCH Consulting Services: > consulting@freeswitch.org > http://www.freeswitchsolutions.com > > FreeSWITCH-powered IP PBX: The CudaTel Communication Server > http://www.cudatel.com > > Official FreeSWITCH Sites > http://www.freeswitch.org > http://wiki.freeswitch.org > http://www.cluecon.com > > 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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040
+64 4 5703870 Extn 875 +64 21 608919 (mobile)
"Solving your problems with the right technology"
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040
+64 4 5703870 Extn 875 +64 21 608919 (mobile)
"Solving your problems with the right technology"
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040
+64 4 5703870 Extn 875 +64 21 608919 (mobile)
"Solving your problems with the right technology"
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
To be quite honest, I wouldn't expect FreeTDM to collect any more digits once the call is in the dialplan. That's why I suggested to use in-band dtmf detection after the call gets bridged from the FreeTDM side to the SIP side of things. The same idea also applies to real TDM links (i.e. no analog stuff here)., meaning you have to do in-band detection on these type of links. I've seen a person on this ML thinking that RBS in a TDM link carries DTMF :P On Thu, May 10, 2012 at 5:56 PM, Shane Harrison <shane@longwhitecloud.com> wrote:
Thanks, I'll give that a go. But it doesn't make sense to me because after the bridge action I am receiving DTMF OK from the Freetdm module.
As for the bind_meta_app actions for outgoing - yes probably a good idea if I want to transfer after making an outgoing call out a trunk.
Cheers Shane
On Fri, May 11, 2012 at 11:48 AM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
I would try adding <action application="start_dtmf" /> right before the bridge action for the dialplan for your FreeTDM FXS extensions. You may want to also apply the bind_meta_app actions on the dialplan for your FreeTDM outgoing calls for features like attended transfer to work.
Hope this helps
On Thu, May 10, 2012 at 12:55 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote:
Hi
For calls originating from Freetdm extension I simply set up freetdm.conf.xml to use the XML dialplan and context fxs-ports like so: <span name="analogExtns"> <param name="hold-music" value="$${moh_uri}"/> <param name="tonegroup" value="nz"/> <param name="digit-timeout" value="2000"/> <param name="max-digits" value="11"/> <param name="callwaiting" value="true"/> <param name="answer-polarity-reverse" value="false"/> <param name="hangup-polarity-reverse" value="false"/>
<!-- FreeSWITCH dialplan type and context to send the calls --> <param name="dialplan" value="XML"/> <param name="context" value="fxs-ports"/> </span>
Then dialplan to get it into default context is:
<context name="fxs-ports"> <extension name="outbound"> <condition field="destination_number" expression="^(.*)$"> <action application="set" data="toll_allow=local,domestic,international"/> <action application="transfer" data="$1 XML default"/> </condition> </extension> </context>
For calls into FreeTDM I have the following dialplan:
<extension name="Local_FXS_Extension"> <condition field="destination_number" expression="^(300)$"> <action application="set" data="dialed_extension=300"/> <action application="export" data="dialed_extension=300"/> <!-- bind_meta_app can have these args <key> [a|b|ab] [a|b|o|s] <app> --> <action application="bind_meta_app" data="1 ab s execute_extension::dx XML features"/> <action application="bind_meta_app" data="2 ab s
record_session::$${recordings_dir}/archive/${strftime(%Y)}/${strftime(%b)}/${strftime(%d)}/${uuid}.wav"/> <action application="bind_meta_app" data="3 ab s execute_extension::cf XML features"/> <action application="bind_meta_app" data="4 ab s execute_extension::att_xfer XML features"/> <action application="set" data="ringback=${us-ring}"/> <action application="set" data="transfer_ringback=$${hold_music}"/> <action application="set" data="call_timeout=30"/> <!-- <action application="set" data="sip_exclude_contact=${network_addr}"/> --> <action application="set" data="hangup_after_bridge=true"/> <!--<action application="set"
data="continue_on_fail=NORMAL_TEMPORARY_FAILURE,USER_BUSY,NO_ANSWER,TIMEOUT,NO_ROUTE_DESTINATION"/> --> <action application="set" data="continue_on_fail=true"/> <action application="hash" data="insert/${domain_name}-call_return/300/${caller_id_number}"/> <action application="hash" data="insert/${domain_name}-last_dial_ext/300/${uuid}"/> <action application="set" data="called_party_callgroup=${user_data(300@${domain_name} var callgroup)}"/> <!--<action application="export" data="nolocal:sip_secure_media=${user_data(300@${domain_name} var sip_secure_media)}"/>--> <action application="hash"
data="insert/${domain_name}-last_dial/${called_party_callgroup}/${uuid}"/> <action application="bridge" data="freetdm/2/1"/> <action application="answer"/> <action application="sleep" data="1000"/> <!--<action application="bridge" data="loopback/app=voicemail:default ${domain_name} ${dialed_extension}"/>--> <action application="voicemail" data="default ${domain_name} 300"/> </condition> </extension>
Cheers Shane
On Fri, May 11, 2012 at 2:07 AM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
It would be beneficial if you can post the dialplan on how FS handles the part where FreeTDM comes into play. I.e. the dialplan that does the transfer of the FreeTDM call into the default context. This seems to be opening up a can of worms here with FXS cards in FreeTDM...
On Wed, May 9, 2012 at 8:39 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote:
Happy for you to laugh at yourself, I'm just happy you are finding some time to take some interest in my problem. Much appreciated.
I think some clarity is required here. I am simply trying to do an attended transfer as per the wiki (except I set the bind_meta_app to both legs) http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_att_xfer
It works fine for SIP to SIP. For SIP to Freetdm it only works if the SIP is trying to do the transfer. If the FreeTDM is trying to do it ie. push *3 on the phone keypad, then the bind_meta_app works fine and detects the *3 and executes the appropriate extension ie. att_xfer, however the read() in the extension att_xfer does not see the subsequent DTMF pressed on the phone ie. the destination extension number.
Cheers Shane
On Thu, May 10, 2012 at 2:44 PM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
I just had to laugh at my self for mixing up the 2 again... bind_meta_app is only applicable to that extension that the inbound call was made to. Since you've transferred to another extension, the bind_meta_app won't work anymore because it's not defined in the extension you're transferring to.
If you want this to happen, you'd have to manually define that bind_meta_app to those target extensions too. Remember, do this at your own peril - obvious misuse of bind_meta_app can open a huge security hole if you don't know what you're doing :)
On Wed, May 9, 2012 at 7:27 PM, Shane Harrison <shane.harrison@paragon.co.nz> wrote: > Thanks for the thoughts. As I said, I am already setting it to > both > legs - > I will try simply trying one leg but am sceptical :-) > > I also mentioned that I called the start_dtmf just before calling > the > read > so unless I am doing something wrong here..... I'll try and post > the > XML > tonight when I get home. Oh and it is an FXS card not an FXO of > course > since it has a phone plugged into it. > > The question still remains though, why is the in-band DTMF > detection > working > for the bind_meta_app digit detection but not after that? > > Cheers > Shane > > > On Thu, May 10, 2012 at 12:28 PM, curriegrad2004 > <curriegrad2004@gmail.com> > wrote: >> >> and crap, since I wasn't even reading anything here, on the >> subsequent >> transfers from your FXO card, enable the in-band DTMF detector >> that >> FS >> has. The details on the in-band DTMF detector is here: >> >> http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_start_dtmf >> >> But use this with caution, if there is a DTMF detector on the FXO >> card >> itself, make sure you disable it before using it. >> >> On Wed, May 9, 2012 at 5:26 PM, curriegrad2004 >> <curriegrad2004@gmail.com> >> wrote: >> > apologies for telling you the wrong thing. I was replying you >> > from >> > my >> > phone btw :P >> > >> > Yeah, bind_meta_app is the app you would use, but try changing >> > it >> > to >> > point to the b-leg, not the a-leg >> > >> > On Wed, May 9, 2012 at 4:12 PM, Shane Harrison >> > <shane.harrison@paragon.co.nz> wrote: >> >> Thanks. I am currently using bind_meta_app (set to both legs) >> >> already >> >> rather than bind_digits. I'll give bind_digits a shot and see >> >> if >> >> it >> >> behaves >> >> differently. >> >> >> >> Note that I do detect the initial *3 digits and because >> >> bind_meta_app >> >> is >> >> both legs, this is successful no matter which direction the >> >> call >> >> is >> >> setup >> >> from. However once the dialplan moves to the extension the *3 >> >> is >> >> bound >> >> to, >> >> digits are no longer received. >> >> >> >> The worrying thing for me is that ftdm_io.c doesn't even write >> >> to >> >> the >> >> log >> >> that it has received them (nor freetdm above that of course >> >> which >> >> is >> >> understandable) and I am surprised that the read() influences >> >> that >> >> since it >> >> works prior on the *3 digits. >> >> >> >> Cheers >> >> Shane >> >> >> >> >> >> >> >> On Thu, May 10, 2012 at 10:22 AM, curriegrad2004 >> >> <curriegrad2004@gmail.com> >> >> wrote: >> >>> >> >>> I'm guessing the bind digits in your analog card was set to >> >>> listen >> >>> for >> >>> this sequence on the a-leg given if the call was being routed >> >>> from >> >>> the >> >>> IP side to the analog side. >> >>> >> >>> Try changing that to listen on the b-leg. >> >>> >> >>> On 5/9/12, Shane Harrison <shane@longwhitecloud.com> wrote: >> >>> > Hi All, >> >>> > >> >>> > Have a situation where I have a call between a SIP phone >> >>> > and a >> >>> > FreeTDM >> >>> > channel. Pushing *3 on the analog FreeTDM phone is >> >>> > detected >> >>> > and >> >>> > this >> >>> > is >> >>> > bound to a dialplan extension (attended transfer) that does >> >>> > a >> >>> > read(): >> >>> > <action application="read" data="3 3 >> >>> > 'tone_stream://%(10000,0,350,440)' >> >>> > digits 30000 #"/> >> >>> > >> >>> > However pushing further digits on the analog phone ie. >> >>> > extension >> >>> > number >> >>> > of >> >>> > phone we wish to do an attended transfer to , doesn't >> >>> > result >> >>> > in >> >>> > the >> >>> > DTMF >> >>> > being detected. Note that this all works the other way >> >>> > around >> >>> > ie. >> >>> > using >> >>> > the SIP phone. >> >>> > >> >>> > When the *3 digits are pushed on the analog phone I see the >> >>> > logs >> >>> > report: >> >>> > >> >>> > ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF * (debug = 0) >> >>> > mod_freetdm.c:702 Queuing DTMF [*] in channel FreeTDM/2:1/ >> >>> > >> >>> > ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF 4 (debug = 0) >> >>> > >> >>> > mod_freetdm.c:702 Queuing DTMF [4] in channel FreeTDM/2:1/ >> >>> > >> >>> > When the further keys are pushed ftdm_io reports nothing. >> >>> > >> >>> > I have tried inserting a start_dtmf before the read() but >> >>> > it >> >>> > had >> >>> > no >> >>> > effect. >> >>> > Any thoughts as to why DTMF isn't being seen from the >> >>> > analog >> >>> > phone >> >>> > after >> >>> > the read()? >> >>> > >> >>> > Cheers >> >>> > Shane >> >>> > >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> _________________________________________________________________________ >> >>> Professional FreeSWITCH Consulting Services: >> >>> consulting@freeswitch.org >> >>> http://www.freeswitchsolutions.com >> >>> >> >>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server >> >>> http://www.cudatel.com >> >>> >> >>> Official FreeSWITCH Sites >> >>> http://www.freeswitch.org >> >>> http://wiki.freeswitch.org >> >>> http://www.cluecon.com >> >>> >> >>> 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 >> >> >> >> >> >> >> >> >> >> -- >> >> Paragon Electronic Design Ltd >> >> L6 Crest House >> >> 92 Queens Drive >> >> P0 Box 30449 >> >> Lower Hutt 5040 >> >> >> >> +64 4 5703870 Extn 875 >> >> +64 21 608919 (mobile) >> >> >> >> "Solving your problems with the right technology" >> >> >> >> >> >> >> >> >> >> >> >> _________________________________________________________________________ >> >> Professional FreeSWITCH Consulting Services: >> >> consulting@freeswitch.org >> >> http://www.freeswitchsolutions.com >> >> >> >> FreeSWITCH-powered IP PBX: The CudaTel Communication Server >> >> http://www.cudatel.com >> >> >> >> Official FreeSWITCH Sites >> >> http://www.freeswitch.org >> >> http://wiki.freeswitch.org >> >> http://www.cluecon.com >> >> >> >> 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 >> >> >> >> >> >> >> _________________________________________________________________________ >> Professional FreeSWITCH Consulting Services: >> consulting@freeswitch.org >> http://www.freeswitchsolutions.com >> >> FreeSWITCH-powered IP PBX: The CudaTel Communication Server >> http://www.cudatel.com >> >> Official FreeSWITCH Sites >> http://www.freeswitch.org >> http://wiki.freeswitch.org >> http://www.cluecon.com >> >> 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 > > > > > -- > Paragon Electronic Design Ltd > L6 Crest House > 92 Queens Drive > P0 Box 30449 > Lower Hutt 5040 > > +64 4 5703870 Extn 875 > +64 21 608919 (mobile) > > "Solving your problems with the right technology" > > > > > _________________________________________________________________________ > Professional FreeSWITCH Consulting Services: > consulting@freeswitch.org > http://www.freeswitchsolutions.com > > FreeSWITCH-powered IP PBX: The CudaTel Communication Server > http://www.cudatel.com > > Official FreeSWITCH Sites > http://www.freeswitch.org > http://wiki.freeswitch.org > http://www.cluecon.com > > 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 >
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040
+64 4 5703870 Extn 875 +64 21 608919 (mobile)
"Solving your problems with the right technology"
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Paragon Electronic Design Ltd L6 Crest House 92 Queens Drive P0 Box 30449 Lower Hutt 5040
+64 4 5703870 Extn 875 +64 21 608919 (mobile)
"Solving your problems with the right technology"
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
participants (3)
-
curriegrad2004
-
Shane Harrison
-
Shane Harrison