VoIP Mailing List Archives

[klaus.teller at gmx.net]

Hi Folks,

It's me again with a DTMF issue. Here is what's going on. I have a remote IVR and i'm writing some code to communicate with it, exercise it, and test it. The remote IVR is playing DTMF as inband.

Right now, Freeswitch can detect all DTMF digits from the IVR. The interaction between my code and the IVR is essentially a combination of playing files and sending and reading DTMFs.

The issue: whenever my code plays a file or send a DTMF digit, the following attempt to read DTMF fails. By failing i mean that there will be a spurious DTMF detected by Freeswitch that was not sent by the IVR.

That is, if i have something like:

sendDTMF("3"); getDigits("38373", "#"); // # is the termination character

After executing the sendDTMF, getDigits fails because it immediately detects a pound. Yet this pound is not sent by the IVR. I can check this by having wireshark running both on the IVR's computer and on Freeswitch's computer.

Any idea what may be causing this problem? Is there some sort of Echo going on or something like that?

Thanks,
Klaus.


--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

_______________________________________________
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

[anthony.minessale at g...]

gather a console log at debug level and a trace of the event_socket traffic.


On Wed, Nov 5, 2008 at 9:08 AM, Klaus Teller <klaus.teller@gmx.net (klaus.teller@gmx.net)> wrote:

[brian at freeswitch.org]

Inband DTMF on voip isn't the most reliable thing in the first
place... anyway to use RFC2833 or SIP Info?

/b

On Nov 5, 2008, at 9:08 AM, Klaus Teller wrote:

[klaus.teller at gmx.net]

HI,

I'm attaching the console log and event-socket traffic. In the latter case, i gathered only the last few Digits (including the spurious one).

I also have the wireshark trace that i can send you off the list if you wish.

We ran the same IVR (VoiceXML App) with a platform that supports RFC2833 i didn't have this problem. With this platform we unfortunately don't have this feature available.


Klaus.

-------- Original-Nachricht --------

[anthony.minessale at g...]

is the send dtmf inband as well?
did you try doing a pause after send dtmf to give it time to deliver it?
I still don't quite get what you are saying because i don't recognize the functions in your example.

for good measure i added 2 new commands to FS

the flush_dtmf application you can execute before playing the file

and the uuid_flush_dtmf api command you can send to an arbitrary uuid
maybe try those


On Wed, Nov 5, 2008 at 9:59 AM, Klaus Teller <klaus.teller@gmx.net (klaus.teller@gmx.net)> wrote:

[brian at freeswitch.org]

Extract the RTP audio into wav/au files in wireshark and lets look at
them.

/b

On Nov 5, 2008, at 2:30 PM, Klaus Teller wrote:

[klaus.teller at gmx.net]

Hi Anthony,

Let me add some few facts.

1) I am sending DTMF using RFC2833 and the IVR is using Inband
2) The problem is not limited to when i send DTMF. It also happens when i try to play a file.
3) The functions are from my java code. They send commands to Freeswitch via socket interface.
4) The same functions are working perfectly when the remote IVR sends DTMF via RFC2833.
5) I have a pause of 2000 ms after sending the DTMF.


Let me reformulate my problem. I have a spurious dtmf-# being detected by freeswitch where nothing was sent by the other party.

The strange thing to me is that Wireschark (running on the same machine as Freeswitch) detects the proper digit sequence.

Klaus.


-------- Original-Nachricht --------

[anthony.minessale at g...]

dont forget to try what i said,
use the flush_dtmf before playback

On Wed, Nov 5, 2008 at 2:30 PM, Klaus Teller <klaus.teller@gmx.net (klaus.teller@gmx.net)> wrote:

[klaus.teller at gmx.net]

OK, we made some progress on this issue. It appears that if we introduce 50ms delay between the reading (not playing) of the DTMF and the playing of the file (or the sending of DTMF), the problem doesn't occur. And if we place many such calls this delay needs to be increased.


What i suspect is happening is that there is some sort of race condition or interference between the event processing part of Freeswitch and the handling of synchronous commands such as sending dtmf. I recall Anthony saying few days ago that event delivery is paused when a command execution request arrives. So, would it be possible that command execution requests are able to interfere on the deliverying of events?

Thanks,
Klaus.




-------- Original-Nachricht --------

[anthony.minessale at g...]

When you call send dtmf and it's rfc2833 you must sleep to give it a chance to send.
the variable last_dtmf_duration is always set on the channel with how long you should execute sleep
on the channel in the case of 2833

so call send_dtmf
execute sleep ${last_dtmf_duration}



On Wed, Nov 5, 2008 at 3:08 PM, Klaus Teller <klaus.teller@gmx.net (klaus.teller@gmx.net)> wrote:

[klaus.teller at gmx.net]

I'm updating now and will try the flush dtmf. I yet have a hard time understanding how this is related to sending DTMF (instead of reading DTMF). This because:

1) The same problem appears when i replace sending DTMF with playing an audio file
2) Introducing a delay between READING Dtmf and playing the file prevents the issue to appear.

Ideas?

Klaus.



-------- Original-Nachricht --------

[anthony.minessale at g...]

you are one email behind i think.
Problem is that FS only sends 2833 while it's busy doing something so you have to keep FS reading audio to trigger the outbound dtmf.


On Wed, Nov 5, 2008 at 3:37 PM, Klaus Teller <klaus.teller@gmx.net (klaus.teller@gmx.net)> wrote:

[jkr888 at gmail.com]

Not sure if this is related or something totally different, I used to have dtmf detection problem with inband setup. One side sending digits with send_dtmf, and on the other side, detecting the digits. Both run freeswitch with custom script, and the call go over pstn carrier network. The receiving side always having problem on detecting these dtmf, But then it solved if I played some kind of audio file after "send_dtmf" command. So, I did something like these:

<action application="send_dtmf" data="12345#"/>
<action application="playback" data="sounds/500ms.wav"/>

Weirds, but at least solved my problem





On Wed, Nov 5, 2008 at 4:46 PM, Anthony Minessale <anthony.minessale@gmail.com (anthony.minessale@gmail.com)> wrote:

[anthony.minessale at g...]

yes that's the same as my sleep explanation.


On Wed, Nov 5, 2008 at 9:11 PM, Johny Kadarisman <jkr888@gmail.com (jkr888@gmail.com)> wrote:

[klaus.teller at gmx.net]

OK. I updated and tried flushing the DTMFs before playing the commands and it works. Thanks.

Now, i feel there is a more general issue of scalability around DTMF (both inband as well as RFC2833) handling in Freeswitch. What do you guys think?

What i've been working on is a tool for testing voice applications. The tool connects via Freeswitch to the voice platform and simulates the behavior of the user. We've tried the tool with the most reliable voice platforms out there as well as with some less reliable.

What we observe is that in all cases, we can run 100 calls sequentially without problem. But as soon as we have 10 calls in parallel, digits start to get lost. Is this something you think should be expected?

I must note that there are a lot of DTMF reading and sending going on. In fact, the testing tool doesn't use voice recognition to assert whether the voice application is in the right state or not. Instead, we instrument the voice application to emit some DTMF sequences that are uniquely mapped to prompts. So there DTMF sequences are read by the testing tool to determine if the voice app is in the right state or not.

Looking forward to your feedback.

Klaus.







-------- Original-Nachricht --------