LanScape Support Forum: Issues After Upgrading to DLL v5.12.8.1

		Active Topics Member List Search Help Register Login

LanScape VOIP Media Engine™ - Technical Support
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support

Topic: Issues After Upgrading to DLL v5.12.8.1

Author

Message

<< Prev Topic | Next Topic >>

ajdiaz
Junior
Junior

Joined: December 10 2007
Location: United States
Posts: 76

Posted: February 28 2008 at 6:10pm \| IP Logged

The issue with the application hanging after calling MediaEngine.GoOffHook() has been resolved after moving this method call outside the main application thread where MediaEngineCallbackProc also resides.

The problem now is that no DTMF is detected. The same exact code used with DLL v5.12.4.7 works; we switch to DLL v5.12.8.1 and it does not work. The application is not hanging, the problem is that the DtmfCallbackProc registered is not being triggered at all.

I do not suspect any thread locking issue with this scenario. Any ideas?

support
Administrator

Joined: January 26 2005
Location: United States
Posts: 1666

Posted: February 28 2008 at 6:53pm \| IP Logged

Hi Alex,

Hmmm… that is strange. We do not have any other reports regarding broken in-band DTMF. We will check it our right away tomorrow morning.

By the way: You post good info. It is good to know that v5.12.4.7 worked. I wonder if something has been broken between releases.

We will check…

Support

support
Administrator

Joined: January 26 2005
Location: United States
Posts: 1666

Posted: February 29 2008 at 6:45am \| IP Logged

Alex,

We are looking into the in-band DTMF detect issue you reported right now using v5.12.8.1. Will post back when we have further details.

Support

support
Administrator

Joined: January 26 2005
Location: United States
Posts: 1666

Posted: March 03 2008 at 8:32am \| IP Logged

Hi Alex,

We looked into the in-band DTMF decoder support in the latest media engine and it has not changed since your initial revision of the product.

That being said, if you are not able to detect in-band DTMF using v5.12.8.1 of the media engine, something is definitely going on that we cannot see just by looking at our source code for the media engine product.

The in-band DTMF decoder blocks in the media engine have worked well for many-many application deployments over the past few years. We have on occasion had to supply customers with updated DTMF decoder tuning table information in order to handle some esoteric oddities that we have come across.

The three primary factors that can kill good DTMF detection are input signal to noise ratio (i.e. how clean is the DTMF channel), input power level (amplitude of the DTMF signals) and variations in DTMF twist.

The in-band DTMF decoders in the media engine have AGC (automatic gain control) at their inputs, so item two from the above statement probably is not causing the problem.

We need to see your DTMF input signals:
We would like for your group to perform a small test for us. The result of this test will be a 8K PCM wave file we can use to look at the DTMF signals that are coming into your IVR server application.

Modify your server app so that call recording is active on phone line 0. See the StartPhoneLineRecording() API procedure.

Start your IVR server application.

Do whatever you normally do to make your server app have a call connected on phone line 0.

From your PSTN cell or land-line phone, press all the DTMF digits on the keypad (0-9,#,*). Hold down the DTMF keys on the phone for 1 second or more.

Terminate the call.

Exit out of your IVR application.

Playback the generated wave file that was recorded for phone line 0. Make sure all the tones (12 of them) are in the recorded wave file.

Upload the recorded wave file to your support FTP account and we will look at its contents. The signals present in the recorded wave file should give us an indication as to the problem we are facing.

Post back to this thread when you have uploaded the recorded wave file.

Question:
Is it possible for your deployment to use RFC2833 DTMF?

Support

ajdiaz
Junior
Junior

Joined: December 10 2007
Location: United States
Posts: 76

Posted: March 03 2008 at 9:25pm \| IP Logged

I do not see a problem using RFC2833 DTMF. I'm not sure how to switch, but if it is better and also solves our problem, we are OK willing to give it a try with your directions.

BTW, the WAV file was sent via email since we do not have FTP permission to upload a file.

Thanks.

support
Administrator

Joined: January 26 2005
Location: United States
Posts: 1666

Posted: March 04 2008 at 9:03am \| IP Logged

Alex,

If you can use RFC2833 DTMF, that would be much better. RFC2833 DTMF is "rock solid" compared to in-band DTMF detection.

Getting the media engine to handle this will be no problem. We will make sure you get it working properly.

What we need to know is:

Regarding PSTN termination: How are you connecting your VOIP Media Engine IVR server application to the PSTN? Are you terminating yourself using your own PBX or PSTN gateway device?

Does your PSTN termination support RFC2833 DTMF RTP payloads?

If your PSTN termination supports RFC2833 DTMF RTP payloads, then we will definitely want to use that instead of in-band DTMF detection. It will be more accurate and lead to less problems down the road.

In the mean time, we will take a look at the DTMF in-band wave file you sent. It’s generally something simple that causes the in-band DTMF detection problems.

Support

support
Administrator

Joined: January 26 2005
Location: United States
Posts: 1666

Posted: March 04 2008 at 10:46am \| IP Logged

Alex,

Update:
From your in-band DTMF waveforms, it looks like there is a signal to noise (S/N) issue. The DTMF detection of the media engine is being too picky regarding the DTMF signals it is receiving. This is explaining why in-band DTMF detection is failing at the moment.

In-band DTMF frequency tolerance and twist all look good.

We still need to look at a few other things.

Question:
Are you using a lossless codec like uLaw or aLaw when making these VOIP phone calls?

Support

ajdiaz
Junior
Junior

Joined: December 10 2007
Location: United States
Posts: 76

Posted: March 04 2008 at 11:03am \| IP Logged

No uLaw. We use PCM.

We use for Start Params:

StartParams.AudioRecordBandWidth = VoipMediaEngine.AUDIO_BANDWIDTH.AUDIO_BW_PCM_8K;

StartParams.AudioPlaybackBandWidth = VoipMediaEngine.AUDIO_BANDWIDTH.AUDIO_BW_PCM_8K;

And we call for every line:

Code:

status = DtmfDecoder0.CreateDtmfDecoder(

   MediaEngine,

   true, // use PCM samples.

   8000, // sample rate.

   160,      // number of samples per input block.

   160,      // filter block N size. generally set to the 

         // same as the num samples per block.

   true      // was false, immediate mode.

   DtmfDecoderCallbackProc,     // handler proc.

   myDataObj  // handler proc instance data.

);

status = RxIvrChannel0.OpenRxIvrChannel(

   MediaEngine,

   PhoneLine,

   IvrCallbackProc0,

   myDataObj, //My Custom object,

   true,      // Perform conversion.

   VoipMediaEngine.AUDIO_BANDWIDTH.AUDIO_BW_PCM_8K,

   ref RxIvrSamplesPerIvrBuffer0,

   ref RxIvrBytesPerIvrBuffer0,

   ref SamplesInByteArray0

);

support
Administrator

Joined: January 26 2005
Location: United States
Posts: 1666

Posted: March 04 2008 at 1:10pm \| IP Logged

Alex,

OK, good. What that tells us is that you are asking the media engine for 8khz PCM sample blocks from phone lines so you can feed the sample blocks to in-band DTMF decoders. That part is OK. Unfortunately it does not answer the question we asked.

When the media engine is in a call, it exchanges media data (voice) with the far end of the call using a negotiated codec (uLaw, aLaw, G729, iLBC etc). What codec type are you using for the calls? This is important.

The media engine will rate/format convert from the phone line media rate/format to the 8k PCM Rx IRV rate/format you requested. In-band DTMF will not work if your calls are using “lossy” type codecs like iLBC or G729 even though you are getting 8k PCM from the Rx IVR channels.

Support

ajdiaz
Junior
Junior

Joined: December 10 2007
Location: United States
Posts: 76

Posted: March 04 2008 at 1:40pm \| IP Logged

With our provider, we are using G711.

ajdiaz
Junior
Junior

Joined: December 10 2007
Location: United States
Posts: 76

Posted: March 05 2008 at 10:40am \| IP Logged

Hi Support,

I need to apologize. I failed to inform you that the wave file I sent you was recorded using DLL v5.12.4.7. If we use this version, the tones can be heard clearly.

I just uploaded a wave file recorded using v5.12.8.1, and you will clearly listen to the difference. The file is called "All Keys Dtmf recorded by Simplikate Using DLL v5.12.8.1.wav". Both files were recorded using the same exact application, same exact code. We only switched your ME DLLs.

In this new wave file you can easily see that the DTMF tones are of bad quality.

Hope this helps. Sorry again about the confusion.

-AJDiaz

support
Administrator

Joined: January 26 2005
Location: United States
Posts: 1666

Posted: March 05 2008 at 10:54am \| IP Logged

Alex,

Thanks for the update. We will look at the new file.

In the mean time, try to verify that your PSTN termination (gateway) supports RFC2833 out-of-band DTMF signaling in RTP payloads. If you need help figuring out how to do this, post again to this thread and we will elaborate.

If we can use RFC2833 DTMf for your deployment, it will work much better, take less CPU cycles per phone line and not be affected by in-band signal processing “gotch-yas”.

Support

ajdiaz
Junior
Junior

Joined: December 10 2007
Location: United States
Posts: 76

Posted: March 05 2008 at 10:58am \| IP Logged

Support,

Our provider is telling us that yes, they support RFC2833.

How would we go about making the change, or better yet perform a quick test?

Thanks,

-AJDiaz

support
Administrator

Joined: January 26 2005
Location: United States
Posts: 1666

Posted: March 05 2008 at 11:45am \| IP Logged

Alex,

The last wave file you uploaded contained complete garbage. There is no DTMF in-band signal content in the waveform at all. How can this be??? Hmmm…..

Not that we want to beat a “dead horse”, but we would like for you to quickly run a test using an undocumented API procedure:

Code:

TELEPHONY_RETURN_VALUE VOIP_API SetPhoneLineReceiveRecordState(

          SIPHANDLE hStateMachine,

          int PhoneLine,

          char *pWaveFileName,

          BOOL Enable

          );

Using the above proc, you can tell the media engine to record all received phone line media data to a wave file. This will bypass all other processing in the RTP receivers for the phone line. What gets recorded to a wave file is PCM data immediately after the initial format/rate conversion from phone line media format/rate to internal PCM format/rate. No other processing of the RTP media is performed.

When you perform this latest call test, make sure you use G711 aLaw or uLaw for the codec.

Hmm… something is not right….

Support

Notes:

This post discusses VOIP Media Engine undocumented API procedures that are used for internal test purposes. Do not use these API procedures in your VOIP applications.

support
Administrator

Joined: January 26 2005
Location: United States
Posts: 1666

Posted: March 05 2008 at 11:51am \| IP Logged

Alex,

To process RFC2833 DTMF for a call using v5.12.8.1 media engine, you have to use the raw RTP receiver callback. See the following post:

Processing RFC2833 DTMF using v5 Media Engines:
http://www.lanscapecorp.com/forum/forum_posts.asp?TID=421&KW =2833

There is code in the above post for a callback proc you can use. You will have to port it over to C# but it has all the logic you will need. If you want us to create the C# version of this callback, just say the word and we will get it to you.

If you prefer a sample app containing all the logic, we will do that too. Let us know what you want. We will log it under March support.

Support

support
Administrator

Joined: January 26 2005
Location: United States
Posts: 1666

Posted: March 05 2008 at 12:33pm \| IP Logged

Hi Alex,

We just mounted the 512 line media engine for your group to download. If there are any problems or questions, just post as usual.

Support

Jalal
Vetran
Vetran

Joined: April 24 2006
Location: Iran
Posts: 188

Posted: March 06 2008 at 12:44am \| IP Logged

Hi Alex,

Why don't you use wireshark to capture all received RTP packets at your end ? You can then extract the wave file for received audio using this cool software and compare your recorded wav file using Media Engine and wireshark.

Note: wireshark is a free packet capture and network protocol analyzer software available at http://www.wireshark.org/download.html .

Regards,
Jalal

support
Administrator

Joined: January 26 2005
Location: United States
Posts: 1666

Posted: March 06 2008 at 7:34am \| IP Logged

Yup, wireshark is great. :)

ajdiaz
Junior
Junior

Joined: December 10 2007
Location: United States
Posts: 76

Posted: March 06 2008 at 11:47am \| IP Logged

Thanks support.

We are so busy moving forward with development, we switch to the working version of the DLL (v5.12.4.7). We will try your suggestions early next week.

A quick try of the 512 license failed. Switching the .lic file and then adding the distribution code gives us CallSipFailure after calling StartSipTelephony().

Is there anything else to do?

Thanks.

-Alex

support
Administrator

Joined: January 26 2005
Location: United States
Posts: 1666

Posted: March 06 2008 at 12:42pm \| IP Logged

Alex,

We just performed the following test:

Installed your 512 line media engine to a fresh machine. Win XP Pro.

Copied the LanScapeVME.c license file from the media engine distro image to the C:\Program Files\LanScape\VOIP Media Engine\5.12\Software Examples\Microcode directory.

Modified the PhoneBase.cpp module in the software examples and added a NULL terminated redistribution string from your licensing info.

Passed the redistribution code to the init proc like this: InitializeMediaEngine(pRedistCode,0);

Rebuilt the release build image of the single line soft phone sample.

Ran the soft phone on the Development box – no problems.

Ran the soft phone app on a completely different machine not having the media engine installed – no problems.

You may have to check your setup again. Make sure to use the v5.12.8.1 DLL image and your new redistribution code together. Do not mix redistribution codes with previous versions of media engines.

Support

ajdiaz
Junior
Junior

Joined: December 10 2007
Location: United States
Posts: 76

Posted: March 06 2008 at 1:39pm \| IP Logged

Yes, the 512 license only works with DLL v5.12.8.1. Unfortunately, that is the version that is not working for us. We are in a catch-22 now.

I will try the RFC2833 early next week.

Thanks.

-AJD

ajdiaz
Junior
Junior

Joined: December 10 2007
Location: United States
Posts: 76

Posted: March 11 2008 at 11:14am \| IP Logged

Hi Support,

I wanted to try your suggestion about calling SetPhoneLineReceiveRecordState() to record Dtmf inside another wav file with minimal processing of the RTP media.

But this method does not exists in the DLLs provided. Not in the LMEVoipManaged library. Not in v5.12.4.7 or in v5.12.8.1.

-Alex

support
Administrator

Joined: January 26 2005
Location: United States
Posts: 1666

Posted: March 11 2008 at 12:04pm \| IP Logged

Hi Alex,

Our mistake. We forgot you are using C#.

The native media engine DLL exports the API proc but the managed code wrapper does not support it. You can see the exported proc in the native DLL by using tools such as “Dependancy Walker”.

You can still call the SetPhoneLineReceiveRecordState() proc if you want to create a .NET “inter-op” signature for the native procedure and then call it that way. We will make note of adding these undocumented procs to the managed code wrapper.

Also: We know why your in-band DTMF detection failed using v5.12.8.1. The noise power of the DTMF measured in your original “All Keys Dtmf recorded by Simplikate.wav” file is just exceeding what is specified in the default DTMF decoder tuning tables.

We have two options if we want to continue using “in-band” DTMF detection:

1)
Get you an updated set of default DTMF tuning tables. This is not as flexible and as good as option 2 below.

2)
Get you an updated media engine version that will allow you to control DTMF detection signal thresholds, noise thresholds and other valuable settings. We will be offering this capability in the media engine API anyway moving forward. This way end users will be able to handle in-band DTMF detection situations that may be out of the DEFAULT norm.

The 3rd and best option is to use out-of-band RFC2833 DTMF detection. Then all the signal processing issues go away forever. Let us know when you need help with this.

Support

ajdiaz
Junior
Junior

Joined: December 10 2007
Location: United States
Posts: 76

Posted: March 11 2008 at 1:48pm \| IP Logged

Got it. Thanks.

1) Yes, please send us an updated set of default DTMF tuning tables. We eventually want to use RFC2833, but because we have too many unknowns at this time, we wish to make in-band work again if by simply setting new tuning tables - we need to get through the day.

2) Sounds like implementing these capabilities in the media engine API moving forward is a good idea. Doubt we can wait though.

Thanks again.

support
Administrator

Joined: January 26 2005
Location: United States
Posts: 1666

Posted: March 13 2008 at 9:31am \| IP Logged

Hi Aj,

This is a bit of a long post so I hope you had your morning coffee…

We started to code up the RFC2833 example app in C# and started thinking: Why the hell are we wasting time doing this? We need to “cut to the chase”.

We really do not want you to go down the route of having to handle all the details of in-band and RFC2833 DTMF in your application. It can certainly be done but there is no need to have you do it that way at this time. Considering the alternative we can offer you, it’s just too messy. Yuk.

What we want to do is get you a pre-released version of the media engine that does all of this for you. We are talking about the upcoming v6 product release. Don’t worry – its stable. As far as bugs, there could be a few teething pains but no show stoppers.

Except for a few minor details we must send through engineering QA, our goal is to get you this temp product image before the day is over. At the very latest tomorrow.

It really comes down to being sensible. A little patience now will make all of our development and support tasks easier. We will then commit to getting you a free final product image when v6 of the media engine is released to the street.

OK, Now for some other info:

Updating your existing DTMF tuning tables:
The noise in your DTMF signal is pretty high. So high in fact that it is causing detection failures in our software. Hmm… not good.

Normally in-band DTMF detection support in the media engine works well when using DTMF sourced from PSTN terminations (i.e. DTMF from the phone company) or received digitally via the network from other devices (soft phone, etc).

We re-tuned the DTMF detection to you recorded signals and were not happy with the results. It would work but it was not good enough. We would have had problems down the road. Another thing is the AGC (automatic gain control) that is internally applied prior to DTMF decoder operations made matters worse. It really boils down to a signal to noise issue.

The solution:
The media engine has been updated to allow the VOIP app to use standard DTMF decoder tuning with additional control. Instead of giving the VOIP app a fixed “all or nothing” DTMF decoder capability (based on DTMF decoder characteristics we determine here), we now allow the app the ability to change critical DTMF detection settings if required. Here are the new APIs:

SetDtmfSignalThreshold()
GetDtmfSignalThreshold()

Allows an app to control the signal strength associated with DTMF decoding. Signal strength is specified in db (decibels). The 0db reference is equal to full scale 16 bit PCM.

SetDtmfTwist()
GetDtmfTwist()

Allows the app to control and tailor acceptable DTMF decoder signal twist.

SetMinimumDigitOnTime()
GetMinimumDigitOnTime()

Allows the app to control the minimum digit ON time required before the media engine will notify the app of the DTMF ON event. Setting higher values from the default (40Ms) also improves talk off and noise immunity.

Using this updated DTMF decoder capability in its default state, we had no problems detecting the DTMF signal you recorded and sent to us.

Test scenarios (using new default decoder settings):
We played your DTMF signals through the decoders direct from disk (all digital).

Then we used a microphone on another PC running one of our soft phones to record capture your DTMF signals being played back. The recorded signals were sent to another media engine based IVR app for in-band tone decoding.

We then used a “super crappy” headset microphone we have here to capture DTMF signals from a hand-held lineman’s DTMF generator (it’s a portable DTMF generator with an acoustic coupler – Interface Technologies Model #720).

All the above tests passed.

How the new integrated in-band and RFC2833 DTMF works in the media engine:

There are a few additional startup parameters. These allow the media engine to create needed resources when it boots.

After the media engine starts, in-band and/or RFC2833 DTMF decoding can be enabled on a per phone line basis. Either DTMF detection can also be disabled or shut off anytime after boot on a per phone line basis.

There are basically two new APIs that the VOIP app calls to initialize in-band and/or RFC2833 DTMF for the phone lines. That’s all you have to do.

Once enabled, the media engine handles everything else. When incoming DTMF is detected on any phone line, the VOIP app gets an “immediate” event.

The “immediate” event has DTMF detection data associated with it such as the DTMF digit that is changing, the ON/OFF state of the digit, etc. Also, if the DTMF digit was in-band, the app also gets the power levels of: DTMF frequency 1, DTMF frequency 2 and the average signal noise in db at the time of detection.

So now, if an app is having any trouble detecting in-band DTMF, all it has to do is lower the DTMF detect signal threshold using the SetDtmfSignalThreshold() API until it starts getting proper digit decoding.

To obtain optimal in-band DTMF detection:
Once detection is obtained, the app can then look at the power levels of DTMF 1 and 2 frequencies and the power level of the average noise. It can then set the detect threshold as the mean point between signal power and average noise power.

Generally the default settings for the updated DTMF decoder should work OK.

Current defaults:
Default Signal threshold: -36bd
Default forward twist: 8db
Default reverse twist: 4db
Minimum digit ON time: 40Ms

We will repost when we have the new product image ready for FTP download.

Repost with any concerns or details.

Thanks,

Support

Page of 2 Next >>

Printable version

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum