[Freeswitch-users] FS ends call on DTMF **

[Cliff Wells]

Hi,

I've got a Lua application that takes the caller id and generates
particular sequences of DTMF tones (for a testing system) based on the
CID.  If I call into the system (using my cellphone), it correctly plays
the sequence.   However, if I press ** on the keypad it stops the
generated DTMF tones and then apparently hangs up.    
This wouldn't be a huge issue (the app isn't supposed to receive any
DTMF anyway) except that one of the systems calling in apparently has
enough echo on the remote end that the DTMF I'm generating is being
echoed back to FS and the first two DTMF tones I generate are, of
course, "**", so the end result is the system calls into FS, gets two
tones and the call is terminated.

As an aside, it appears that ** is unique in this way.   If I dial "99"
or "77", the DTMF still pauses, but then resumes (or maybe restarts...
it's difficult to tell).

I was using an older version of FS, so I did "make current" a couple of
hours ago, but it didn't help.

My one and only dialplan is this:

  <extension name="responder">
    <condition field="destination_number" expression="^(.*)$">
      <action application="lua" data="responder.lua"/>
    </condition>
  </extension>

And responder.lua does this:

session:answer ()
session:sleep (3000)
session:execute ("playback", genstream (val))  -- genstream uses the CID to produce a tone_stream
session:hangup()

(clearly there's a bit more to the Lua app, but nothing relevant to this
issue).

I see this in the console when this happens:

2010-12-17 01:04:34.603404 [NOTICE] mod_dptools.c:920 Channel [sofia/internal/3232269108 at 99.99.99.99] has been answered
EXECUTE sofia/internal/3232269108 at 99.99.99.99 lua(responder.lua)
2010-12-17 01:04:34.673314 [DEBUG] sofia.c:4606 Channel sofia/internal/5551231234 at 99.99.99.99 entering state [ready][200]
2010-12-17 01:04:34.751303 [DEBUG] switch_rtp.c:2657 Correct ip/port confirmed.
EXECUTE sofia/internal/5551231234 at 99.99.99.99 playback(tone_stream://*(200,200);*(200,200); ...
2010-12-17 01:04:37.915169 [DEBUG] switch_ivr_play_say.c:1236 Codec Activated L16 at 8000hz 1 channels 20ms
2010-12-17 01:04:38.295137 [DEBUG] switch_rtp.c:3033 RTP RECV DTMF *:1440
2010-12-17 01:04:38.295137 [DEBUG] mod_dptools.c:1634 Digit *
2010-12-17 01:04:38.295137 [DEBUG] switch_ivr_play_say.c:1573 done playing file
2010-12-17 01:04:38.295137 [DEBUG] switch_cpp.cpp:602 CoreSession::hangup
2010-12-17 01:04:38.295137 [DEBUG] switch_channel.c:2455 (sofia/internal/5551231234 at 99.99.99.99) Callstate Change ACTIVE -> HANGUP
2010-12-17 01:04:38.295137 [NOTICE] switch_cpp.cpp:604 Hangup sofia/internal/5551231234 at 99.99.99.99 [CS_EXECUTE] [NORMAL_CLEARING]
2010-12-17 01:04:38.295137 [DEBUG] switch_channel.c:2471 Send signal sofia/internal/5551231234 at 99.99.99.99 [KILL]
2010-12-17 01:04:38.295137 [DEBUG] switch_core_session.c:1083 Send signal sofia/internal/5551231234 at 99.99.99.99 [BREAK]
2010-12-17 01:04:38.295137 [DEBUG] switch_cpp.cpp:972 sofia/internal/5551231234 at 99.99.99.99 destroy/unlink session from object
2010-12-17 01:04:38.295137 [DEBUG] switch_core_session.c:1998 sofia/internal/5551231234 at 99.99.99.99 skip receive message [APPLICATION_EXEC_COMPLETE] (channel is hungup already)

At this point I'd be content with a simple workaround (mute the inbound
audio, ignore DTMF, etc), since I do not need any feedback from the
other end.


Cliff Wells <cliff at develix.com>