VoIP Mailing List Archives

[pete at privateconnect...]

Hey guys. Has anyone else experienced the inability to detect/receive DTMF tones? Just yesterday I had about 4-5 hours where One of my IVR scripts would not detect 1, 2 or 3, but detected the other digits perfectly. If I removed the sound file that was playing, and substituted silence it worked, add the sound file in, and it broke. I have a strong feeling that this is not an issue with FS, but with an upstream system. But wanted to know if anyone has seen this before, and how they went about identifying the culprit and/or fixing it.

Some background:
<![if !supportLists]>- <![endif]>Using FS trunk
<![if !supportLists]>- <![endif]>Both legs of the call were via SIP gateway.
<![if !supportLists]>- <![endif]>Setting loglevel to 9 (console and sofia) showed that the RTP packets were not received by FS for 1/2/3 but were received for other digits
<![if !supportLists]>- <![endif]>Both legs of calls were to/from ATT cell phones
<![if !supportLists]>- <![endif]> Was using session:setInputCallback() to receive tones, did not test with playAndGetDigits()

Thanks for any help.
-pete

[brian at freeswitch.org]

What are you doing exactly? Can you provide us an example.

/b

On Apr 16, 2009, at 3:49 PM, Pete Mueller wrote:

[pete at privateconnect...]

below is the lua script that is running when the caller dials in. As mentioned before, swaping the streamFile and sleep make the problem go away.

I am experiencing different issues all related to DTMF tones, again, I don't think FS is the problem. But I'm wondering how to find the culprit.

Issues:
1. for 4-5 hours the other day I could not detect the 1,2,3 tones, but 4-0 worked fine.
2. Using some cellphones (iphone) the digits take 1-2 seconds each to be received by FS, no matter how fast the digits were typed on the phone's keypad.

I believe the isuse with #2 is somewhere in the iphone/ATT as I can call other IVR systems and sometimes get the same problem. (Etnering a 10 digit phone number will take 15 seconds to be recognized, because the digits seem to be spaced 1-2 seconds apart)

Issue #1 is the more problematic one. It occurs intermittently, and for hours at a time, and then everything goes back to normal.

Thanks for your help
-pete

------- BEGIN SCRIPT -------

function cbPIN(ses, type, data, arg)
if (type == "dtmf") then
freeswitch.consoleLog("info", "DIGIT: " .. data.digit)
local d = ses:getVariable("private_digits")
if ((d == nil) or (d == "")) then d = data.digit
else d = d .. data.digit end
ses:setVariable("private_digits", d)
if (d == "1234") then return "break" end
end
end

function inboundToHotline(isUser)
if (isUser == true) then
session:setInputCallback("cbPIN")
session:streamFile(soundDir .. "thank-you-for-calling")
--session:sleep(20000)
if (session:getVariable("private_digits") == "1234") then
session:transfer("privateMenu", "XML", "public")
else
session:hangup()
end
else
session:streamFile(soundDir .. "thank-you-for-calling")
session:hangup()
end
end



if (session:ready()) then
session:answer()
session:sleep(500)
inboundToHotline(true)
end

[brian at freeswitch.org]

This isn't anything we can do anything about... its the gsm to PSTN conversion of the digits... it'll take some time.. I have noticed this on AT&T also while dialing digits on a remove IVR such as BofA.

/b

On Apr 17, 2009, at 1:47 PM, pete@privateconnect.com (pete@privateconnect.com) wrote:

[pete at privateconnect...]

Just the usual goodies, here it is:

<context name="public">

<extension name="unloop">
<condition field="${unroll_loops}" expression="^true$"/>
<condition field="${sip_looped_call}" expression="^true$">
<action application="deflect" data="${destination_number}"/>
</condition>
</extension>
<!--
Tag anything pass thru here as an outside_call so you can make sure not
to create any routing loops based on the conditions that it came from
the outside of the switch.
-->
<extension name="outside_call" continue="true">
<condition>
<action application="set" data="outside_call=true"/>
</condition>
</extension>

<extension name="call_debug" continue="true">
<condition field="${call_debug}" expression="^true$" break="never">
<action application="info"/>
</condition>
</extension>


<!-- central inbound point -->
<extension name="incoming_call">
<condition field="destination_number" expression="^InboundCall$">
<action application="lua" data="${base_dir}/scripts/privateIn.lua"/>
</condition>
</extension>


......
</context>

[msc at freeswitch.org]

Quick question: do you do anything interesting in the dialplan prior to calling the script? For posterity's sake could you paste the extension info here as well?

Thanks,
MC

On Fri, Apr 17, 2009 at 11:47 AM, <pete@privateconnect.com (pete@privateconnect.com)> wrote: