support Administrator
Joined: January 26 2005 Location: United States Posts: 1666
|
Posted: November 17 2008 at 3:16pm | IP Logged
|
|
|
Hi George,
Acoustic Echo Cancellation:
The media engine does not yet support echo cancellation on a per phone line basis internally. We know the importance of offering this capability and have it targeted for a future release. Internally handled AEC per phone line will definitely be a great benefit.
At the moment, customers who require AEC on each phone line use the RAW RTP packet access and their own AEC algorithm for echo cancellation processing. We know this is a clunky but it allows them to accomplish the echo cancellation task.
Noise Suppression:
This can mean a few different things. What the media engine supports is a form of noise gating on the local audio signal that gets sent out individual phone lines. We process the locally recorded multimedia audio signal and check it against noise gating settings as set by the application calling the SetNoiseDiscriminationEnableState(), SetNoiseThreshold() and SetSilenceDecay() API procedures. With the settings specified by the above procedures, we “noise gate” local recorded audio that is sent to any active phone line. If the volume level of local audio exceeds the noise threshold, the audio is allowed to pass to RTP transmitter functions on a per phone line basis. If the local audio drops below the set noise threshold, the local recorded audio passes for a fixed amount of time before being turned off. When local recorded audio gets turned off by the gating function, no RTP payload packets get transmitted. The noise gating function makes sure that there are no discontinuities in the transmitted audio signal as to not introduce step response noise in the transmitted audio. This noise gating capability allows the media engine to only transmit RTP packets (regardless of codec) when no local audio is generated. The media engine will also always send RTP keep alive packets at an application specified interval if told to do so for the purpose of maintaining NAT traversal of RTP media packets.
For any other form of noise suppression – customer’s use the raw RTP packet access capability and do whatever they want.
Automatic Gain Control:
The media engine does not perform native AGC on transmitted or received phone line audio levels. We would really like to get this in the product ASAP because it is fairly easy and we could handle this in the RTP transceiver logic. Again, customers who needed AGC have performed their own simple feedback loop using the raw RTP packet access API interface (simple averaging filter on the RTP media packets that drives the AGC set point). The transmit and receive averaging filters per phone line would then use the SetPhoneLineVolume() API procedure to constantly “tweak” the transmit and receive phone line volumes. Clunky but entirely possible to do.
VAD/CNG/DTX:
Current media engine codecs do not support RTP VAD/CNG/DTX payloads and the media engine does not negotiate codec types that use VAD/CNG/DTX payloads. We see this changing as soon as we add additional codec support such as G729B through G729E for example or any other coded that supports a VAD/CNG/DTX capability.
The great thing about LanScape is that we really like working with customers to improve the media engine product. New capabilities and features are continuously being added to the media engine as a direct result of customers and us working together.
Repost if we have missed something or if additional clarification is needed.
Support
|