(false detected and) generated dtmf when bridging calls using uuid_bridge on any leg wich uses start_dtmf

2 Jul 2012

      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.

Michael Lutz

Anthony Minessale

tags

participants (2)