| Author |
|
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 13 2008 at 9:35am | IP Logged
|
|
|
Aj,
Forgot to mention one other item.
With the new product image, you can continue to use all your existing code. You do not have to change your VOIP app over to using the integrated DTMF capability right away.
Your current in-band DTMF decoder blocks you are using in the media engine will all support the new capability.
Support
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 13 2008 at 7:02pm | IP Logged
|
|
|
Hi Aj,
Thanks for waiting for this post.
Your support FTP account has been updated with an engineering product image. See the “v5.12.8.2 DLL Only” directory. The image is good until end of June. Make sure to look at the release notes.
Your VOIP apps should be able to use the updated in-band DTMF detection “out of the box” with no tweaking.
If you do have to tweak any DTMF settings to obtain detection, there are only two APIs you should need:
Code:
BOOL VOIP_API DtmfDecoderSetSignalThreshold(
HDTMFDECODER hDtmfDecoder,
double DtmfDecoderSignalThresholdDb
);
void VOIP_API DtmfDecoderSetMinimumDigitOnTime(
HDTMFDECODER hDtmfDecoder,
DWORD MinimumDigitOnTimeMs
);
|
|
|
In case you cannot detect in-band DTMF using the media engine’s DTMF decoder default settings, call the DtmfDecoderSetSignalThreshold() API proc for the decoder in question with a value of negative 36db or less. Continue to lower the db value until you get detection. Once you get detection, Look at the magnitude values in your DTMF detection data that gets passed to your decoder callback proc. Finally set a DTMF detection power level that is between the lowest DTMF frequency power and the average noise power. You shouldn’t have to do this but we want you to be armed with this info in case you do.
If you find that your app is getting too many false DTMF digit detections, simply call the DtmfDecoderSetMinimumDigitOnTime() proc with a value 40Ms or higer. The larger values you pass to this proc, the more noise immunity you get which reduces false positives.
We will probably update the Developer’s Reference tomorrow (hopefully) and then you can start thinking about using the cool fully integrated in-band and RFC2833 DTMF detection the media engine now supports.
Note:
The Developer’s Reference that comes with this release has not been updated to contain information on the new DTMF capability.
Support
|
| Back to Top |
|
| |
ajdiaz
Junior
Joined: December 10 2007
Location: United States
Posts: 76
|
| Posted: March 14 2008 at 3:44pm | IP Logged
|
|
|
Hi Support,
Preliminary tests indicate that this version is detecting the in-band DTMF inputs “out of the box” with no tweaking for us. We will perform more thorough testing shortly.
To use RFC2833 DTMF I will need some guidance. Maybe you can post here instructions on how to use it.
Thanks again for all your help.
-Alex
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 14 2008 at 4:15pm | IP Logged
|
|
|
Hi Alex,
That’s good news. We will be getting the dev reference updated as soon as possible. When we do, we will get you the updated copy.
Using the new natively supported in-band and RFC2833 DTMF decoding and generation will be simple for you. We will post the basics on Monday. You should really enjoy working with it. All you do is set it up and wait for the media engine to send DTMF digit events to your app. Way simpler that using the previous DTMF generator/decoder function blocks in addition to having the hassle of logically wiring it all together in your app.
See you Monday….
Support
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 18 2008 at 1:14pm | IP Logged
|
|
|
Alex,
We updated your support FTP account with a Developer’s Reference (v5.12.155) that has additional information about the fully integrated in-band and RFC2833 DTMF the media engine now supports (from the upcoming v6 product release).
If you reference the section:
The Telephony API
DTMF Generation and Detection
Fully Integrated In-Band and RFC2833 DTMF
You will have additional information you can use to start using RFC2833 DTMF. Post with any further questions, bugs or issues.
Using the RFC2833 DTMF is very simple. You should have no problems using it. I bet you guys have it up and running within an hour or so….
Thanks,
Support
|
| Back to Top |
|
| |
ajdiaz
Junior
Joined: December 10 2007
Location: United States
Posts: 76
|
| Posted: March 19 2008 at 3:03pm | IP Logged
|
|
|
Hi Support,
Thanks for your vote of confidence. We modified our code and it seems to be working great! Thanks.
One question, just to be sure. Once using RFC2833, it seems that there is no need to call CreateDtmfDecoder(), or call OpenRxIvrChannel(), is that true?
We seem to be able to handle RFC2833 DTMF and record voice data without ever calling OpenRxIvrChannel. For what other purposes would OpenRxIvrChannel be needed?
Thanks,
-Alex
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 19 2008 at 3:44pm | IP Logged
|
|
|
Hi Alex,
You >>>
One question, just to be sure. Once using RFC2833, it seems that there is no need to call CreateDtmfDecoder(), or call OpenRxIvrChannel(), is that true?
<<< Support
Yup - you are exactly correct. Once you start using the fully integrated DTMF capability in the media engine, there is no need to call those API procedures anymore.
You >>>
We seem to be able to handle RFC2833 DTMF and record voice data without ever calling OpenRxIvrChannel. For what other purposes would OpenRxIvrChannel be needed?
<<< Support
The full-duplex voice recording for the phone lines is handled internally by completely separate logic... and like you said, you are now handling in-band and/or RFC2833 DTMF with no problems (another completely isolated internal sub-system of the media engine).
The receive IVR channels of the phone lines exist in case the voip app has to do any auxiliary processing of the received media data being received by any of the phone lines. All the receive IVR channels can be used however the app wants. Voice (speech) recognition is a good example of this. We have other customers who are basically designing IVR server platforms that are voice interactive. This means that you can talk into the phone and speak your way through the IVR menus instead of using DTMF to navigate. It’s pretty cool.
Support
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: Issues After Upgrading to DLL v5.12.8.1
