| Author |
|
ajdiaz
Junior
Joined: December 10 2007
Location: United States
Posts: 76
|
| Posted: May 27 2009 at 7:31pm | IP Logged
|
|
|
Hi Support,
We have a VOIP application that records a wave file and plays it back. The application first plays a wave beep, the user starts recording their message and when done hits the # key.
The issue we have is that the sound of the # key gets recorded inside the wave file. By the time we detect the # as DTMF and call StopRecording() the wave file contains the sound of the pound.
The big issue is that this wave file with the # sound was sent to a voicemail and the voicemail system interpreted the # sound as a key stroke and ended their recording before we were doing playing all the wave files we needed to play.
How can we stop the Media Engine from recording the # sound inside the wave file generated by LME StartRecording()?
Thanks.
AJDiaz
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: May 28 2009 at 12:18pm | IP Logged
|
|
|
Hi Aj,
Thanks for waiting for this response. We are playing catch-up due to last weekend’s holiday.
Very interesting…
One way to stop this behavior is to only allow incoming calls to send to the media engine RFC2833 DTMF payload packets with non-interlaced DTMF audio. In other words, all SIP clients should be configured to only send pure RFC2833 DTMF payloads to the media engine when using DTMF. In this case, no audible DTMF tones will be recorded to your audio wave files.
If the above is not possible, there are a number of options that may exist.
1) Delayed Recording – internal to the media engine:
We could update the media engine to perform delayed call recording. We would probably add an additional parameter to the StartPhoneLineRecording() API procedure. A VOIP application could then specify a delay time that would be used when recording is active. For example, your app could specify 500Ms delay. This would allow your app to detect the DTMF digit and then call the StopPhoneLineRecording() API procedure. This would in effect place your application DTMF detect logic “ahead” of the actual phone line record audio – thus terminating recording before the audible in-band DTMF is written to the wave file.
2) Delayed Recording – inside your VOIP app:
In this case, you would have to stop using the StartPhoneLineRecording() and StopPhoneLineRecording() API procedures and record the received audio using the Rx IVR channel of each phone line. A bit “clunky” but will allow you to implement your own record delay logic. The end result would be the same as the above solution that we would implement natively.
3) Post processing of wave file audio:
In this scenario, your app could post process the recorded wave file using FFT or some other signal processing scheme to remove the recorded DTMF tone. We can discuss this in more detail if required.
If you want, see if you can obtain a WireShark network capture of a typical call that your system handles. I would like to see the RTP stream for the call. Upload the WireShark trace file to your support FTP account if you can.
Randal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: June 02 2009 at 9:50pm | IP Logged
|
|
|
Hi Aj,
Any further info regarding this issue?
Best,
Randal
|
| Back to Top |
|
| |
ajdiaz
Junior
Joined: December 10 2007
Location: United States
Posts: 76
|
| Posted: June 03 2009 at 1:01pm | IP Logged
|
|
|
Hi Support,
Thanks for the follow up. Yes, we are still having the issue.
We were looking to see if there is a lot of code between capturing the DTMF and stopping the recording, but there is not code much code between one method and the other.
The idea of having an additional argument to delay start/stop recording in the LME API, I believe would accomplish our goal. We could play with the delay until we see which setting works best for us, and if on a particular recording we do not need a delay, then we won't use it. Wouldn't you agree?
If you cannot think of any other suggestion, what would be the next step to make this happen?
Thanks,
-AJD
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: June 04 2009 at 10:13am | IP Logged
|
|
|
Hi Aj,
<<< You
…We could play with the delay until we see which setting works best for us, and if on a particular recording we do not need a delay, then we won't use it. Wouldn't you agree?
Support >>>
Yes, that is exactly correct.
I would imagine that you would use a simple 500 millisecond record delay that would allow the end of the recorded wave file to not contain the in-band DTMF tone that the media engine is detecting. You would use this same delay record setting for all incoming IVR calls that you process and that are terminated with the ‘#’ key.
<<< You
If you cannot think of any other suggestion, what would be the next step to make this happen?
Support >>>
Because your team has a support agreement with us, I think we will simply add the new capability to the next version of the media engine (v6.0.0.13) and get an “engineering release” to you for evaluation and qualification testing. After you complete your testing, we can upgrade your current product images – no additional cost.
Best,
Randal
|
| Back to Top |
|
| |
ajdiaz
Junior
Joined: December 10 2007
Location: United States
Posts: 76
|
| Posted: June 04 2009 at 5:37pm | IP Logged
|
|
|
Hi Randal,
That would be great. Let's go ahead with the plan you are suggesting.
Please give us an estimated timeline.
Thanks again,
-AJD
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: June 05 2009 at 9:22am | IP Logged
|
|
|
Hi Aj,
I think we should plan on getting you an updated image some time next week. Sorry – I can’t be more exact that this. We should be able to slip this update in with some of the other work we are completing.
I will post again to this thread when we have something ready for you.
Tell Matt I say hello.
Best,
Randal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: June 12 2009 at 1:40pm | IP Logged
|
|
|
Hi Aj,
We have updated your support FTP account with the latest “engineering release” media engine image v6.0.0.14. This image will function until the end of July. You can use this latest image for testing with your VOIP app builds. Do not use this image with your LanScape call tester app.
Item 1:
This updated media engine contains the “record delay” update we previously discussed. See the developers reference that comes with the image – specifically the StartPhoneLineRecording() API procedure. The RecordDelayMs parameter of the StartPhoneLineRecording() API procedure can be used to specify a record delay in milliseconds. Make sure to rebuild your app using the included media engine lib and header file. A record delay of 500Ms should be more than enough to remove any trailing ‘#’ DTMF in-band tone from your recorded call’s audio.
Item 2:
This media engine image addresses the release build assertion failures you brought to our attention in the following post:
Assertion Failed:
http://www.lanscapecorp.com/forum/forum_posts.asp?TID=588&PN =1
We would still like to get your SIP log for the calls that experienced the original issue.
Note that v6.0.0.14 is an “engineering release” and still must go through additional testing. If you experience any issues, please post back to this thread.
Thank you,
Randal
|
| Back to Top |
|
| |
ajdiaz
Junior
Joined: December 10 2007
Location: United States
Posts: 76
|
| Posted: June 12 2009 at 1:57pm | IP Logged
|
|
|
Hi Support,
Does v6.0.0.14 resolve the assertions issue, so that they do no longer fire?
-Alex
|
| Back to Top |
|
| |
ajdiaz
Junior
Joined: December 10 2007
Location: United States
Posts: 76
|
| Posted: June 12 2009 at 1:57pm | IP Logged
|
|
|
Yes it does. Just read it. Sorry about that.
Thanks again.
|
| Back to Top |
|
| |
ajdiaz
Junior
Joined: December 10 2007
Location: United States
Posts: 76
|
| Posted: June 17 2009 at 8:28pm | IP Logged
|
|
|
Support,
Tests so far indicate that we are not getting the 'Assertion Failed' message with version 6.0.0.14.
Also, we are taking advantage of the record delay parameter and it looks like it is working fine. The pound # DTMF sound previously being recorded is not in the wave file anymore. I think 300ms was what did it for us.
Thanks again.
-AJD
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: June 18 2009 at 8:01am | IP Logged
|
|
|
Hi Alex,
Assertion failed:
Sounds good. I posted other info to support forum post:
http://www.lanscapecorp.com/forum/forum_posts.asp?TID=588&PN =1
Record delay:
300Ms sound good. Using that value for a record delay basically truncates the recorded end of file by 300Ms when recording gets turned OFF so you do not hear the DTMF in-band tone. Simple… but it works.
I will contact you again when the new media engine version has been released.
Thank you,
Randal
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: Pound # being recorded in wave file
