<div dir="ltr"><div><div><div>Yes exactly that is being done perfectly but what i want to do is to handle NAT on client's end. The IP of client that comes in the SDP's c= param is his local IP address and rtpproxy swaps that IP with server's local IP but on the other way arround it tries to send the IP back to client's local IP address which is not visible to server. <br>
<br></div>Actually we have two nated acenerios. One on the server end and the other on the client's end.<br><br></div>Regards,<br></div>Qasim<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 9, 2013 at 5:59 PM, Răzvan Crainea <span dir="ltr"><<a href="mailto:razvan@opensips.org" target="_blank">razvan@opensips.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, Qasim!<br>
<br>
Basically this is what the rtpproxy module does: when you call rtpproxy_offer("ei") function, opensips tells the rtpproxy server that a new session has to be created and the media flow will be from external to internal. Rtpproxy assigns the proper interface(IP) and port and returns them to OpenSIPS, which advertises in the ongoing INVITE. So, considering the rtpproxy server has been configured correctly, all you have to do is call rtpproxy_offer() with the proper direction.<div class="im">
<br>
<br>
Best regards,<br>
<br>
Razvan Crainea<br>
OpenSIPS Core Developer<br>
<a href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-solutions.<u></u>com</a><br>
<br></div><div class="im">
On 05/09/2013 02:54 PM, <a href="mailto:qasimakhan@gmail.com" target="_blank">qasimakhan@gmail.com</a> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Hi Razvan,<br>
<br>
My scenerio is like this<br>
<br>
Client <-------> NAT <-------> OpenSIPs/RTPProxy <-------> Client<br>
<br>
<br>
in this scenerio left side of OpenSIPs is public side and the right side<br>
is on private network. Secondly i have tried using<br>
rtpproxy_offer/answer() but the same problem. I will try using<br>
rtpproxy_offer/answer() again in a bit more detail now specially after<br>
hearing about problems in engage_rtpproxy in brigding mode. Now can you<br>
point me how i can achieve nat handling in rtpproxy module?<br>
<br>
Regards,<br>
Qasim<br>
<br>
<br>
On Thu, May 9, 2013 at 5:39 PM, Răzvan Crainea <<a href="mailto:razvan@opensips.org" target="_blank">razvan@opensips.org</a><br></div><div class="im">
<mailto:<a href="mailto:razvan@opensips.org" target="_blank">razvan@opensips.org</a>>> wrote:<br>
<br>
Hi, Qasim!<br>
<br>
There are two problems with your approach: the first one is that you<br>
are using the engage_rtp_proxy() function in a bridging mode<br>
scenario. The behavior of this is undefined, because the rtpproxy<br>
module cannot fully determine your scenario (for example what's the<br>
direction of the media flow in the reply). That's why you should use<br>
the rtpproxy_offer() and rtpproxy_answer() functions to explicitly<br>
indicate the direction in INVITE and replies.<br>
The second problem is that you try to change the SDP twice: first by<br>
the fix_nated_sdp() and then by engage_rtp_proxy(). These changes<br>
confuse OpenSIPS, who tries to apply both of them. Try to use only<br>
one. My suggestion is to rtpproxy_offer/answer() to fix the SDP,<br>
without calling fix_nated_sdp().<br>
<br>
Best regards,<br>
<br>
Razvan Crainea<br>
OpenSIPS Core Developer<br></div>
<a href="http://www.opensips-solutions." target="_blank">http://www.opensips-solutions.</a><u></u>__com <<a href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-<u></u>solutions.com</a>><div class="im">
<br>
<br>
<br>
On 05/09/2013 02:33 PM, Nick Khamis wrote:<br>
<br>
It's not a bug, many of us here use RTP proxy in the same scenario.<br>
Can you please provide a sip trace using ngrep<br></div>
(<a href="http://wiki.freeswitch.org/__wiki/Packet_Capture" target="_blank">http://wiki.freeswitch.org/__<u></u>wiki/Packet_Capture</a><br>
<<a href="http://wiki.freeswitch.org/wiki/Packet_Capture" target="_blank">http://wiki.freeswitch.org/<u></u>wiki/Packet_Capture</a>>). Secondly,<div class="im"><br>
post the<br>
relevant far end nat related scripting please.<br>
<br>
<br>
Nick.<br>
<br></div>
On 5/9/13, <a href="mailto:qasimakhan@gmail.com" target="_blank">qasimakhan@gmail.com</a> <mailto:<a href="mailto:qasimakhan@gmail.com" target="_blank">qasimakhan@gmail.com</a>><div class="im"><br>
<<a href="mailto:qasimakhan@gmail.com" target="_blank">qasimakhan@gmail.com</a> <mailto:<a href="mailto:qasimakhan@gmail.com" target="_blank">qasimakhan@gmail.com</a>>> wrote:<br>
<br>
Hi,<br>
<br>
I am facing a problem when a client connects to opensips<br>
from NATed<br>
network. I am using rtpproxy in bridging mode i.e. from<br>
publicnetwork to<br>
private network. When i use fix_nated_sdp function from<br>
nathelper the local<br>
IP address of the caller is replaced by its public IP but<br>
the problem<br>
starts when i use engage_rtp_proxy instead of replacing<br>
server's public ip<br>
to private it embeds private ip after the caller's publicIP like<br>
X.X.X.XY.Y.Y.Y. I have tried fix_nated_ip with flag 3 and<br>
engage_rtp_proxy<br>
with flag rie.<br>
<br>
The question is am i using something wrong here or should it<br>
be counted as<br>
a bug.<br>
<br>
If you want some more clarification can draw a flow diagram<br>
also.<br>
<br>
Regards,<br>
Qasim<br>
<br>
<br></div>
______________________________<u></u>___________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a> <mailto:<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.<u></u>org</a>><br>
<a href="http://lists.opensips.org/cgi-__bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-<u></u>__bin/mailman/listinfo/users</a><br>
<<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/<u></u>cgi-bin/mailman/listinfo/users</a><u></u>><br>
<br>
<br>
______________________________<u></u>___________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a> <mailto:<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.<u></u>org</a>><br>
<a href="http://lists.opensips.org/cgi-__bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-<u></u>__bin/mailman/listinfo/users</a><div class="im"><br>
<<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/<u></u>cgi-bin/mailman/listinfo/users</a><u></u>><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-<u></u>bin/mailman/listinfo/users</a><br>
<br>
</div></blockquote><div class="HOEnZb"><div class="h5">
<br>
______________________________<u></u>_________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-<u></u>bin/mailman/listinfo/users</a><br>
</div></div></blockquote></div><br></div>