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, [email protected] 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 <[email protected]
<mailto:[email protected]>> 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, [email protected]
    <mailto:[email protected]> 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
        <[email protected] <mailto:[email protected]>
        <mailto:[email protected] <mailto:[email protected]>>> 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

_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to