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(a)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/e… >> >> >> 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(a)lists.kamailio.org >> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users >> >>

All I had to do was use force_rtp_proxy(). Everything was broken when I tried to use rtpproxy_offer/answer, though the code suggests they are just wrappers around force_rtp_proxy().

Klaus, It seems that force_rtp_proxy is removed in Kamailio 3.3 --- has there been a work-around for this bridge issue without using force_rtp_proxy? Sincerely, Brandon Armstead On Wed, Nov 4, 2009 at 5:46 AM, Klaus Darilion < klaus.mailinglists(a)pernau.at&gt; wrote: > > > Alex Balashov schrieb: > > That's pretty much what I did. >> >> All I had to do was use force_rtp_proxy(). Everything was broken >> when I tried to use rtpproxy_offer/answer, though the code suggests they >> are just wrappers around force_rtp_proxy(). >> > > > That's strange. I took a look at the code and these are really just > wrappers - fmro code point of view it looks fine. > > Do you have syslog traces? > > regards > klaus > > > > ______________________________**_________________ > Kamailio (OpenSER) - Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-**bin/mailman/listinfo/users<http://lists.… > http://lists.openser-project.**org/cgi-bin/mailman/listinfo/**users<http… > _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Daniel-Constantin Mierla wrote: > IIRC, I use: > > if(dst_ip==private_ip) > force_rtp_proxy("ocfaei"); > else > force_rtp_proxy("ocfaie"); > > rtpproxy started with: -l external_ip/private_ip > > Probably is rtpproxy 1.1 -- cannot check right now. I just tried this and it works, from the point of view of SDP. We were already able to obtain this result. The problem is that the actual rtpproxy does not seem to forward the packets that come into one interface toward the other, so no media is exchanged.