| Author |
|
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 27 2008 at 6:02am | IP Logged
|
|
|
Note:
We recently received this email from a customer. We wanted to post the information here in case it is useful to someone else.
Support
--------Original Message--------
Hi,
I am looking for answers to the following pre-sales questions. We are looking at using LanScape for creating a conferencing server.
1) Its noted that parties in a conference can be using different codecs, but I noticed a possible restriction in the developer docs that the codecs be running at 20ms? From CreateFormatRateConverter: "When you use the VOIP Media Engine's internal format and rate conversion functions, you will be able to convert between all of the supported 20Ms audio data types with ease." Is this a ptime restriction for the RTP streams?
2) Are there any licensing requirements on our part for using the G729 codecs?
3) Please confirm that the codec translations can be done both in real-time and off-line (re-formating a recorded file for example from one codec to another)
4) Does the library have an AGC (automatic gain control) filter?
5) Does the library have an Echo cancellation filter?
6) What CPU/hardware requirements are there for running various session densities on a single box?
7) Will the libraries performance improve with the use of additional CPU cores/cpu's? (multithreaded design?).
thanks!
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 27 2008 at 8:02am | IP Logged
|
|
|
Hi Justin,
Thanks for your questions.
Item 1, Question regarding codec restrictions:
Conference parties can use whatever media codecs are supported by the media engine for their calls. There is no 20Ms restriction. The actual RTP media format used for each call does not matter and the actual RTP frame size (in milliseconds) does not matter. The media engine will handle it all automatically when the call (phone lines) are placed into conference mode.
If you want to use the “stand-alone” format/rate conversion blocks the media engine supports, that’s a whole ‘nother question. You can use them for whatever media frame size you want. They convert 20Ms worth of sample block data at any one time. If you want to deal with 30Ms, 50Ms, or whatever media frame sizes, then your app code will have to “block time convert” the media data for whatever purpose it requires. This simply means performing proper buffering of enough 20Ms blocks of data so that you can format/rate convert 20Ms blocks using the stand-alone converter support in the media engine and then forward the appropriate sized sample blocks to where they need to be consumed. If we knew more about your application’s specifics, we could elaborate more.
The stand-alone format/rate conversion support in the media engine was chosen to use 20Ms frame size because any higher sample block size can be created from that using proper buffering and using a “block time convert” scheme. Its pretty simple. The stand-alone format/rate conversion blocks in the media engine do not care about a call’s SDP “ptime” parameter for the RTP streams.
Item 2, G729/G729A licensing:
If you use G729/G729A, you have to talk to Sipro Labs (http://www.sipro.com) to pay their licensing fees. Here is a post in this forum that will explain more:
Alternatives to licensing G729 - we request your input:
http://www.lanscapecorp.com/forum/forum_posts.asp?TID=436&PN =1
Item 3, Codec translations:
You can use the stand-alone format/rate conversion capability the media engine supports real-time or off-line. It does not matter.
Item 4, AGC:
The media engine uses AGC internally for some of its processing functions but AGC is not generically exposed via the API. If you want generic AGC capability, its simple enough to add yourself. If you do not know how to develop AGC functionality, we can assist you. If you need to apply AGC to an internal media engine signal path that we currently do not allow access to via the API, we will gladly update the media engine to allow what is needed.
Item 5, Echo cancellation:
The media engine employs no internal echo cancellation. We have considered natively supporting robust echo cancellation in the signal paths but have not yet committed. Let us know what your requirements are and we will support you as appropriate.
Item 6, Required CPU and host hardware:
If you want to get the most out of the media engine put it on the fastest box you can afford. It will run on anything - event old slow hardware that runs Windows 2000. Call processing throughput is very, very, very fast.
If you want to get the most out of the media engine, make sure to develop your VOIP app using native C++. You will get better performance over developing the VOIP app using .NET languages.
Item 7, Multi-processor scalability:
The more CPU cores that exist on the host machine, the better. The VOIP Media Engine is completely multithreaded and multi-core aware. We are pretty exited about the future of this software because as hardware improves, becomes faster and adds more CPU cores, the media engine will automatically take advantage of it. It will rock. We are also excited to support upcoming 64-bit native and .NET versions.
All good questions!
Thanks,
Support
|
| Back to Top |
|
| |
|
|
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Pre-Sales Technical Support
Topic: Developing a conferencing server
