| Author |
|
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: October 04 2007 at 10:02am | IP Logged
|
|
|
Jalal,
Yes exactly. A release date before the end of this year is what we are planning. When we have product ready, we will be contacting you via email. We will most likely get you an updated product image via FTP download for your testing.
Support
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: January 08 2008 at 11:47pm | IP Logged
|
|
|
Hi,
We are now on 9th of January and you have not release any version yet. Do you have any new plan for your release date?
Regards,
Jalal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: January 09 2008 at 8:28am | IP Logged
|
|
|
Hi Jalal,
Thanks for posting. We hope you are well. The reason for the long wait is that paid customer support issues takes precedence over free support. That’s just the way it has to be.
As far as an official release date for the next v5 VOIP Media Engine, that is still going to happen. We will do the release as soon as we can. Managed .NET documentation and managed code samples are waiting for completion. However the most up-to-date binaries for the native Win32 VOIP Media Engine and the managed code API wrapper are all currently shipping. We will want to get you this current release for testing at your location.
Now, back to the “Play delay bug” issues…
Voice path latencies:
The current media engine supports internal signal path audio resampling in order to remove audio signal path latencies. VOIP calls using continuous streaming media have no built up audio delays regardless of call duration. The feedback regarding this improvement has been good thus far.
Playback delay build up when using Tx IVR outputs:
We have tested a few possible improvements for this characteristic but are not able to release an update as of yet. Just let it be known that it is our intent to eventually eliminate this latency.
Possible workarounds:
If playing back long or continuous TX IVR prompts, your VOIP application software can pass the prompt sample blocks through your own VAD logic (prior to sending the sample blocks to the Tx IVR outputs) to introduce small “dead times” that will not be noticeable to end users. In a previous post, juice mentioned similar tactics. Be sure to double buffer the sample block you send to the TX IVR outputs.
If your application is using the TX IVR lines to tie phone lines together (for bridging the line), this technique is not required anymore. The latest version of the media engine supports an infinite number of conference session groups. Phone lines can now be bridged internally using the updated conference support. Using this new technique will simplify the application and take advantage of the “Voice path latencies” improvements described above.
If you want to test the latest v5.12.8.0 version, repost and we will get it to you via your FTP support account.
Support
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: January 09 2008 at 9:03am | IP Logged
|
|
|
Hi,
Thanks for your detailed reply.
As I have mentioned in my previous posts we have to issues for latency.
1- Using the TX IVR lines to tie phone lines together (for bridging the line): In your previous post you have encouraged us to use your new conference instead of this method. Do you mean if we use this method our latency problem will be solved for ever?
2- Playing long duration and continous fax data on the line: To solve this problem you have suggested to use VAD. But as the fax data file is continous and there is no silence until end of data any latency or packet lost during play of this file will result to fax receive error. Do you have any new suggestion for this?
We are interested to recheck your latest version 5.12.8.0 to check your new conference methods for first issue. So please update our ftp account and let it be enabled till end of saturday because I may not be at office till then to download the files.
Thanks
Jalal Abedinejad
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: January 09 2008 at 9:49am | IP Logged
|
|
|
Jalal,
Item 1:
Yes, your voice path latency should be gone if you use the new conferencing capability to bridge phone lines.
Item 2:
Ohhhhh! You are trying to send fax data via the TX IVR outputs. We did not know this. We have never tried this.
We do not know the intricate details regarding the robustness of sending digitized FAX via UDP (possible network latencies and packet loss) but you would think that FAX signal tone negotiation and handshaking could withstand a 20Ms signal dropout occasionally. I mean, FAX tone negotiations and handshaking must be able to overcome noisy analog phone lines anyway, right?
If you tell us exactly how you are trying to send digitized FAX via VOIP using the media engine, we will help as much as possible within the guidelines of free support. Once we understand exactly what you are trying to do, we will think about possible solutions and post.
Questions:
With the current VOIP Media Engine, have you already tried sending FAXes?
What are the errors are you seeing in the FAX being transmitted?
Does it currently work at all?
Anyway, sounds like a cool application. We are sure other users would also like to know how to do this. If we can come to a solution that really works, we would like to write up an application note and publish it via the web.
Your support FTP account is enabled and has a time bombed version of the latest media engine. It will be OK for the next few months (end of June). Be sure to rebuild your app using the new lib and header file. If you are still using Delphi, make sure to diff the API header files for any API changes/updates.
Support
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: January 12 2008 at 9:59am | IP Logged
|
|
|
Hi,
Item1: I have downloaded the files and will test this issue as soon as possible and send you the results.
Item2: As I have said before we have IVR applications here which works on our own developed Computer Telephony Hardwares. These applications also work on Intel Dialogic Hardwares. We have developed some modules to support both sending and receiving Fax images over G711-ulaw codec.
We have also tested these FAX API on Dialogic boards which does not have fax feature.
These IVR applications may also work with SIP through Lanscape Media Engine. (This project is not released yet because of the bugs we have seen on LME). So the same API can be used to work with any Tazarv/Dialogic/SIP hardware.
As we have encountered this latency in the bridge solution discussed before we had never tested the fax over IP. But today I have tested it with LME v5.12.3.30 and we did it successfully both on sending and receiveing fax images. We did it using a Panasonic Fax machine and a Linksys SPA3000 voice gateway using G711-ulaw codec. The test is done on a 100Mbps LAN so there should not be any packet loss.
We did not see any page receive/send error both sides but I think it is because our test pages were not large enough to reach the latency problem. For any reason if one or more 20ms packet is lost or sent by a delay it depends on the receiving fax machine. Some fax machines drop the call and some other will drop some lines of the page and continue from next lines. For best quality it is better LME send TX packets in time and there should be no latency or this latency should be less enough to be ignored.
If you want I can send you a test IVR application for you to test. Contact me directly on abedi at tazarv.com.
Regards,
Jalal
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: January 20 2008 at 1:04am | IP Logged
|
|
|
Hi
Item 1:
Support: Yes, your voice path latency should be gone if you use the new conferencing capability to bridge phone lines.
Jalal:
I changed my Test Bridge application to use SetConferenceGroupIds and ConferenceLine to make two phone lines in a Conference Group. I did following deployment for test.
ComputerA : Phoner Free Softphone + Wireshark Sniffer
ComputerB : My Conference Server Sample Application using LMEVoip
ComputerC : Telephony Echo Server Sample Application of LMEVoip
I called from A to B and then from B to C and put the two call in a conference Group on B.
I recorded all packets on A using Wireshark and then saved the analyzed VOIP call in a file and checked the distance between sent DTMF voice and the received DTMF. Note that C is a Echo server and returns what is received immediately. The distance was noticebly about 3100 (ms).
In our previous Bridge tests which we did not use Echo server to test the delay it was about 1500 (ms) but
I think the delay is doubled because we have two voice path on the conference server. One for sending from A to C and another from C to A.
So the delay problem is not solved at all in this version even in conference.
Regards,
Jalal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: January 21 2008 at 12:24pm | IP Logged
|
|
|
Jalal,
Your description sounds OK but something in your test setup must be wrong.
The VOIP Media Engine version you have (v5.1.8.0) has audio resampling enabled internally by default in the audio paths.
We just set up a VOIP bridging/conference server application we use here. Two SIP VOIP endpoints call into the server. With resampling disabled, we are able to observe the build up of voice path latency. With resampling enabled, all voice path latency disappears. You better check your setup again.
There are 2 undocumented API calls that will allow you to enable/disable audio path resampling:
Code:
TELEPHONY_RETURN_VALUE VOIP_API SetMixerResampleState(
SIPHANDLE hStateMachine,
BOOL EnableState
);
TELEPHONY_RETURN_VALUE VOIP_API GetMixerResampleState(
SIPHANDLE hStateMachine,
BOOL *pEnableState
);
|
|
|
Application code does not have to call the above APIs but you may find them useful.
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.
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: January 22 2008 at 5:58am | IP Logged
|
|
|
Hi,
I replaced ComputerA in my previous test with a LinkSys Sipura SPA3000 voice gateway. It seems there was something wrong with ComputerA because by this change the delay was reduced to less than 200 ms after about 20 minutes.
So congradulations. The delay problem is solved.
But I did more tests and I found a new problem. I compiled the SingleLine Phone sample with new LMEVoip and stored the raw RTP packets (G711 codec) sent by SingleLine to LinkSys in a file using wireshark. In this test I did not use conference, just a direct call from LinkSys SPA3000 to SingleLine softphone. I compared this raw file with the recorded raw file (using wireshark again) of packets sent by previous version (v5.12.3.30) of singleline phone using CoolEdit Pro. It seems when I have no microphone to send any data on the line, in new version there is a short low amplitude noise(less than -60db) on the sent RTPs periodically (period is not constant). This is while the complete raw file sent by previous verion is absoultely silent and there is not even one noise. I think this noise is added because of resampler you mentioned in your previous post.
I know this low amplitude noise is not so important but just wanted to let you know that this problem is created in this version.
It seems the delay problem is not only fixed for conference state but also it is fixed for any direct voice call. I say this because I tested new singleline phone and previous one in the same test environment and there was no delay on this new version while there was some delay on previous one.
I also tested this new version for sending and receiving faxes at 9600 bps rate and I did not see any problem.
Just for my info: What does audio resampler added in this version do?
Regards,
Jalal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: January 24 2008 at 2:54pm | IP Logged
|
|
|
Hi Jalal,
You >>>
Just for my info: What does audio resampler added in this version do?
<<< Support
I guess the term resample is not completely correct. We added internal time scaling to internal media streams. We will be adding improvements to the current implementation as we continue on. For right now, we just wanted to get the latencies down. It should get better as we go on from here.
Regarding sending and receiving faxes:
That is good news. Sometime we will have to discuss with you how you are actually doing this. We are curious if you are dealing with an “all software” hosted solution.
Also note that we are not forgetting about the time build up in the transmit IVR outputs. That will be good to get that complexly gone too.
Thanks,
Support
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 15 2008 at 7:21am | IP Logged
|
|
|
Hi Jalal,
Playback delay build up when using Tx IVR outputs:
OK. We finally have come to a conclusion regarding this issue. All of the internal digital mixers in the media engine that are used to combine transmit IVR sample block data with normally recorded audio (to be sent out the phone lines) have been re-engineered/updated. The software changes completely remove any Tx IVR time build up. So at this point, this issue should be a “done deal”.
We tested the new changes with sample wave files of varying sample lengths in addition to others about 1 hour in length. No time creep at all.
You will get this update when we get you the latest product distribution. We are glad to get this Monkey off our back. :)
Support
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: February 15 2008 at 11:59pm | IP Logged
|
|
|
Hi,
Although our problem was fixed with previous version but this a very good news.
So with this new version if we use TX IVR lines to tie two phone lines for bridging purposes, we will never encounter the latency again. Am I right?
Do you have any decision for the release date? If you think it will take long time, you would send us a pre-release version to test this issue.
Regards,
Jalal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 18 2008 at 8:04am | IP Logged
|
|
|
Jalal,
You >>>
So with this new version if we use TX IVR lines to tie two phone lines for bridging purposes, we will never encounter the latency again. Am I right?
<<< Support
That’s correct.
You >>>
Do you have any decision for the release date?
<<< Support
We have to get the next maintenance release out this month (February).
Support
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: Playing Delay Bug
