[OpenSIPS-Users] RTPProxy for users behind NAT.

[Răzvan Crainea]

Hi, Qasim!

I am not sure what'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.

Best regards,

Razvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 05/10/2013 06:41 AM, qasimakhan at gmail.com wrote:
> 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.
>
> Actually we have two nated acenerios. One on the server end and the
> other on the client's end.
>
> Regards,
> Qasim
>
>
> On Thu, May 9, 2013 at 5:59 PM, Răzvan Crainea <razvan at opensips.org
> <mailto:razvan at opensips.org>> wrote:
>
>     Hi, Qasim!
>
>     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.
>
>
>     Best regards,
>
>     Razvan Crainea
>     OpenSIPS Core Developer
>     http://www.opensips-solutions.__com <http://www.opensips-solutions.com>
>
>     On 05/09/2013 02:54 PM, qasimakhan at gmail.com
>     <mailto:qasimakhan at gmail.com> wrote:
>
>         Hi Razvan,
>
>         My scenerio is like this
>
>         Client <-------> NAT <-------> OpenSIPs/RTPProxy <-------> Client
>
>
>         in this scenerio left side of OpenSIPs is public side and the
>         right side
>         is on private network. Secondly i have tried using
>         rtpproxy_offer/answer() but the same problem. I will try using
>         rtpproxy_offer/answer() again in a bit more detail now specially
>         after
>         hearing about problems in engage_rtpproxy in brigding mode. Now
>         can you
>         point me how i can achieve nat handling in rtpproxy module?
>
>         Regards,
>         Qasim
>
>
>         On Thu, May 9, 2013 at 5:39 PM, Răzvan Crainea
>         <razvan at opensips.org <mailto:razvan at opensips.org>
>         <mailto:razvan at opensips.org <mailto:razvan at opensips.org>>> wrote:
>
>              Hi, Qasim!
>
>              There are two problems with your approach: the first one is
>         that you
>              are using the engage_rtp_proxy() function in a bridging mode
>              scenario. The behavior of this is undefined, because the
>         rtpproxy
>              module cannot fully determine your scenario (for example
>         what's the
>              direction of the media flow in the reply). That's why you
>         should use
>              the rtpproxy_offer() and rtpproxy_answer() functions to
>         explicitly
>              indicate the direction in INVITE and replies.
>              The second problem is that you try to change the SDP twice:
>         first by
>              the fix_nated_sdp() and then by engage_rtp_proxy(). These
>         changes
>              confuse OpenSIPS, who tries to apply both of them. Try to
>         use only
>              one. My suggestion is to rtpproxy_offer/answer() to fix the
>         SDP,
>              without calling fix_nated_sdp().
>
>              Best regards,
>
>              Razvan Crainea
>              OpenSIPS Core Developer