| Author |
|
Joe Sansalone
Intermediate
Joined: February 18 2009
Location: Canada
Posts: 6
|
| Posted: February 18 2009 at 3:52pm | IP Logged
|
|
|
Hi,
I'm currently running several Dialogic (ISDN PRI) servers. All development was via the Dialogic API. I'm eager to replace everything with a SIP based Media Engine. I develop in Delphi.
Do you have a Delphi wrapper? If not, do one of your clients? (maybe I can purchase for a fee).
Can I use your components/objects using many threads - like 1 or more per channel? Also, does your engine scale well via more cores?
We have 1 system that needs 250 channels right now (500 in 6 months).
Joe
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 18 2009 at 4:55pm | IP Logged
|
|
|
Hi Joe,
Thanks for your post. We updated your post above with the original email you sent us.
You >>>
Do you have a Delphi wrapper?
<<< Support
We do not have an official LanScape developed Delphi wrapper. What we do have is a Delphi wrapper that was developed and kindly submitted to us by one of our customers. The ZIP archive in the above link is a Delphi wrapper for v5.12.3.14 of the media engine that we previously released. You could use that code as a starting point of your development and add to it if required. The wrapper code in the above link is pretty complete for that version of the media engine. The archive also contains Delphi sample application code too. For a skilled Delphi developer, updating the wrapper code above to the latest Release 6 media engine would be pretty simple.
If you are interested in updating this wrapper code for other Delphi users to the Release 6 media engine, we will gladly place a copy of your work on this server for other Delphi developers to download. We will just make the Delphi wrapper code freely available without charge.
You >>>
Can I use your components/objects using many threads - like 1 or more per channel?
<<< Support
Hmm… I am not exactly sure what you are asking.
As far as using the media engine in a multi threaded way, the answer is yes. The VOIP media engine is fully multi threaded. There are only a few calling restrictions associated with the media engine in an effort to avoid dead locks. Other than that, your VOIP app can use the media engine in a fully multi threaded way.
You >>>
Also, does your engine scale well via more cores?
<<< Support
Yes. Because of the threading nature of the media engine, the more cores the better. Quad core or Intel i7 core CPUs work very very well compared to the single core CPUs. The difference is pretty cool. We are getting around to publishing data via the web. Unfortunately at the moment, performance and processor scalability benchmark data is not available. :(
Currently we perform the development and testing of the media engine product on Intel Quad core and i7 host machines.
You >>>
We have 1 system that needs 250 channels right now (500 in 6 months).
<<< Support
That is great. Hopefully we can discuss your requirements in more detail. We have a lot of other customers that license our VOIP media engine product to do the following:
1)
Reduce the dependency, availability and sourcing problems associated with VOIP hardware from other 3rd party vendors.
2)
Simplify their VOIP systems and deployments.
3)
Replace their VOIP hardware solution with a pure 100% software VOIP media engine solution. VOIP hardware is expensive compared to a pure software solution.
4)
Reduce the overall cost of their VOIP system.
5)
As time progresses and higher density multi core CPUs become available, the media engine will automatically inherit this power giving you the ability to offer higher line densities of your VOIP solution. Nice.
Thanks again for your post,
Randal
|
| Back to Top |
|
| |
Joe Sansalone
Intermediate
Joined: February 18 2009
Location: Canada
Posts: 6
|
| Posted: February 18 2009 at 5:25pm | IP Logged
|
|
|
Randal,
Thank you for the detailed response. And thanks for updating my post with my original email.
I'm very happy I found your company!!
Joe
|
| Back to Top |
|
| |
Joe Sansalone
Intermediate
Joined: February 18 2009
Location: Canada
Posts: 6
|
| Posted: February 18 2009 at 5:27pm | IP Logged
|
|
|
Can you give a little sneak peak at what a Quad or i7 processor is capable of scaling to?
Joe
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 19 2009 at 8:21am | IP Logged
|
|
|
Hi Joe,
Thanks for your kind words.
Regarding quad and i7 core scaling - what I can tell you at this time is this:
When we test the media engine on quad core architectures (quad cores, not the i7), we use two VOIP server applications we developed here in our lab. These applications each use the VOIP Media Engine.
When we perform “burn in” testing of the media engine, we configure both of these apps to instantiate 128 VOIP phone lines. The two apps perform all sorts of API and functionality testing. They also perform simultaneous call testing. When the call testing portion of the tests execute, the two servers hammer at each other initiating and receiving phone calls using all the various supported codecs (G729, iLBC, uLaw, aLaw and the PCM codecs).
Quad Core Performance Summary
During the call phase of testing we effectively have two 128 line VOIP servers running on the same test machine and CPU loading is about 90%.
The basic hardware spec of a typical quad core test machine is:
Motherboard: Intel Desktop Board DP35DP
Intel Quad Core CPU Q6700 @2.66Mhz
Windows XP Pro SP2 (32 bit)
4 gig or ram
2 standard SATA 3 hard drives installed - non raid configuration.
100Mbit Ethernet NIC.
Various multimedia sound card hardware.
Other than the above specs, the test machines are absolutely “off the shelf” plain vanilla quad core PCs.
The i7 cores with their on chip memory controller and the dual threading per processor is expected to allow even higher concurrent call line densities. How much? We will have to test and see.
Thanks,
Randal
|
| Back to Top |
|
| |
Joe Sansalone
Intermediate
Joined: February 18 2009
Location: Canada
Posts: 6
|
| Posted: February 19 2009 at 9:49am | IP Logged
|
|
|
Hi Randal,
That sounds very promising.
During this testing, do the apps play audio files? Do they also process DTMF digits?
Any idea of what kind of call volume happens during this "burn in" testing? I'm guessing that you just let the app blast away calls ... even to the point of 128 simultaneous new incoming calls?
I'm hoping this means I can have 512 channels on 1 machine.
If my app simply answers an incoming call and then makes an outgoing call and connects the 2 audio paths, so that 2 people are having a conversation. From your testing/experience, would a quad-core be able to have 256 simultaneous calls (2 channels each)?
Does connecting audio paths take much CPU power?
I'm asking a lot of questions ... it's just I'm coming from TDM world with hardware and ISDN ... I'm not yet familiar with what basic functions take a lot of CPU ... I know the codec does - especially if it's G729 vs G711.
You see, in Dialogic hardware land, connecting 2 audio paths doesn't take any cpu .. 2 users can talk and talk to each other and it really doesn't do anything.
The call control signalling does use up some ... I'm guessing that SIP uses about the same ... maybe a little more.
I appreciate the answers so far!
Joe
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 19 2009 at 7:58pm | IP Logged
|
|
|
Hi Joe,
You >>>
…During this testing, do the apps play audio files?
<<< Support
Yes. When the calls connect, both ends play random wave file content for the entire duration of the calls.
You >>>
Do they also process DTMF digits?
<<< Support
No.
In-band DTMF:
Note that the additional system loading for enabling in-band DTMF detection is pretty minimal on a per phone line basis. Also, the DTMF generation per phone line is even more light weight seeing that a single multi-toned software based DTMF generator is implemented and is shared by all phone lines.
Out-of-band DTMF:
Now if we talk about RFC2833 out-of-band DTMF generation and detection, there is no need to talk about extra system loading seeing RFC2833 out-of-band DTMF is incredibly efficient when handling generation and detection. RFC2833 based DTMF is the only way to go if you have a choice. It gives both minimal system loading and excellent DTMF generation/detection characteristics.
You >>>
Any idea of what kind of call volume happens during this "burn in" testing? I'm guessing that you just let the app blast away calls ... even to the point of 128 simultaneous new incoming calls?
<<< Support
Wow, you are exactly correct – blast away is the perfect description. Depending on the timing of the calls as the test execute for hours and hours and…, you may have 128 concurrent calls all needing to be setup all at the same time or you may have all 128 calls in the “in call state” actively exchanging RTP media with each other – and every possible combination of call states in between these extremes.
You >>>
I'm hoping this means I can have 512 channels on 1 machine.
<<< Support
This all depend on your host hardware. We have run the media engine up to 1024 lines on Windows XP Pro SP2. This means this line density is possible – not that the host can actually keep up with that type of call volume.
The primary limiting factors for these kinds of VOIP line densities are:
1) Process space memory.
2) How much CRUNCH power your host hardware has.
3) The max network bandwidth you have.
By going to a 64bit media engine, we can solve the max number of simultaneous phone lines that can be instantiated (remove the process space memory limit). The other two are dependant on how the customer intends to use the media engine.
We have a section on the software developer’s reference that gives additional info on how to reduce computation demands in the media engine to get the highest number of concurrent calls possible for your host hardware. You may want to check that out if you request a trial.
We are very excited about the future of the media engine and the line densities that will be achieved by our software as the Intel and ADM processors include more and more cores. It is our intent to have the media engine scale beautifully as higher density processor cores come on-line over the years.
You >>>
If my app simply answers an incoming call and then makes an outgoing call and connects the 2 audio paths, so that 2 people are having a conversation. From your testing/experience, would a quad-core be able to have 256 simultaneous calls (2 channels each)?
<<< Support
For 512 concurrent lines - bridging 2 lines together using the media engine’s internal conferencing capability (2 lines per conference session), the host machine would have to be faster then the one I mentioned above. However I think, (and don’t hold me to this), it would be very close if your host was based on the Intel Core i7 Extreme Edition Processor 965 with the DDR3 memory. If this configuration won’t do it, then we will have to wait for the next generation of i7s.
If you don’t use the conferencing capability, the same functionality can be achieved by simply bridging the required line pairs in software. We have other customers doing just this. In this case, system loading is less than when using conferencing to do the job and 512 concurrent calls is even closer in reach using the same hardware platform.
You >>>
Does connecting audio paths take much CPU power?
<<< Support
By “connecting” I assume you mean bridging the lines together.
The answer is yes and no (I know, …sorry).
The best way to “connecting audio paths” or “bridge lines” is to define a logical conference group for your 2 line pairs you want to connect/bridge. When you bridge the lines, the lines are added to the required logical conference session. The phone lines in the same logical conference group will exchange full duplex audio with each other without further VOIP app intervention. All the audio format/rate conversion and media exchange between the lines is handled by the media engine.
Using 2 line conferencing for bridging lines is not bad from a loading standpoint. Conferencing gets pretty expensive and requires fast host hardware if conference sessions get large - lets sat 20 or more lines in a conference group. This is because the media data that all the lines must exchange will somehow have to go through a format/rate conversion during the process which increases exponentially as the number of lines increase in the conference group.
You >>>
I'm asking a lot of questions ... it's just I'm coming from TDM world with hardware and ISDN ... I'm not yet familiar with what basic functions take a lot of CPU ... I know the codec does - especially if it's G729 vs G711.
<<< Support
Joe, you are asking great questions. Its all good. Not a problem.
Yes, from a codec standpoint G729 takes more processing than G711.
You >>>
You see, in Dialogic hardware land, connecting 2 audio paths doesn't take any cpu .. 2 users can talk and talk to each other and it really doesn't do anything.
<<< Support
Yup, I understand completely.
You >>>
The call control signalling does use up some ... I'm guessing that SIP uses about the same ... maybe a little more.
<<< Support
SIP processing for the most part is very light weight for call setup and tear-down and pretty lightweight overall. Its actually pretty amazing how much SIP you can crunch through in a given quantum of time. When compared to media handling costs such as format/rate conversions and digital mixing of streams, SIP generation/processing is not bad.
I hope this info helps.
Thanks Joe,
Randal
|
| Back to Top |
|
| |
Joe Sansalone
Intermediate
Joined: February 18 2009
Location: Canada
Posts: 6
|
| Posted: February 19 2009 at 9:29pm | IP Logged
|
|
|
Hey Randal,
Tons of stuff to absorb .. I like it! I need to get our systems to SIP, by end of 2009. So, I need to "transfer" my application knowledge to the SIP world. We already have about 40,000+ calls per day and growing.
(expected to be 350,000 calls per day by end of 2009)
I'm guessing I can load-balance several servers if I need more than 512 channels?
Can several different tasks (i.e. threads) (1 call) have access to the DTMF that one user presses? Even if that user is listening to music? Can he keep pressing DTMF and all the tasks get what he presses ... but the music keeps playing for him?
In the same sense, can different tasks "listen" to what he is saying while he's listening to audio? (this is so several threads can process Speech Rec looking for different key words)
Can different tasks (threads) control what audio is played to one channel?
I noticed you said that the conferencing engine will combine all audio in a duplex fashion. What if one user wants to access an IVR menu for himself while listening to the conference BUT he doesn't want anyone else to listen to what he's doing? (assumption: a thread is processing DTMF digits on that channel and waiting for the user to press * to access an IVR personal menu)
The app can combine all participants in one conference ID and then another ID can be everyone + his IVR?
Is it possible for a user/channel to "listen" to the conference but they can't hear him?
Obviously, I'm asking these questions with certain applications in mind. I'm more than willing to describe our different apps ...
Joe
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 20 2009 at 8:22am | IP Logged
|
|
|
Hi Joe,
You >>>
I'm guessing I can load-balance several servers if I need more than 512 channels?
<<< Support
Yes, exactly. How the load balancing between “VOIP servers” is done depends on the goals of your deployment and type of redundancy required. It can be accomplished via round robin using DNS and address records or some other load balancing means – like using a head/front end load balancing SIP proxy or similar. We try to leave the load balancing decisions up to the customers.
You >>>
Can several different tasks (i.e. threads) (1 call) have access to the DTMF that one user presses? Even if that user is listening to music? Can he keep pressing DTMF and all the tasks get what he presses ... but the music keeps playing for him?
<<< Support
Yes. If the media engine receives DTMF from any phone line, your VOIP will receive a DTMF ON or OFF event in the form of a callback handler and parameter data. Your VOIP app can do whatever he wants with the DTMF events. The DTMF events are thread independent. Even if your caller is listening to music… you can do whatever with the DTMF events.
You >>>
In the same sense, can different tasks "listen" to what he is saying while he's listening to audio? (this is so several threads can process Speech Rec looking for different key words)
<<< Support
Yes. Exactly correct. For speech recognition, you need to tap into the call’s received audio using the “Receive IVR channel” each phone line supports.
In general:
The media that is received by any phone line (the received audio) is available to your VOIP application. Your VOIP app can do whatever it wants with the received audio. You have access to raw RTP media packets if needed or you can ask the media engine to pass you received audio sample blocks (in a variety of formats and rates) via the receive IVR channel each phone line supports. Once your VOIP app gets the sample blocks from the phone line, it can do whatever it wants with the audio data.
For speech recognition it is pretty simple: Get the received audio sample blocks for the phone line using the receive IVR channel of the phone line. Then pass the 20Ms sample blocks of received audio from the media engine phone line to the instance of your speech engine for that phone line.
For more info, see the OpenRxIvrChannel() API procedure in the Software Developer’s Reference.
You >>>
Can different tasks (threads) control what audio is played to one channel?
<<< Support
Yes, Playing out audio to a media engine phone line is thread independent. In this case, to play audio out a phone line, your VOIP app would use the “transmit IVR channels” each phone line supports. Up to four Tx IVR channels can be opened to playback audio to the required phone line. All audio data your VOIP app sends to the Tx IVR channels will be digitally mixed with normal transmitted local audio and then finally transmitted out the phone line in the form of RTP packets.
For more info, see the OpenTxIvrChannel () API procedure in the Software Developer’s Reference.
You >>>
I noticed you said that the conferencing engine will combine all audio in a duplex fashion. What if one user wants to access an IVR menu for himself while listening to the conference BUT he doesn't want anyone else to listen to what he's doing? (assumption: a thread is processing DTMF digits on that channel and waiting for the user to press * to access an IVR personal menu)
<<< Support
Ohhh, I see. This is getting complicated :)
This can be performed in a number of ways.
For any phone line, your VOIP app has the ability to mute received audio or transmitted audio. It would be up to your application logic on how and when to apply audio line muting. For example: If the person (lets call this guy “Mr. Stealth”) calls into your media engine conference session that already has 2 or more people in the conference session, “Mr. Stealth” could instruct your media engine VOIP app to mute his received audio so that other conference session participants would not hear him. “Mr. Stealth” could do this with a DTMF sequence or maybe a special SIP header that “Mr. Stealth” added to his SIP INVITE request that was used to setup the call (I am assuming “Mr. Stealth” called into the VOIP server). Once “Mr. Stealth’s” received audio is muted, no one else will know he is there. He can listen to the conference and poke around DTMF menus as needed.
You >>>
…The app can combine all participants in one conference ID and then another ID can be everyone + his IVR?
<<< Support
I almost could not figure out what you were trying to ask but…
The answer is YES if “his IVR” means audio data that would be transmitted out to “him” in conjunction with the combined audio of the other conference session participants that are in a totally different logical conference.
Conference session support in the media engine is very powerful – all conferences are logical which means there can be complete phone line overlap between conference participants in different logical conference sessions.
You can imagine the media handling juggling act that goes on inside the media engine to pull this off. It’s a bit of a nightmare to get right but is very cool to see in action.
You >>>
Is it possible for a user/channel to "listen" to the conference but they can't hear him?
<<< Support
Yes.
You >>>
Obviously, I'm asking these questions with certain applications in mind. I'm more than willing to describe our different apps ...
<<< Support
We will probably have to do this at some point.
Joe, I am the founder and currently run LanScape. We are a small shop. We would welcome your business and enjoy working with your group. If there is a real business opportunity here for us to work together, we can take our conversation off line to discuss the sensitive business details further. For now however, lets continue to keep all the tech questions here as we have been doing. If you feel we need to discuss our business opportunities, just let me know. I will set up a VOIP account here for you in our system and we can discuss via VOIP calls.
By the way, where are you located? We are GMT-6.
Thanks,
Randal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 20 2009 at 8:30am | IP Logged
|
|
|
Joe,
I almost forgot to mention…
We extend to customers an “enhanced support agreement” so that we can closely work with your group if needed. This includes high end technical support during your development and long after if required. Support agreements also allow you to obtain the very latest version of our products as they are made available. Simply let me know if this is something your group would be interested in and I can forward the information to you.
Thanks,
Randal
|
| Back to Top |
|
| |
Joe Sansalone
Intermediate
Joined: February 18 2009
Location: Canada
Posts: 6
|
| Posted: February 20 2009 at 10:10am | IP Logged
|
|
|
Randal,
Well, you have me sold. We got a quote from Dialogic for its HMP SIP engine - very expensive. That's what got me looking for other providers. I looked at ASTA and wasn't thrilled that their conferencing functionality was in a seperate engine. We have a framework that allows for very unique and diverse phone apps to run all with the same group of lines/channels. And, having the ability to offer anything "phone" related is important - i.e. the media engine should support it. The only thing that your engine doesn't support is Fax.
I do have some more questions ... I'll post later today. Like I said, I'm sold!
Joe
|
| Back to Top |
|
| |
|
|
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Pre-Sales Technical Support
Topic: Delphi support? Quad Core Performance?
