[OpenSIPS-Users] NAT and Re-INVITE

[Kennard_White at logitech.com]

Hi Doug,

I had similar problem. My solution is to use record-route variable:
add_rr_param("mr=1") on initial INVITE at same time as first call to
use_media_relay(). The later within loose_route block, I use
check_route_param("mr=1") for re-INVITES and then re-invoke media relay if
found. In that case I also install a reply handler for the reinvite and set
the bflag. The reinvite reply handler then checks the bflag and invokes
use_media_proxy on the reply.  That solves the media problem for me.

How are you handling the private IP in the Contact address in B's 200
response to A's re-INVITE? This contact address will become the R-URI of
all subsequent in-dialog messages from A (e.g., INFO, MESSAGE, BYE).

Regards,
Kennard



From:	Doug <doug at wd.co.za>
To:	OpenSIPS users mailling list <users at lists.opensips.org>
Date:	10/12/2010 08:47 AM
Subject:	[OpenSIPS-Users] NAT and Re-INVITE
Sent by:	users-bounces at lists.opensips.org



  Hi All,

I've got a problem I'm not 100% sure how to resolve.

Ok the scenario is, client A is on a public interface, Client B is on a
private IP address and has cflag 6 set in the location table.

Client A calls Client B via Opensips.

Now during the initial INVITE, opensips locates Client B, loads the
information, and naturally bflag is set to 6 (my NAT flag). This then
triggers mediaproxy to get involved, and the call is established
correctly, media passes from Client A ----> Mediaproxy ----> Client B.

Now the problem is, the Client A device (Audiocodes ATA) sends a
Re-INVITE to switchover to T.38. The process works pretty much the same,
but follows the loose_route path due the call already being in a dialog
(i think thats the right terminology).

Client B receives the Re-INVITE, however, because loose_route doesn't
know about the bflag (I've check with xlog and its not set during this
phase), mediaproxy is not engaged (as the INVITE is coming form Client A
who is not behind NAT). So when Client B responds, the SDP is a private
IP address, and the call falls apart.

Now I suppose what I could do is call "use_media_proxy()" from the
onreply_route if the SDP is RFC1918 (nat_uac_test("8")), however, this
would engage mediaproxy for only one leg of the call and not the Client
A leg.

The other option is I can force mediaproxy on all calls, which works,
but now I have to have RTP flowing through my links for devices that
could be speaking directly to each other.

Has anyone had experience with this, or an idea of how to check during
the loose_route phase if the Client B sisde is behind nat, or set a flag
that remains consistent throughout the entire call flow (INVITE, 200Ok,
Re-INVITE, 200OK, BYE).

I look forward to your assistance.

Many thanks
Doug


_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20101012/028ac105/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://lists.opensips.org/pipermail/users/attachments/20101012/028ac105/attachment.gif