| Author |
|
ajdiaz
Junior
Joined: December 10 2007
Location: United States
Posts: 76
|
| Posted: April 03 2009 at 2:17pm | IP Logged
|
|
|
Hi Support,
We noticed that in your examples, the Media Engine places SIP messages in a global FIFO queue, where another thread reads from it and passes it onto its corresponding call monitor handler thread which also has its own FIFO queue. We are not using this approach, we are using more worker threads everywhere yet sometimes experience deadlocks.
So we are looking at redesigning our application and applying the techniques used in your examples. We are taking the ConferenceServer example as our base model and building on top of it to fit our needs.
My questions are:
Does the ConferenceServer example app apply what you consider best practices? Is there anything in the ConferenceServer example app that you would consider needs improvement to be a production app?
Could it use improvements in the way maybe it updates the GUI? Or maybe with the way it handles DTMF? Or playing WAV files?
Is there anything in the ConferenceServer example app that you would not suggest we use in a production environment?
Is there another example app that maybe uses a better approach in handling DTMF? Or playing or buffering WAV files? Or updating the GUI?
Any feedback regarding the ConferenceServer app is greatly appreciated. Thanks.
-AJD
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 03 2009 at 3:26pm | IP Logged
|
|
|
Hi Aj,
All good questions.
Are you referrig to the C# conference server sample app or the two native code conference server samples?
Randal
|
| Back to Top |
|
| |
ajdiaz
Junior
Joined: December 10 2007
Location: United States
Posts: 76
|
| Posted: April 03 2009 at 3:29pm | IP Logged
|
|
|
Sorry. I'm referring to the C#.
Thanks.
-AJ
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 04 2009 at 11:04am | IP Logged
|
|
|
Hi Aj,
Deadlocks are definitely not good.
As far as designing a native code or .NET VOIP app around the LanScape VOIP Media Engine, there is a short section in the Software Developer’s Reference that discusses the recommended application event processing layout you should follow. See the section entitled: VOIP Application Design Considerations.
You >>>
Does the ConferenceServer example app apply what you consider best practices?
<<< Support
Yes.
When using the media engine, the best possible approach when designing your VOIP app is to defer as much as possible to another app worker thread when the main media engine event callback is executed in your app. To simplify things, I will use the term media engine event to mean all the types of events that are sent to your app’s main media engine main event callback hander.
With a few exceptions, almost all media engine events that your app receives (“phone line” and “global” events) can be fifo queued to one or more of your app’s worker threads. The only events that cannot be deferred are the true media engine “immediate events”.
Immediate events are sent to your app because the media engine needs your app to make a critical decision so it can continue processing calls. These immediate events cannot be deferred. Also, when the app gets these immediate events, the app should process the events and return execution back to the media engine as fast as possible. Doing so will give your app the best possible call performance and throughput.
For “phone line” and “global” events, your app should defer these to one or more of your app’s worker threads.
This next bit is important and will simplify your life:
When queuing these events to other worker threads, it is best to also get whatever additional status information that may be associated with the event while your code is synchronously executing in the thread context of the main media engine event callback handler. What I mean is, in the main media event callback handler, you app can call API procedures such as GetIncomingCallInfo(),GetOutgoingCallInfo(),GetLineStatus(), etc… to get additional status info for calls and other operations and then queue this status info along with the event info for the “phone line” or “global” deferred event to another worker thread.
Using this approach allows you to defer the events with the “true” media engine status information at the time of the event. Does that make sense?
You >>>
Is there anything in the ConferenceServer example app that you would consider needs improvement to be a production app?
<<< Support
Not that I am aware of. Theoretically, you could change the GUI, add any other functionality you want and you should be on your way.
You >>>
Could it use improvements in the way maybe it updates the GUI? Or maybe with the way it handles DTMF? Or playing WAV files?
<<< Support
GUI:
No improvements that I can think of.
Where .NET is concerned, the marshalling of GUI updated from worker threads over to the GUI thread using Form.InvokeRequired and Form.Invoke() or Form.BeginInvoke() is the most critical to get correct.
You do not want GUI updates to hold back the normal operarions of the media engine functions.
DTMF:
No improvements that I can think of.
The DTMF events for detection are very straight forward and are routed to per call worker threads for eventual processing. Pretty simple.
Wave file playback:
The approach the sample uses is typical.
The C# conference server app reads wave file data from disk and then plays the sample blocks out to callers via the phone line’s Tx IVR outputs. This is a typical thing to do.
The only place where this approach will start having issues is if the wave file sample block data cannot be read from disk and sent to the phone lines. This issue will eventually occur if the total number of lines is scaled up and the host hardware cannot handle the CPU load or disk I/O load.
The most obvious way to deal with bottlenecks is to memory cache wave file but that too will take away from process memory thus limiting the max number of total phone lines the app could scale to. Everything is a trade off.
You >>>
Is there anything in the ConferenceServer example app that you would not suggest we use in a production environment?
<<< Support
No.
However, you must be the final judge and make sure to test appropriately.
You >>>
Is there another example app that maybe uses a better approach in handling DTMF? Or playing or buffering WAV files? Or updating the GUI?
<<< Support
No.
Native code or .NET:
I’m an assembler and C/C++ guy. I develop all my hard core VOIP apps using C++. The main reason is for scalability and performance. When I develop VOIP apps, I try to get the most out of the underlying OS and hardware and do not want to worry if “anything else” is sitting in between my VOIP app and the OS. It’s tough enough to try to run “real time” VOIP apps on Windows. I try not to add more complexity to the mix. For me, less is more.
I am not saying “stay away from” .NET. On the contrary - the .NET technologies are useful and pretty cool. All I am saying is if you are contemplating developing a conference server that will have a high line density, I would think about staying with native code. That way YOU will be in full control of what goes on in your process space. It will be your app logic, the OS and the hardware – more than enough to worry about.
I hope this info is helpful.
Randal
|
| Back to Top |
|
| |
|
|
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: ConferenceServer Sample App for Production
