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@99.99.99.99] has been answered EXECUTE sofia/internal/3232269108@99.99.99.99 lua(responder.lua) 2010-12-17 01:04:34.673314 [DEBUG] sofia.c:4606 Channel sofia/internal/5551231234@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@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@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@99.99.99.99) Callstate Change ACTIVE -> HANGUP 2010-12-17 01:04:38.295137 [NOTICE] switch_cpp.cpp:604 Hangup sofia/internal/5551231234@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@99.99.99.99 [KILL] 2010-12-17 01:04:38.295137 [DEBUG] switch_core_session.c:1083 Send signal sofia/internal/5551231234@99.99.99.99 [BREAK] 2010-12-17 01:04:38.295137 [DEBUG] switch_cpp.cpp:972 sofia/internal/5551231234@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@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@develix.com>