| Author |
|
hermes
Junior
Joined: October 27 2006
Posts: 64
|
| Posted: October 22 2007 at 10:37am | IP Logged
|
|
|
I am trying to optimize the bandwidth consumed by my SIP phone. This phone only receives voice and never sends voice. So with the help of the RtpCallback procedure I capture RTP packets and when the TransmittingPacket field is not 0 I set ProcessRtpPacket field to 0. At this moment, RtpCallback is never called. What is happening?
Thank you very much.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: October 22 2007 at 11:36am | IP Logged
|
|
|
Hi hermes
Hmmm….. Your explanation is a bit confusing to us. It sound as if your app is having its “RTP callback” proc called OK.
If your app wants to “intercept” or “dump” received or transmitted RTP media packets for any phone line, your app must call the EnableRawRtpPacketAccess() API procedure for each phone line. One of the parameters for the API procedure is the address of a callback procedure. This callback procedure will be called for all transmitted and received RTP packets for the phone line.
If you want to have the media engine ignore any RTP packets, just set the ProcessRtpPacket member of the RAW_RTP_DATA struct to zero (FALSE). If you do this, the media engine will toss out the received RTP media packet or it will toss out the ready-to-be-transmitted RTP media packet.
Please repost additional information that describes your problem in more detail.
Thanks,
Support
|
| Back to Top |
|
| |
hermes
Junior
Joined: October 27 2006
Posts: 64
|
| Posted: October 22 2007 at 4:30pm | IP Logged
|
|
|
Hello,
my RTP callback procedure works correctly because I´m encrypting and decrypting voice and it works sucessfully, but when I intercept a transmitted RTP media packet and set ProcessRtpPacket member of the RAW_RTP_DATA struct to 0 this callback isn´t called anymore.
I´ve noticed this entry in Media Proxy log:
Code:
Media session created (audio). Media Port: 9001, Call Id: 93578eee-8f29-474d-8964-41558da9b7ec-000006a8@192.168.1.71
Media stream active (audio). Media Port: 9001, Call Id: 93578eee-8f29-474d-8964-41558da9b7ec-000006a8@192.168.1.71
--------------------------------- Media Port Allocated ----------------------------(9001)
Src UA(192.168.1.71:9000) <===> MediaProxy(192.168.1.25:9001) <===> Dest UA(192.168.1.43:9000)
Local RTP media synchronization applied.
Media session closed due to inactive media stream (audio). Media Port: 9001, Call Id: 93578eee-8f29-474d-8964-41558da9b7ec-000006a8@192.168.1.71
|
|
|
Do you have any suggestions?
Thanks
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: October 23 2007 at 7:34am | IP Logged
|
|
|
Hermes,
Thanks for the additional information. Now it is clear – we now understand what you are saying.
In the current version of the VOIP Media Engine we verified that toggling the ProcessRtpPacket value in the RAW_RTP_DATA struct works as expected.
We see that you are running version v5.12.3.10. It is possible that there was a bug in that version than would explain what you are seeing.
It would be good to get you updated to the current v5.12.7.15 version and go from there. Without a doubt, there are many improvements in the current product image that you do not have. We can get you a temporary product image that you could test with and use for evaluation if you want. You will have to rebuild you test apps against the updated DLL/API. A few modest API changes but not a big deal.
You are a good customer and we would like to have you enter into a support agreement with us so that we may offer you improved software as it is made available. I know we have talked about this previously and would still like to pursue this with you. Support rates have been reduced by 50% since we last talked about it. A support package would allow us to freely work together and offer you immediate fixes and updates. It makes everything simple. Support contracts are meant to make life easier for you and us. We just want to be fair – that’s all.
The other option is to for you to purchase individual product upgrades at our next release. If you want to hammer out the details of a support contract – we can work with you to tailor a support package to your specific needs. Contact Randal Ziegler for further information. You should already have his contact info.
The next substantial release of the VOIP Media Engine package is coming. The plan is to release it yet this year.
Support
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 21 2008 at 5:25pm | IP Logged
|
|
|
Hi hermes,
Media Engine Update:
We are completing work on what we are going to consider final v5 updates before we start developing and releasing upcoming v6 product. We would like you to briefly test your VOIP application(s) using the current v5 image. Our notes indicate that you have a “timed development version” of the media engine that will require updating soon.
Please see your support FTP account directory “v5.12.8.1 DLL Only”. It contains a timed image of the media engine you should use for your final development and testing. Download the image. Unzip it and use the new files LMEVoip.lib, LMEVoip.dll, LMEVoipManaged.dll and SipTelephonyApi.h to overwrite your existing files. There is also an updated developer reference you should also use.
We will officially update you before this latest image times out. Read the Engineering notes that come with the distribution for the changes. You will want to run this version of the media engine with your app. Really, check out the engineering notes that come with the ZIP image. If this image looks good, we will cut you an official release any time.
Any questions, please post back to the support forum.
Support
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: RTP callback problem
