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.