[OpenSIPS-Users] NAT and Re-INVITE

[Doug]

  Hi Kennard,

Would you be so kind as to post what you did in regards to the reply 
handler? Also do you set the bflag if check_route_param succeeds and 
then let your reply handler check for a bflag?

In regards to the private IP address, thats handled easily with the 
following:

         if(nat_uac_test("1"))
         {
                 fix_nated_contact();
         }

I also modded the code of nathelper.c to include a 64 check for 
nat_uac_test that checks the port number in the contact header against 
the source port of the packet (not sure if this breaks RFC's?), as I had 
an issue with a dumb ALG device stuffing up the port in the contact 
header on the 180 Ringing. It was suppose to be something like:

sip:xxxx at 1.2.3.4:17319

but instead, came through as:

sip:xxxx at 1.2.3.4:17319319

which just broke everything else, so I added my check and if the contact 
header port and source port did not match, I simply called 
fix_nated_contact() to resolve it - this fixed the ALG issue, but still 
left the re-INVITE issue.

I look forward to your assistance.

Thanks
Doug


On 2010/10/12 8:02 PM, Kennard_White at logitech.com wrote:
>
> 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
>
> Inactive hide details for Doug ---10/12/2010 08:47:39 AM--- Hi All, 
> I've got a problem I'm not 100% sure how to resolve.Doug ---10/12/2010 
> 08:47:39 AM--- Hi All, I've got a problem I'm not 100% sure how to 
> resolve.
>
> 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
>
>
> _______________________________________________
> 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/56d4477e/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://lists.opensips.org/pipermail/users/attachments/20101012/56d4477e/attachment-0001.gif