| Author |
|
jmatthewsr
Junior
Joined: April 09 2008
Posts: 40
|
| Posted: April 09 2008 at 6:20pm | IP Logged
|
|
|
Is it possible to use only the media capabilites of the Voip Media Engine if I am running my own SIP stack? I noticed that the API's for conferencing reference SIP sessions. Would it be possible to add conferencing to my app if I am using my own SIP stack for signalling?
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 10 2008 at 8:50am | IP Logged
|
|
|
Hi Justin,
Thanks for posting to this forum.
You pose a very interesting issue. At the moment, all internal media related handling gets set up as the results of the media engine negotiating the call with the “far end” using the SIP protocol.
Technically what you describe is completely possible but the ability to use the media engine in the manner you describe is not exposed to the VOIP app via the media engine’s API.
If we were to support this new capability, we would need to develop a minimal “media only” API. It could be as simple as a few new API calls. If your SIP stack handles all issues associated with call setup and teardown in addition to hold/un-hold operations, the information from your SIP stack and call state handling code could be used to tell phone lines of the media engine how RTP media needs to be received/transmitted and in what rate/format. Once internal phone line logic is set up, the media engine could technically handle all your call media format/rate conversions and conferencing issues. We do not know the scope of your development or your project, but if this is a viable possibility for your team, then we would have to branch the current code base of the media engine and offer you this custom capability. We would have to do it for a fee or under a support contract. Have no clue at this time any time estimation on how long it would take to BETA this new capability.
Another very cheap (and possibly sleazy… :) ) way to accomplish similar behavior as described above would be to have your existing VOIP app handle all SIP issues as it normally does and have a media engine (that is built into your VOIP app) handle the actual call media (just like a stand alone conferencing or media server). In this case your app can handle all call setup and teardown, whatever, and simply act as an RTP data relay when calls are connected. Your app will relay calls to an internal media engine where all the full blown media handling capabilities will take place.
For example:
1)
Assume your app and your SIP stack receives an incoming call. You know the format and rate and the frame size of the call media from the INVITE SDP.
2)
Your app calls its internal media engine. Once the internal media engine answers the call, (which would be instantaneously) your app through its legacy SIP stack sends a “200 OK” back to the originator of the call. The call is now set-up and your VOIP app simply acts as a data relay for the call’s RTP media between the call endpoint and the internal media engine. Your VOIP app does not have to perform any processing of RTP media other than to relay RTP packets between the call endpoint and the internal media engine.
3)
Assume you receive another call (or you initiate another outgoing call to some location) using your legacy SIP stack. Once this second call gets connected, the internal media engine will have two phone lines active. To conference the 2 calls internally, your VOIP app would simply use the standard media engine conference APIs. You would also be able to take full advantage of each media engine phone line’s receive and transmit IVR APIs, full duplex call recording, etc….
The above would work out of the box and would require no custom media engine. The primary drawback (and it’s not a big drawback from a performance perspective) is the additional incremental CPU overhead of routing RTP call media through your local host’s network layer.
Support
|
| Back to Top |
|
| |
jmatthewsr
Junior
Joined: April 09 2008
Posts: 40
|
| Posted: April 10 2008 at 8:57am | IP Logged
|
|
|
Thanks. I was thinking along the same lines in the event that the media API was not exposed.
What I was thinking of doing was just creating a conference server and communicate to it from the "legacy" SIP stack (my app) and pass it a simple MSCML control and use the lanscape conference server as a stand-alone server with MSCML as the control protcol embedded in the SIP messages. This way there is no relay as you described below. My app would pass along the SDP to the conference server in the initial INVITE and re-INVITE the inbound leg to the conference server.
-justin
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 10 2008 at 9:42am | IP Logged
|
|
|
...that sounds like a reasonable approach. Great.
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Pre-Sales Technical Support
Topic: using only the media (rtp) stack
