| Author |
|
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: October 03 2008 at 2:05pm | IP Logged
|
|
|
I would like to know if there's a way to stream the audio from the media engine to a remote system. There are two methods I would be interested in.
Method 1:
Stream incoming and outgoing data to a specific ip:port for pickup by an application (I haven't worked on yet).
Basically as a monitoring scenario, while a call is active. (For this method I wouldn’t need to stream any audio back into LS--at least not at this time).
Method 2:
Stream incoming audio to a specific IP:Port for pickup by an application (I haven't worked on yet) and receive audio for input to LS from that same IP.
This method could be used to handle a remote LS installation, where the person operating the call is working elsewhere.
I perceive method 2 would not be as easy to accomplish and it may end up being a wash. Regardless I'd like to hear your thoughts on this.
To be clear I'm not requesting any special development. These are just concept scenarios I'm considering. I think Method 1 should be somewhat doable, granted I'd have to build some audio receiver on the far end.
Do you happen to have any sample code (maybe for RawRtpCallback() ) that can duplicate or transmit the rtp data to a remote system? If not, how difficult do you think this would be and do you have any suggestions on how to accomplish it?
Environments
At this time we are using LS in a c++ environment. This may change to c# in the future. Regardless of this the monitoring application would be in c#.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: October 06 2008 at 12:29pm | IP Logged
|
|
|
Hi Fitz,
Thanks for waiting for this response.
What you want to do sounds very interesting. Call monitoring is something useful and occasionally we have gotten requests like yours. There are a couple of ways you could do all of this.
Method 1:
In the simplest case, you could grab the raw RTP media packets that the media engine will transmit. You can have your application access the raw RTP media packets using the EnableRawRtpPacketAccess() API procedure. Once your app gets “ready-to-be-transmitted” RTP packets from the media engine, you can pretty much do whatever you want with them. You could send them to any other UDP port yourself (using your own socket handling code) or simply send the RTP packets to some other IP:port using the SendUdpDatagram() API procedure. This scenario assumes you only want to “listen” to a phone conversation for monitoring purpose. You could enable/disable call monitoring at the media engine based app using SIP NOTIFY requests for example. The NOTIFY requests could contain the IP:port of where raw RTP would be forwarded. To do this, no mods to the media engine are required.
Method 2:
If you want to obtain full duplex voice capability between your monitoring app and your VOIP media engine based app, the easiest way would be to use the multi-session conferencing capability offered by the media engine. If you use conferencing to support your call monitoring, you will have full duplex voice capability and will be able to monitor and/or speak to any call endpoint. To do this, no mods to the media engine are required.
For example: Lets say your media engine based app (application A) is in a call and the call has been given a conference session ID (SetConferenceGroupIds () API proc) of your choosing and the call has been punched down into a conference session (ConferenceLine() API proc). Your call monitoring app could call your media engine based app (using SIP/RTP) on another reserved phone line any time and access the same conference session for the first call. Your monitoring app would be able to exchange full duplex audio with application A if it wanted. Depending on how you assign conference call IDs to calls on application A, you could monitor any number of calls at any one time.
If we needed to put together some form of example code for you, that would not be a problem. We have the base 16 hours of paid support for you each month so we would do it under that as much as we can.
Using the above conferencing capability, you could assemble a pretty cool call monitoring capability between your media engine apps, your IP PBX system and your call monitoring app. If we were to do call monitoring, we would lean toward this scenario.
As far as going with C#, that should not be a problem for your monitoring app. We tend to develop all of our VOIP apps using C/C+ jut because of the incredible performance (“bang for the buck”). If you want to develop an app and get the highest performance possible, stick with C/C++. If the VOIP app does not have a ton of concurrent calls on many phone lines and does not have to update GUI elements “too much”, then a C# or other managed code based app should be OK.
You >>>
Do you happen to have any sample code (maybe for RawRtpCallback() ) that can duplicate or transmit the rtp data to a remote system? If not, how difficult do you think this would be and do you have any suggestions on how to accomplish it?
<<< Support
We don’t have anything canned that we can send to you immediately. However, its very simple to do and we will gladly put something together for you. Event if we posted some simple pseudo code for you or code snippets, you will see how simple and easy it is to accomplish.
Note: We will be sporadically monitoring this support forum today. Back full time tomorrow and for the rest of this week.
Repost if more info is needed.
Support
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: October 31 2008 at 5:01pm | IP Logged
|
|
|
I’ve been given the go-ahead to pursue this further and use some of our development hours. I suppose it would definitely be a bit late to use any from October. However we can use up to eight of the hours for November to get this going to the next step.
What I’m looking for specifically:
I need some sample code for LS on how to broadcast audio data from one system to another. I would like one sample in c++ and one in c#. (Not full duplex, just as a monitoring scenario.) This would take the audio data from both sides of the conversation. It would be a large bonus if this could be in stereo, where one side of the conversation is right-channel while the other is on the left-channel. Perhaps the stereo audio could be a feature enhancement for the StartPhoneLineRecording function?
I would need some kind of receiving application in C# which would accept these data packets and play back the audio to a specific device or just the system default audio device. (A command line or dialog app would be fine.)
Please understand that my knowledge of audio programming/buffering is exceptionally limited. I have been successful in building an audio router/buffer from one audio device to another, however I had a bit of trouble keeping the delay from becoming greater and greater over time.
Thanks as always.
If you need further clarification just let me know.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: November 03 2008 at 11:18am | IP Logged
|
|
|
Hi Fitz,
The sample code you request will probably take a bit more than 8 hours to complete and test (just a gut feeling). Not exactly sure about the total time but we’ll work it out so we can both be happy. What we should probably do is split the difference with you and use a max of 8 hours from November support and 8 hours of the unused October support as a buffer. That way we will have more time to put together sample code that will be meaningful for your intended application. If we have to log a bit more time, the hourly rate we quoted your group is not too bad and we would surely welcome the additional work.
Implementing the monitoring app in C# if OK.
We would like to stay with a single language for the first cut of the monitored app if possible. The first cut could be C/C++ or C#... either language is not an issue. Just don’t want to make the same mistakes in two identical implementations. Probably better to do it in C# and then when we are all happy, grind the same thing out in C/C++. The actual language for the first cut can be your call.
About stereo: Not impossible but makes life harder. Lets hold off on this unless it is absolutely necessary. If you want stereo, then application level UDP network code may have to be used to transmit independent UDP media streams to the monitoring app. Likewise, the monitoring app will have to have its own media handling code for the separate streams. Need to defer additional thought on this unless this is a deal breaker.
There are issues we need to be aware of when wanting to monitor the audio of another app (user agent).
1)
Will all the monitored apps be in the same sub net as the monitoring app?
2)
Will NAT traversal be an issue in the deployment of the monitoring app and the monitored apps? In other words, will the monitored apps and the monitoring apps be in separate sub nest and/or separated by firewall/NAT router network elements?
We would like to keep these sample apps as simple as possible and use the media engines capability as much as possible. This means not duplicating network capable code in the application code. We will want to use the media engine’s native ability to transact RTP audio data with the monitoring app.
If we were going to create what you purposed and use it for a deployment, here is how we would approach it:
The monitored application:
1)
The monitored media engine app (monitored app) behaves as normal SIP/RTP endpoints. We will assume they can initiate and receive calls.
2)
Assume that monitored apps can have concurrent calls active.
3)
Monitored apps will be able to process SIP INFO requests that come from the monitoring apps. SIP INFO will be used to carry monitoring control information.
4)
All monitored audio will be accomplished using native media engine conferencing capability at the location of the monitored app. In other words, the monitored call endpoint and the third party of the call will have the full duplex call audio digitally mixed at the monitored call “node” and this mixed audio will then be transmitted to the monitoring app via normal RTP media stream between the monitored app and the monitoring app.
5)
The monitored app will support the needed monitor capability and not require any user intervention (fully transparent monitoring).
The monitoring application:
1)
This monitoring app will be able to call any endpoint that can be monitored. The INVITE request being received by the monitored endpoint will contain a custom SIP header (“x-Monitoring-Call:”) so that the monitored app knows the call is coming from a monitor app.
2)
Calls that are answered by the monitored endpoints will not be presented to the user (no incoming phone ring, etc). Instead, they will be answered automatically by the monitored app.
3)
When the call automatically gets answered by the monitored app, the monitored app will send the monitoring app a SIP INFO message. The contents of the INFO message will be proprietary content for this app. The INFO message will contain current call session info (calls that can be monitored). The monitoring app can use this info to display what call sessions can be monitored.
4)
If at any time, call sessions change at the monitored app while a call session from the monitoring app is still active, the monitored call endpoint will update the monitoring app’s session information by sending the monitoring app a SIP INFO with updated call session info.
5)
At any time the monitoring app can send the monitored app a SIP INFO message that either starts a call monitoring operation or stops a call monitoring operation.
That’s about it. Using the above framework would give a pretty flexible architecture. It would also allow the monitoring app to listen in on multiple calls all at the same time. Not that it would be terribly useful, but the monitoring app could listen to call media from different monitored apps all at the same time too.
Fitz, if you can repost with your comments in case we have totally missed the boat on this one, please do so.
We have assumed that you want to deploy your monitoring apps anywhere and your monitor apps anywhere regardless of NAT or firewall network elements. If your deployment is completely in the global IP address space or completely in a single private sub net. Then other possibilities exist too.
Note that the above descriptions use SIP INFO messages. We can also use the media engines ability for SUBSCRIBE/NOTIFY. Minor detail.
Thanks,
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: November 03 2008 at 4:07pm | IP Logged
|
|
|
I can see several undesirable limitations to your proposal. I had hoped for a stripped down scenario with streaming audio data. (I certainly understand not desiring to duplicate audio streaming code that already exists.)
I have had some time to think it through, I see just as many, if not more possibilities with your proposal. We might be able to use it in other environments/scenarios though (if I understand correctly) it requires both of the phone lines we have licensed in LS.
Tutorial language (c++ vs C#):
I would prefer the C# tutorials first. Though we would only be interested in the c++ tutorial in the monitored application as an end result. (The C# tutorial on the monitored application may prove to be intuitive enough to convert the C# logic to c++ w/o the need for additional tutorial.)
Your proposal to use 8 hrs from unused time from Oct as well as up to 8 hrs from Nov is agreeable.
To answer your questions regarding the network:
You
1) Will all the monitored apps be in the same sub net as the monitoring app?
Us
1) Not always. The networks *could* be on the same subnet, but we also have a WAN with many different subnets. These subnets are separated by routers, but not firewalls.
You
Will NAT traversal be an issue in the deployment of the monitoring app and the monitored apps? In other words, will the monitored apps and the monitoring apps be in separate sub nest and/or separated by firewall/NAT router network elements?
Us
2) Initially NAT traversal shouldn't be an issue as these are all internal networks. However, if it's not too difficult, NAT traversal would be beneficial as it would allow for a wider deployment (i.e. a quality assurance monitor has to work from home due to a sick child).
Something else to keep in mind:
Because this is (initially) for monitoring purposes we would like the ability to enable/disable any audio from the monitoring app from reaching the monitored application.
Side effect/feature question:
If the agent on the monitored application is not currently on an active call, would the scenario you propose allow for the monitoring agent to communicate with the monitored agent? (This is a question of curiosity and not a request for a feature.)
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: November 04 2008 at 7:08am | IP Logged
|
|
|
Hi Fitz,
Thanks for the feedback. Whatever we do for the sample code, it’s completely your call. We want to provide you with the sample code that will fit your situation and be of some benefit. We don’t want to insist on a certain implementation or set of functionality. Take all of our suggestions as “thinking out loud”.
I think we should have a quick call sometime today if you want. You can call me any time and we can discuss further. I will send you via email the SIP URI I can be reached at.
You >>>
I can see several undesirable limitations to your proposal. I had hoped for a stripped down scenario with streaming audio data. (I certainly understand not desiring to duplicate audio streaming code that already exists.)
<<< Support
Sounds like we missed the boat a bit with our last response. Please help us understand the limitations you see and we will correct our thinking.
You >>>
I have had some time to think it through, I see just as many, if not more possibilities with your proposal. We might be able to use it in other environments/scenarios though (if I understand correctly) it requires both of the phone lines we have licensed in LS.
<<< Support
What we hoped to purpose was a completely generic monitoring app capability that could be deployed to any VOIP domain/realm. We were thinking completely generic when we posted the last info. I understand your question: Yes, a monitored app would at least require 2 phone lines minimum.
You >>>
I would prefer the C# tutorials first. Though we would only be interested in the c++ tutorial in the monitored application as an end result. (The C# tutorial on the monitored application may prove to be intuitive enough to convert the C# logic to c++ w/o the need for additional tutorial.)
<<< Support
OK. Both sample apps (a monitored app and a monitoring app) will both be done in C# initially. That sounds good. To transition the logic of the monitored C# app to C/C++ won’t be difficult. We will assist if required.
You >>>
Because this is (initially) for monitoring purposes we would like the ability to enable/disable any audio from the monitoring app from reaching the monitored application.
<<< Support
Not a problem.
You >>>
If the agent on the monitored application is not currently on an active call, would the scenario you propose allow for the monitoring agent to communicate with the monitored agent? (This is a question of curiosity and not a request for a feature.)
<<< Support
Yes, full duplex audio exchange with the monitored app can be done. Good question.
Repost with any further info. If we come into agreement on how the monitored app and the monitoring app behaves, we will try to get this going yet this week.
Thanks Fitz,
Randal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: November 20 2008 at 10:41am | IP Logged
|
|
|
Hi Fitz,
Wanted to give you an update as to the progress of the sample code we owe you.
We have completed the release of v6 media engine and have started putting in the required changes that will allow us to develop the monitoring app as we discussed via the VOIP support phone call a while ago.
We regret the delay in getting to your request but we want to be able to hand off to your group the new Release 6 media engine with the new C# monitoring app sample and the C# monitored app sample. We appreciate your patience so when required we will upgrade your group’s current VOIP Media Engine code and license for free.
We are currently working on the sample code we promised you. We want to get this to you before the Thanksgiving break next week. Then we can start to tackle the multi-proxy support. I will keep this thread updated as we progress…
Please pass this info along to Greg if you can.
Thanks much,
Randal
|
| Back to Top |
|
| |
gcamp0730
Intermediate
Joined: June 12 2006
Location: United States
Posts: 35
|
| Posted: November 20 2008 at 10:43am | IP Logged
|
|
|
Randal,
Thanks for the update!
Greg.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: December 01 2008 at 2:34pm | IP Logged
|
|
|
Hi Greg + Fitz,
We are back from Thanksgiving break. We tried like hell to release the C# monitoring/monitored sample app code to you before the end of last Wednesday but we fell short with time. I wanted to let you know that we are working on it again today and whatever time it takes this week. Getting this sample code to you is top priority at the moment. It has taken longer (as usual) and to get a good implementation of this call model, we added a few updates to the media engine to make the sample app R+D easier/cleaner.
What we decided to do is take the sample 2 line C# soft phone code that comes with the Release 6 media engine distribution and modify that accordingly so that it shows how an app can perform call audio monitoring and how an app can be monitored. It looks good. The sample C# code should really make life easier at your end. At this point, we are eating the cost overrun associated with the sample code development. And are not looking to doc any pre-paid support hours. We will need your December support hours for the multi proxy/registrar working coming up.
We are planning to go full tilt on the multi-proxy/registrar issue later this week or at the latest the start of next week. I will have to talk to you (Greg) to formulate the work schedule because I am pretty sure we won’t be able to get multi proxy/registrar out in 2 days. It means us deciding on the appropriate number of billable hours in excess of December’s enhanced support.
Ping us in the meantime if any question exist.
Thanks guys,
Randal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: December 09 2008 at 11:22am | IP Logged
|
|
|
Hi Greg + Fitz,
Quick update:
We have the C# monitoring/monitor app sample code just about complete. All I have to do is add a bit of logic to handle the GUI call hold and conference buttons. After that, I need to generate a quick “Application Note” type document and then I should be able to pass this sample C# code off to you.
The docs will be important and will help describe the approach I took to implement the call monitoring app and the call monitored app. Its simple and clean. Its taking longer because I did not want to create a sample app that relies on hacks. The media engine actually required two subtle changes to make things a lot cleaner.
You should be able to take all the logic out of the sample C# app and use it in all your source code. Simpler yet, you may just want to use the sample code with a few GUI updates and you will have your monitoring app ready to go. You will still have to port over the logic from the sample C# code to your media engine “agent station” apps that will allow your agent station calls to be monitored remotely.
I regret the delay….
Randal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: December 12 2008 at 3:57pm | IP Logged
|
|
|
Hi Greg, Hi Fitz,
The first cut of the monitor/monitoring C# soft phone sample app is ready. It’s a single soft phone app that can be used as a monitoring soft phone as well as a monitored target soft phone.
This sample will allow you to test and perform half duplex and full duplex call monitoring. The sample uses the powerful conferencing capabilities of the media engine, SUBSCRIBE and NOTIFY SIP message handling for call information passing and RFC2833 out-of-band DTMF signaling between the master (monitoring app) and the target (monitored) app for transporting monitoring commands between the master and the target soft phones. Nice.
What you can do to get started is build the sample (VS2008 project) and then put the sample monitoring soft phone on two different machines to check out its capabilities.
Using two of the sample apps (optionally configured to use your own SIP proxy), you can set one up as a master (monitoring) app and one up as a slave target soft phone.
From the master soft phone, call the target soft phone. On the master soft phone you can select via the GUI half or full duplex call monitoring of any phone line on the call target. The master has two general purpose lines so you can even monitor two different target soft phones at the same time using different duplex modes. The sample can work with 2 line or higher VOIP Media Engines.
This sample app requires media engine v6.0.0.4. The reason is because I needed to add two additional features to the media engine to make the monitoring soft phone cleaner. One required feature that was added is the ability to disable incoming phone ringing on a per call basis when a new call is being received. The second added feature allows incoming individual DTMF digits to be muted for any call so that received DTMF digits are not played back on local multimedia hardware when they are received by the target soft phone. The reason for these two feature additions will become clear when you read the application note that comes along with the sample application C# code and tool at the source code.
This sample app took way too much time. I new the media engine would have no problem handling the requirements of a monitored/monitoring app using the power of the conferencing capability and its other functionality. I just made a bad error/mistake when I estimated the amount of time to implement it. I have about two weeks into this thing.
Login to your support FTP account and download the following:
Sample C# source code:
Monitoring SoftPhone Sample .zip
V6.0.0.4 media engine engineering release:
VOIP Media Engine Engineering Release v6.0.0.4 Expires 1-31-09.zip
Fitz, repost to this thread if I have missed something or if something is not right. You can use your license files from the "Engineering Update v5.12.8.7" image you should have. This app has been quickly tested. I you see something that is erroneous, shout loud.
Greg, I’m going to send you an offline email with some other info that is important – probably on Monday. We are laying the plans for the multi-proxy/registrar support. I want to get this completed before the end of December if possible. We will have to see how it goes. Unfortunately your December 1 start date for this has come and gone. Nothing I can do but keep moving forward.
Thanks,
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: December 18 2008 at 3:49pm | IP Logged
|
|
|
Merry Christmas and thank you for the sample monitor code.
Unfortunately I'm experiencing some problems getting this to run.
After updating to LS 6.0.0.4, updating the Working Directory, updated the LM Reference in the Solution Explorer and created a "successful" build.
I attempted running the app in VS 2008. I received an unhandled exception of type 'System.IO.FileLoadException' at Application.Run(new MainAppForm()); in Programs.cs.
Quote:
An unhandled exception of type 'System.IO.FileLoadException' occurred in MultiLine Phone with monitoring.exe
Additional information: Could not load file or assembly 'LMEVoipManaged, Version=6.0.3268.25660, Culture=neutral, PublicKeyToken=null' or one of its dependencies. ...
|
|
|
I tried again after adding a Reference Path to LM VoIP and putting LM's dll and library there just in case. The results were the same.
Any suggestions?
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: January 06 2009 at 8:41am | IP Logged
|
|
|
Do you have any feedback on this?
Thanks.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: January 06 2009 at 12:00pm | IP Logged
|
|
|
Hi Fitz,
Thanks for pinging this thread. I did not see your December 18th post until just now. We had a recent issue where emails from our hosting provider were lost for 2 days. I bet you got lost in the shuffle somehow.
I will read your post and respond shortly. Hang on…
Randal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: January 06 2009 at 12:13pm | IP Logged
|
|
|
Hi Fitz,
In the future, if we do not respond to your posts quickly (response time is typically much less than 24 hrs and probably no more than 48 hours worst case), make sure to send an email to “support group” to make sure we have detected your post. Normally response time is short and everything is pretty smooth.
OK…
Are you building with VS2008 or “VS2008 SP1” ?
I bet you have to install VS2008 SP1 for your VS2008 environment. Release 6 media engine is built using VS2008 SP1 tool chain. See the following post for more info:
Distributing Release 6 .NET VOIP applications:
http://www.lanscapecorp.com/forum/forum_posts.asp?TID=546&PN =1
Also note that the VS2008 SP1 redist package will also have to be deployed on all your target machines that run your VOIP app.
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: January 07 2009 at 9:46am | IP Logged
|
|
|
Thank you for your reply Randal.
I was beginning to wonder about the response. Figured it was a technical glitch or the Holidays. LS's response rate is typically as quick as newegg.com's standard shipping and handling (i.e. exceptionally fast).
Though this project will be in the works shortly, we will be busy working on integration/full testing of all aspects of our product and the non-time bombed LS Engine we've recently received. We will be back on this project after proven integration and successful roll-out.
I'll keep in mind contacting the "support group" in the unlikely event of a dead/unanswered thread.
Thanks as always and hope you guys had a great Holiday,
Fitz
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: January 07 2009 at 11:23am | IP Logged
|
|
|
OK, Good show...
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: Streaming Audio
