<div dir="ltr">Hi Razvan,<br><br>Thanks for your replies but i figured that i was using wrong flags along with ie. Its working fine after fixing the flags.<br><br>Regards,<br>Qasim<br></div><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Fri, May 10, 2013 at 2:13 PM, Răzvan Crainea <span dir="ltr">&lt;<a href="mailto:razvan@opensips.org" target="_blank">razvan@opensips.org</a>&gt;</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>
I am not sure what&#39;s your problem then. Are you saying that the SDP is properly changed for both Invite and 200 OK? Can you send a trace? Or at least explain exactly how each message (INVITE and 200 OK) is sent out by OpenSIPS.<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/10/2013 06:41 AM, <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">
Yes exactly that is being done perfectly but what i want to do is to<br>
handle NAT on client&#39;s end. The IP of client that comes in the SDP&#39;s c=<br>
param is his local IP address and rtpproxy swaps that IP with server&#39;s<br>
local IP but on the other way arround it tries to send the IP back to<br>
client&#39;s local IP address which is not visible to server.<br>
<br>
Actually we have two nated acenerios. One on the server end and the<br>
other on the client&#39;s end.<br>
<br>
Regards,<br>
Qasim<br>
<br>
<br>
On Thu, May 9, 2013 at 5:59 PM, Răzvan Crainea &lt;<a href="mailto:razvan@opensips.org" target="_blank">razvan@opensips.org</a><br></div><div class="im">
&lt;mailto:<a href="mailto:razvan@opensips.org" target="_blank">razvan@opensips.org</a>&gt;&gt; wrote:<br>
<br>
    Hi, Qasim!<br>
<br></div><div class="im">
    Basically this is what the rtpproxy module does: when you call<br>
    rtpproxy_offer(&quot;ei&quot;) function, opensips tells the rtpproxy server<br>
    that a new session has to be created and the media flow will be from<br>
    external to internal. Rtpproxy assigns the proper interface(IP) and<br>
    port and returns them to OpenSIPS, which advertises in the ongoing<br>
    INVITE. So, considering the rtpproxy server has been configured<br>
    correctly, all you have to do is call rtpproxy_offer() with the<br>
    proper direction.<br>
<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 &lt;<a href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-<u></u>solutions.com</a>&gt;<br>

<br>
    On 05/09/2013 02:54 PM, <a href="mailto:qasimakhan@gmail.com" target="_blank">qasimakhan@gmail.com</a><div class="im"><br>
    &lt;mailto:<a href="mailto:qasimakhan@gmail.com" target="_blank">qasimakhan@gmail.com</a>&gt; wrote:<br>
<br>
        Hi Razvan,<br>
<br>
        My scenerio is like this<br>
<br>
        Client &lt;-------&gt; NAT &lt;-------&gt; OpenSIPs/RTPProxy &lt;-------&gt; Client<br>
<br>
<br>
        in this scenerio left side of OpenSIPs is public side and the<br>
        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<br>
        after<br>
        hearing about problems in engage_rtpproxy in brigding mode. Now<br>
        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<br>
        &lt;<a href="mailto:razvan@opensips.org" target="_blank">razvan@opensips.org</a> &lt;mailto:<a href="mailto:razvan@opensips.org" target="_blank">razvan@opensips.org</a>&gt;<br></div><div><div class="h5">
        &lt;mailto:<a href="mailto:razvan@opensips.org" target="_blank">razvan@opensips.org</a> &lt;mailto:<a href="mailto:razvan@opensips.org" target="_blank">razvan@opensips.org</a>&gt;&gt;&gt; wrote:<br>
<br>
             Hi, Qasim!<br>
<br>
             There are two problems with your approach: the first one is<br>
        that you<br>
             are using the engage_rtp_proxy() function in a bridging mode<br>
             scenario. The behavior of this is undefined, because the<br>
        rtpproxy<br>
             module cannot fully determine your scenario (for example<br>
        what&#39;s the<br>
             direction of the media flow in the reply). That&#39;s why you<br>
        should use<br>
             the rtpproxy_offer() and rtpproxy_answer() functions to<br>
        explicitly<br>
             indicate the direction in INVITE and replies.<br>
             The second problem is that you try to change the SDP twice:<br>
        first by<br>
             the fix_nated_sdp() and then by engage_rtp_proxy(). These<br>
        changes<br>
             confuse OpenSIPS, who tries to apply both of them. Try to<br>
        use only<br>
             one. My suggestion is to rtpproxy_offer/answer() to fix the<br>
        SDP,<br>
             without calling fix_nated_sdp().<br>
<br>
             Best regards,<br>
<br>
             Razvan Crainea<br>
             OpenSIPS Core Developer<br>
</div></div></blockquote>
<br><div class="HOEnZb"><div class="h5">
______________________________<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>