According to CDRS's: Session:A -> Inbound, PCMU-8000 Session B -> FS to FS, PCMU-8000 Session C -> Outbound, PMCA-8000 According to vars.xml: <X-PRE-PROCESS cmd="set" data="global_codec_prefs=G711,PCMU,PCMA"/> <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=G711,PCMU,PCMA"/> Regards, Mike. 2012/5/31 JRichey <jrichey@itltd.net>:

What CODECs are being used?

In-band DTMF won't work correctly with compressed CODECs like G.729.

-----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org]On Behalf Of Michael Lutz Sent: Thursday, May 31, 2012 2:12 AM To: FreeSWITCH Users Help Subject: [Freeswitch-users] DTMF Passthrough on different legs

Hi Guys,

I am stuck with a bit of a problem I cannot figure out where it is going wrong..

Here's my situation,

I have an inbound call, comming from an external provider, they don't support RFC2833 so I turn on inband detection using 'start_dtmf' in the dialplan. This works ok, for the incomming channel and IVR provided (via Lua) to the caller. (Though sometimes it seems to misinterpret and returns wrong keys..) (Session:A)

After that, this call is bridged (via Lua to a a new inbound session on the same switch) (without specifying start_dtmf) so RC2388 is used by default (?) (Session:B)

This new sessions is playing soem audio (Lua) and is heard by the original caller (the two sessions are bridged).

Seperatly I have an inbound ESL connection where I do an origanate using a originate {execute_on_answer=start_dtmf, .... etc) &park() to setup an new external call via the same gateway (they don't support RFC2388 so I activate the inband detection on the b-leg to receive the digits. Let's call this leg Session:C.

After the orignated call is answered I bridge the parked call with the previous session (Session:B), so at the end Session:A and Session:B can talk to each other.

Al this works perfectly.

[Incommming call] Session:A ----- INBAND ------> Bridge(FS.Lua) ---> Session:B ---- RFC2388 ---->   FS.Bridge ---> Session:C --- INBAND ------> ESL destination number

My symptoms are...

1. I have a customer who had a IVR on his own side, (Session:C) and requires input from Session:A. The weird thing is that it seems the input is wrong. Keys entered do not correspond to what his IVR is receiving. As if newly dtmfs are generated somewhere. When I switch to another inbound provider, making Session:A using rfc2388 and not inband, but do dialout via the provider using inband detection. It seems to work fine.

2. Not being able to get the dtmf's from the ESL Destination number (Session:C). I'm reading this by subscribing to events via ESL for that particulair uuid. When I have a connection (inbound) without inband detection it seems to get the DTMF's from Session:C without any problems. Which makes it weird for me.

note: I know the setup is a bit odd, but Session A cannot exit it's Lua script, so I needed to do a workaround to be able to keep te lua alive and being able to control the call (audio) via ESL.

I realy need some help on this one, becuase we have a lot of customers complaining about not responding to dtmf's or receving invalid input in the (FS) IVR.

Thanks for you help,

Regards, Mike.

_________________________________________________________________________ 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

Join Us At ClueCon - Aug 7-9, 2012

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

Join Us At ClueCon - Aug 7-9, 2012

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

1. I have a customer who had a IVR on his own side, (Session:C) and requires input from Session:A. The weird thing is that it seems the input is wrong. Keys entered do not correspond to what his IVR is receiving. As if newly dtmfs are generated somewhere. When I switch to another inbound provider, making Session:A using rfc2388 and not inband, but do dialout via the provider using inband detection. It seems to work fine.

start_dtmf adds a media bug that detects dtmf tones in the audio and generates the out of band rfc2833 messages. It's doesn't remove the inband ones though. If the receiving end accepts both it'll detect duplicated digits. This may be your issue. You may also be generating duplicate rfc2833 yourself if them sender is already sending both. You should only use start_dtmf if the sender only sends inband and receiver only accepts outofband. It'll also have to decode all audio and examine the audio to detect tones - so running it only when required also decreases server load. -Steve Sent from my iPad On 31 May 2012, at 18:16, JRichey <jrichey@itltd.net> wrote:

1. I have a customer who had a IVR on his own side, (Session:C) and requires input from Session:A. The weird thing is that it seems the input is wrong. Keys entered do not correspond to what his IVR is receiving. As if newly dtmfs are generated somewhere. When I switch to another inbound provider, making Session:A using rfc2388 and not inband, but do dialout via the provider using inband detection. It seems to work fine.