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"