| Author |
|
jmatchet
Intermediate
Joined: November 16 2009
Location: United States
Posts: 2
|
| Posted: November 16 2009 at 4:28pm | IP Logged
|
|
|
I have a radio Receiver and Radio transmitter that understand RTP but not SIP. How do I use Lanscape software to open two rtp streams from a PC;1
stream to the receiver to play received rtp audio packets, and the other stream to the Transmitter which will take mic input and put it into RTP packets to send to the IP address of the tranmitter radio. All this needs to be without SIP since my radios dont understand SIP.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: November 17 2009 at 8:15am | IP Logged
|
|
|
Hi John,
Thanks for your post.
The current v6.0.0.16 media engine can allow your VOIP application to do what you describe. To accomplish the exchange of Tx and Rx RTP packets to your remote radio gear only using RTP, your VOIP app will have to use at least a two line media engine.
I assume you are developing using C/C++ language but the .NET logic would be the same for what I will tell you below.
To summarize, what will happen is this:
1)
Your VOIP app will minimally use a 2 line media engine. Two lines are used because your VOIP app will basically call itself.
2)
Before making a phone call, your VOIP app will have to register an RTP media callback procedure for the media engine phone lines. This callback will allow your VOIP app to managed ready to be transmitted RTP packets. This ability will be needed in order to properly forward Tx RTP packets to your remote radios.
3)
Your VOIP app will have to handle the SipReceivedRtpMediaConflict immediate event in the main media engine event callback your app will support. When your app handles this event, it has the ability to tell the media engine to accept received RTP packets from your remote radio gear. Your app has to handle this event from the media engine because the SIP call will negotiate a media ip:port that is different from the ip:port that your radios use when they send their RTP to your VOIP app. More on this later.
3)
Now we can start talking about placing a call to your radio gear:
The VOIP app will place a SIP/RTP call to itself using the RTP media codec that your remote radio requires. Because the media engine is basically calling itself, this will handle all the SIP call setup and teardown for the call.
4)
Your VOIP app will detect that there is an incoming call and answer it. This will represent the completion of the call setup and fulfill any SIP requirements the media engine has.
5)
When the media engine tries to transmit an RTP packet, your RTP media callback procedure (from step 2 above) will be executed. In this procedure, your app logic will intercept the ready to be transmitted RTP packet and send it directly to your remote radio gear using the SendUdpDatagram() API procedure the media engine supports. You can specify the destination host and port when you call the SendUdpDatagram() API procedure. The final thing to do when your callback is executed is to inform the media engine to ignore the ready to be transmitted RTP packet by setting a callback variable that your app will have access to. Doing all of the above will ensure all RTP media packets being transmitted by the media engine will arrive at your remote radio gear.
6)
When the media engine receives RTP packets from your remote radios, the media engine will detect that the RTP came from an ip:port that is different from what was specified in the call setup. You can tell the media engine to use this received RTP by handling the media engine SipReceivedRtpMediaConflict immediate event in the main media engine event callback your app will support. In this event handler, you basically tell the media engine that it is ok to accept the RTP coming from your remote radio gear and to process the received RTP as normal. Doing all of the above will allow you to receive all RTP media from your remote radios.
7)
Your VOIP app transacts RTP with your remote radio gear for as long as it wants.
8)
When you no longer need to exchange RTP media with your radio gear, your VOIP app will terminate the call by simply calling the TerminateCall() API procedure. Calling this proc will tear down the call using SIP and the call will be complete.
If all of the above seems like a lot of work, it really isn’t. Using the above approach really is simple. In addition, when your VOIP app uses the media engine, it also has the ability to support RTP interaction with many remote radios that are deployed – all at the same time.
I hope this description has helped you and has shed some light on the possibilities you have when selecting the VOIP Media Engine.
Thank you John,
Randal
|
| Back to Top |
|
| |
jmatchet
Intermediate
Joined: November 16 2009
Location: United States
Posts: 2
|
| Posted: November 18 2009 at 8:07am | IP Logged
|
|
|
Wont I need 4 lines. 1 pair for the transmitter and the other for the receiver..(also the transmitter is bidirectional, since it sends sidetone back to the speakers ear)
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: November 18 2009 at 10:05am | IP Logged
|
|
|
Hello John,
Ahh... I understand what you are saying. You are correct!
Randal
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Pre-Sales Technical Support
Topic: VOIP to NON-SIP Device RTP only?
