Hi, Trying again... I have a serious issue with randomly generated dtmf's on bridged calls on where i have a provider wich does not support rfc2833 and I have to use start_dtmf in the dialplan to make dtmf's work. My setup is: A> 1 incomming call, using start_dtmf to activate inband dtmf detection. This makes dtmf work correctly in my (Lua) IVR scripts and respond to digits. (not all the time, but that might be a different issue?) B> This call is at some point in IVR bridged directly from the Lua script to new call on the same switch (no start_dtmf). This script activates a Lua scrpt from the dialplan which does some plays. (so caller A can hear this- as they are bridged) (there is no 'start_dtmf' on this incomming call in the dialplan) C> The Lua script B then triggers a an inbound ESL connection which is generating a completely new session using an api call "originate ... &park()" When C answers the phone, C is bridged to B using api call "uuid_bridge C B" after that B is instructed to end the Lua script to make the bridge work (the bridge works only after the Lua scripts ended) from my ESL connection I have two listeners, one on A and one on C to listen for (dtmf) events. So, there are two bridges, A<->B and B<->C, becuase B is a new incomming session this al works perfectly, and I can do asynchronous stuff from my ESL server and I do need to leave my orignial Lua script A (which is required) The problem: When the incomming call A is using inband detection (start_dtmf in the dialplan) I get a lot (almost always) spontaneous generated dtmf events on the A legg. I am 1000% sure they are not pressed. My ESL listener on A detects them and is showing them in my log. It mostly 'detects' generaly unused dtmfs like 'A' and 'D'. but sometimes also just 'normal' digits. (like '7' in my pastebin) The behaviour leads to hearable dtmf's to C, which of course find it very anoying to hear beeps. They are not heard on the A leg. I can easily reproduce same behaviour on an rfc2833 incomming call and forcing the C leg on inband detection using an "execute_on_answer=start_dtmf" in my originate call. Which is the same setup as my case, but just switched the leggs. Th exact same behaviour will occur but only the dtmf's are detected/generated on the C leg (called user) instead of the A leg (calling user). I have added switchlogs on pastebin: http://pastebin.com/WwW3eDgK for this particulair situation. Please ANY help would be appreciated! I was thinking using for example 'stop_generate_dtmf', to at least make FS stop generating RTP dtmf when (falsely) detecting them. But that doesn't solve the root cause of course, and I have no idea what the consequence might be as that function is not very well documented... Thanks for any help, Regards, Mike.