Author |
|
timkelly1980 Intermediate
Joined: February 07 2005 Posts: 25
|
Posted: April 01 2005 at 2:50pm | IP Logged
|
|
|
Hi.
I am getting a kind of tapping / clicking very faintly when I call an analogue line via my PRI pbx. I don't get it using x/ten xlite. I am using the ulaw codec.
Any ideas!?
Cheers,
Tim
|
Back to Top |
|
|
timkelly1980 Intermediate
Joined: February 07 2005 Posts: 25
|
Posted: April 01 2005 at 2:51pm | IP Logged
|
|
|
The tapping is regular about every 1-2 seconds... quite faint but annoying.
|
Back to Top |
|
|
timkelly1980 Intermediate
Joined: February 07 2005 Posts: 25
|
Posted: April 01 2005 at 4:10pm | IP Logged
|
|
|
I should also point out that the tapping is heared on the other end of the line (on the normal telephone) not on the sip end.... I played about with the setsilencedecay and noice discrim with no joy. :(
|
Back to Top |
|
|
support Administrator
Joined: January 26 2005 Location: United States Posts: 1666
|
Posted: April 02 2005 at 7:19am | IP Logged
|
|
|
Hi Tim,
Sounds like a typical RTP media stream related issue. We need to isolate the culprit. A few things to try:
What happens when you use your application to call another soft phone or IP phone on the network? Any similar clicking on the receiving end?
Make sure manual jitter comp is off by calling the SetEnableJitter() API proc. Set the EnableState param to zero. The media engine will handle jitter related issues by itself automatically.
When noise discrimination is ON, voice data only gets transmitted when the signal level on the soft phone side exceeds a set level. For testing purposes, completely turn OFF this function using the SetNoiseDiscriminationEnableState() API proc. Its possible that the starting and stopping of the media stream is upsetting something.
Make sure the Xlite soft phone is also using 8k uLaw codec when you make a test call. We need to know if it is something specific to your media engine application or the PRI/Asterisk setup you have.
If you are calling the EnableKeepAliveTransmissions API proc, you might not want to do this for your particular setup. This proc should have no effect but anything is possible.
Media Stream Transmit buffering:
Your application can control the audio buffering depth of all media data prior to it being transmitted. Normally it should be set to 2 but depending on the type of host machine you are using, its possible this may have to be increased. See the PhoneLineTransmitBuffering member of the START_SIP_TELEPHONY_PARAMS structure.
Repost as necessary.
LanScape Support
|
Back to Top |
|
|
timkelly1980 Intermediate
Joined: February 07 2005 Posts: 25
|
Posted: April 02 2005 at 12:53pm | IP Logged
|
|
|
Excellent. I changed that buffer setting to 4 and the ticking has gone. Phew! That was one of those horrible problems because it worked fine on my development machine but not on the machines I am meant to be rolling out in 5 days time!
The quality is pretty good now although a little bit of tweaking I think is still needed:
a) There is a slight muffled background noise that comes and goes on the lanscape end, it almost jitters (only the noise jitters, when the person is talking their voice does not jitter). I can actully hear the other person fine, but this background noise is always present. I wonder if you could advise on settings that might help. I wonder if you have a list of typical settings for jitter msecs and noise thresholds etc.
b) there is also a slight echo when calling over the pstn that can be heard only on the remote end (I think this is something I can fix with asterisk though)
|
Back to Top |
|
|
timkelly1980 Intermediate
Joined: February 07 2005 Posts: 25
|
Posted: April 02 2005 at 1:36pm | IP Logged
|
|
|
Agghh!
I switched from my USB headset back to the sound card and my noise has gone (i think the headset has noise cancelling) but the after about 20secs of talking the tapping comes back!
Cheers,
Tim
|
Back to Top |
|
|
timkelly1980 Intermediate
Joined: February 07 2005 Posts: 25
|
Posted: April 04 2005 at 12:14pm | IP Logged
|
|
|
I am still clicking!
I have tried a different sound card, and tried fiddling with the buffer. When I increase the buffer it seems to solve the problem for about 20secs and then I get the clicking again. I have tried setting the CPU priority of the program to real-time and the click rate doubles... not sure if this helps you help me track down the problem.
Do you have any more suggestions please?
|
Back to Top |
|
|
support Administrator
Joined: January 26 2005 Location: United States Posts: 1666
|
Posted: April 18 2005 at 10:28am | IP Logged
|
|
|
Additional notes regarding the clicking Tim Kelly has reported:
Tim’s application is using the LanScape VOIP Media Engine 5.10 in a Windows 32 bit application to make out going phone calls via the open source Asterisk PBX. Asterisk in this case is being used as a PSTN gateway. The PSTN trunk is a T30 line.
The “clicking” that has been reported occurs only when the VOIP Media Engine based application makes a PSTN call via Asterisk and when Tim’s application is executed on a GX60 Dell optiplexe (Celeron 2.4GHz, 256M ram) host machine.
The destination of the call on the PSTN side will start to hear a subtle click after the call has been active for a while. Other call scenarios such as calling soft phone to soft phone do not experience the reported “clicking”.
Findings:
Our tech team worked with Tim on this issue to attempt to isolate the cause of the clicking. Using Ethereal network analyzer, Tim logged all SIP and RTP packets that were being exchanged with his Media Engine based VOIP application and the Asterisk PSTN gateway.
After analyzing the data, we found that the average RTP transmit media block times of 20ms were not being met when using the GX60 Dell optiplexe host machines to execute Tim’s Media Engine VOIP application. This was determined from extracting RTP traffic data from the Ethereal logs and analyzing/graphing the data.
This was our last transaction with Tim on this issue:
Tim>>>
Hi.
My solution didn't work after all, but I managed to delay the ticks until 1min 10secs by setting the transmit buffer to 8.
The new machines didn't help, and I tried changing the celeron 2.4 to a
3gig pentium 4 with a 800mhz fsb.... same problem which means it is definatly the chipset / drivers for it.
I have spoken to dell about this at a high level and they are going to get intel to investigate. I think we agree that this is a timer resolution problem. But i need to know exactly what the engine needs. Does it request a callback from the operating system every 20ms or is it ever 1ms.
LanScape Support>>>
20 ms with a tolerance of +-1ms.
The critical code in the media engine that is responsible for transmitting blocks of RTP media data is expected to execute every 20ms. We normally see a tolerance of +-0.5 ms in this code on generic machines. The actual tolerance is important but not as important as the overall average 20ms block rate. In other words, Windows 32 bit systems execute all process threads on a "best effort" basis. If you ask the OS to call your multimedia thread code every 20ms or wait on an event with a timeout of 20ms, the operating system does not execute the thread code faithfully every 20 ms like we want. What it tries to do is to ensure that the average thread execution rate is maintained at 20ms.
You can see this from some of the data plots we exchanged. If you notice, the critical code execution times dither about the desired 20ms point. Sometimes it takes the OS just a bit longer to get around to executing our code (lets say 20.2ms). The OS keeps track that it was a bit late when it executed our code so the next time it tries to call our thread handlers, it will do so again in 19.8ms. So the OS is making an attempt to keep the average thread execution times constant
(20.2 + 19.8)/2 blocks = 20ms average/block.
This behavior does not equate to hard real time programming but can still be used if a CPU is fast enough and system loading is not heavy.
What we see in the data plots from your Dell machines is that the average block time is exceeding 20ms over some finite period of time. For example, in the plots we see data being transmitted that dithers about the 20ms mark, then all of a sudden, the OS on your machines execute our critical code consecutively late for 2-3 20ms block times. This is introducing a block time error that builds up over time.
This is causing a data starve condition at the Asterisk PSTN gateway (no data) and this is what appears to be causing the clicks.
Tim>>>
I presume you are using the windows "multimedia timer". as opposed to the normal system timer? Please can you confirm this.
LanScape Support>>>
We use both multimedia timer callbacks and standard thread event programming. The media engine modifies the system timer resolution of its process so our overall thread execute resolution is 1ms.
Tim>>>
I was thinking of making a program which asks for a callback every 1ms and then logs to a file if it misses the deadline, I could use this for testing purposes.
Cheers,
Tim
|
Back to Top |
|
|