| Author |
|
prism
Intermediate
Joined: May 15 2009
Location: United States
Posts: 8
|
| Posted: August 12 2009 at 3:54pm | IP Logged
|
|
|
Integrated In-Band DTMF decode problem:
The DTMF decoder appears to have a problem decoding consecutive digits of the same value. The DTMF string “12345” decodes properly as 12345, but “10005” decodes as 105.
The string “12345” decodes properly with a tone on-time of 50ms and an inter-digit time of 50ms. The string “10005” does not decode properly until the inter-digit time is increased to about 400ms. There also appears to be some interaction between the on and off time. 100ms on/400ms off decodes reliably, but 50 on/400 off is marginal.
Our decode parameters for the tests were:
Threshold -> -35dbm
Min on time -> 40ms
Fifo length -> 30
Dialer DTMF amplitude: -18dbm
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: August 13 2009 at 2:31pm | IP Logged
|
|
|
Hello prism,
The quickest way for us to see exactly what is going on with your in-band DTMF detection is to get a WireShark network trace of your phone calls that have trouble decoding the in-band DTMF signals. You can download WireShark here:
http://www.wireshark.org/
Install WireShark and start it so that it can perform promiscuous network traffic sniffing using your host machine’s installed network hardware.
Then have your app connect to your other VOIP call endpoint (either have your app initiate a call or answer an incoming call) and generate the failing in-band DTMF digits detection like “10005”.
Terminate the call and your WireShark sniffing and upload your WireShark capture file to your support FTP account and we will take a look to see what default DTMF parameters need to be adjusted. Note: Support FTP account access has been secured. Please read the following web page to understand how to securely connect to your support FTP account:
Secure access to customer support FTP accounts:
http://www.lanscapecorp.com/support/SecureFtpAccess/FtpAcces sInstructions.asp
There are a number of factors that impact in-band DTMF detection. If at all possible, try to use the RFC2833 DTMF support of the media engine. If that is not possible, then we will have to help you find the in-band DTMF values that will give you the best possible detection performance/accuracy. Depending on the DTMF signal source, signal noise, twist, etc, our goal is to get you the most accurate in-band DTMF detection possible using your DTMF signal characteristics.
IMPORTANT:
You must use either uLaw or aLaw (G7.11) codecs for the calls. This is important because these two media formats will preserve the signal content of the audio path for the calls. Using some other call media codec will not work with in-band DTMF detection.
Randal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: August 25 2009 at 1:05pm | IP Logged
|
|
|
Hello Jim,
Any further information regarding this post? We are hoping that we can receive a network trace of the RTP media packets for your calls that are seemingly having in-band DTMF detection issues.
We are standing by waiting to assist…
Thanks Jim,
Randal
|
| Back to Top |
|
| |
prism
Intermediate
Joined: May 15 2009
Location: United States
Posts: 8
|
| Posted: September 03 2009 at 2:18pm | IP Logged
|
|
|
Hello Randal,
We were both out of town for the past few weeks on business and vacation so we have not been able to run the test.
We will get a Wireshark capture this weekend as suggested. Hopefully that will help.
As a note, during our tests we varied all of the DTMF decode parameters and tested using the X-Lite softphone as well as commerical signaling over a T1 input and an alternate T1 with a Quintum Tenor DX Gateway.
All resulted is the same exact results as described earlier.
Thanks for your support.
Jim
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: September 03 2009 at 2:34pm | IP Logged
|
|
|
Hello Jim,
Thanks for the update. We will get to the solution. Looking forward to the WireShark capture data.
Randal
|
| Back to Top |
|
| |
prism
Intermediate
Joined: May 15 2009
Location: United States
Posts: 8
|
| Posted: September 06 2009 at 10:57am | IP Logged
|
|
|
Hi Randal,
I have uploaded a .pcap Wireshark capture file as you requested. Hopefully it helps you find the issue we are experiencing.
In the test we captured a complete call with the following details:
a. From our T1 call generator connected to a Quintum Tenor DX Gateway (converts T1 to SIP), we placed a call sending a 7 digit telephone number of 2240000.
b. Our application answers the call, validates the number in our database, and sends back an audible prompt indicating the caller should enter DTMF message digits.
c. Our call generator then sends the telephone number followed by a * followed by a unique 6 digit sequence number as the message.
d. Here is an example of the call:
Dial 2240000
Wait for answer and prompt
Dial: 2240000*200015 as message
Wait 3 seconds and disconnect.
e. Our display and log file show we only received: 2400*2015.
f. We used timing parameters of 100ms on/off for our dtmf dialer.
g. We set the minimum on time to 40ms, the sensitivity to -30 dB, and fifo depth to 30 in our application.
Our testing shows we do not reliably decode consecutive identical digits. It misses the 2nd and often the 3rd digit if identical.
We have the same results using an X-Lite softphone and a Polycom 501 VoIP phone.
Jim
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: September 08 2009 at 3:09pm | IP Logged
|
|
|
Hi Jim,
I will look into the capture file you uploaded. Will repost when I have new information.
Randal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: September 10 2009 at 3:22pm | IP Logged
|
|
|
Hi Jim,
I have additional work to do regarding analyzing your in-band DTMF issue. However, I wanted to pass along to you some preliminary info.
The in-band signal content of your test call as per the Wireshark capture is interesting.
I see the DTMF signal content in your media stream for the call and I also see the DTMF (the message) being received by the media engine for the 14 DTMF digit stream of 2240000*200015.
All of the DTMF signal content is nicely 100Ms in duration with 100Ms dead time between digits. This is good and is not a problem.
Here is the strange thing:
1)
The first DTMF 100Ms signal received contains pure tones for the digit 2 (697Hz and 1336Hz) which is good.
2)
Then there is 100Ms of inter-digit silence. Also good.
3)
The second 100Ms signal starts out with DTMF digit 2 tones and then by 30 to 40Ms also contains DTMF tones for DTMF digit 4 until the end of the 100Ms duration. In other words, the gateway is sending in-band DTMF signal content for both DTMF digit 2 and 4 in the same 100Ms signal burst. This is bad.
Why would this be?
Is there some sort of configuration setting on the gateway that will allow the gateway to send only a single DTMF digit in any 100MS signal burst?
It appears the media engine is right on the 40Ms in-band DTMF detect margin.
Possible options at this point:
1)
I looked at the specifications of the Quintum Tenor DX Gateways and it look like they support RFC2833 DTMF signaling. I would use this form on DTMF signaling instead. Much more robust in my opinion and generally “rock solid” as far as the media engine’s DTMF detection logic is concerned. Using this approach removes all the signal processing logic the media engine uses for the in-band detection you are currently attempting.
2)
Get the gateway to only send pure 100Ms single DTMF digit bursts.
3)
Call the SetInBandMinimumDigitOnTime() API procedure in your VOIP application code and set the minimum DTMF digit detection ON time to 20Ms. We normally run our apps using 40 to 60Ms but 20Ms may still work for you in this case.
I still have to extract your RTP raw packets from your capture file and pump them into the media engine and perform additional testing.
Please repost as I would like to receive your thoughts,
Randal
|
| Back to Top |
|
| |
prism
Intermediate
Joined: May 15 2009
Location: United States
Posts: 8
|
| Posted: September 11 2009 at 5:56pm | IP Logged
|
|
|
Hi Randal,
Per your recommendations we now have the Quintum Tenor and the SIP Media Engine running using RFC2833. We are still testing but so far the results look very good. The calls from the X-Lite softphone and Polycom 501 are now solid as well.
We are happy for you to wait until our tests are more complete before spending any more time on this. I will post new results after a full weekend of testing.
We are load testing the 4 line version with as much traffic as it can handle and still using 100 on / 100 off. On a second system we are experimenting with different timing to find the boundaries and are very impressed with the performance. With good results from these tests I plan to move us up to the 64 line version next week.
Thank you for the quick detailed analysis and advice on correcting the configuration.
Regards,
Jim
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: September 14 2009 at 12:01pm | IP Logged
|
|
|
Hi Jim,
OK, good feedback... very good.
Randal
|
| Back to Top |
|
| |
prism
Intermediate
Joined: May 15 2009
Location: United States
Posts: 8
|
| Posted: September 15 2009 at 10:39am | IP Logged
|
|
|
Hi Randal,
Testing over the weekend went very well. No more issues so we are ready to move up to the 64 line version. I will do that today.
Thanks for the great support.
Jim
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: September 15 2009 at 11:34am | IP Logged
|
|
|
Thank you Jim.
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: DTMF decode problem
