Hi Klaus,
Yes, I have learned that both are not to be used. However, I am unable to get the SDP to change with the force_rtp_proxy call. Can you see anything wrong with the way I am calling it? The call is clearly in effect, as it does change the media addresses, just not to what I need them to be. Even if I do specify them explicitly in the call.
Best regards, Örn
2009/10/15 Klaus Darilion klaus.mailinglists@pernau.at:
never call both functions. That will not work (you see the result)
when using the correct parameters (flags), force_rtpproxy() should be able to fix the SDP correctly
regards klaus
Örn Arnarson wrote:
Hi Klaus,
I've gathered as much; I'm able to bridge between the interfaces, but if I do that, I can't rewrite the SDP properly. I can only rewrite the SDP by using fix_nated_sdp. If I use fix_nated_sdp and the rtpproxy functions to bridge the call, the SDP gets messed up. E.g. I rewrite the media address with fix_nated_sdp from the public IP, 157.157.x.x to 10.252.1.8, but if I then call the force_rtp_proxy function, it just appends the public IP address directly behind the 10.252.1.8 IP address, so the SDP media address is now 10.252.1.8157.157.x.x.
Any ideas?
Regards, Örn
On Thu, Oct 15, 2009 at 12:30 AM, Klaus Darilion klaus.mailinglists@pernau.at wrote:
I think it is not about offer/answer, but you have to call rtpproxy* functions with the proper parameter to activate bridging inside rtpproxy.
E.g. there is an (I guess rather old) example for ipv4 to ipv6 bridging, but from the logic it should be similar to v4:v6 bridging:
http://openser.svn.sourceforge.net/viewvc/openser/trunk/modules/nathelper/ex...
Take a look at the i and e flag: http://kamailio.org/docs/modules/1.5.x/nathelper#id2468157
regards klaus
Joe Hart wrote:
Hi all,
For a project on which I'm currently working, I am having some problems figuring out how to correctly configure Kamailio to communicate with RTP Proxy in order to send media into and out of a network with private IP address ranges.
I have a proxy set up to send the SIP traffic, and all of this is working fine. However, I'm having some trouble getting the RTP Proxy set up. Currently, when the call is connected, the offer/answer is made and RTP Proxy seems to be taking over, but I'm having trouble getting my audio to flow in both directions.
Examination of the traffic coming into and out of this machine seems to indicate that the IP addresses aren't being mangled correctly. Specifically, it appears the internal IP address isn't being changed to reflect the IP address of the machine on which RTP Proxy is running, so that when the caller tries to send audio back, the IP it's given to reply to is 10.10.x.x, which obviously won't work.
I have tried experimenting with specifically setting IP addresses in the rtpproxy_offer() and _answer() methods to no avail, as well as setting various flags in those methods. However, I must admit that I'm not entirely sure what's happening under the hood with these methods, or what rtpproxy is doing with that information when it gets it. Rather than continue to hack at this by trial and error, I'm hoping someone here can point me in the right direction.
Any advice, example code or pep talks would be greatly appreciated.
Thanks in advance,
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users