[OpenSIPS-Users] re-INVITE from external gateway

[Bogdan-Andrei Iancu]

Hi Daniel,

You have to ways to handle this problem:

1) at original INVITE, when you know the NAT status of both caller and 
callee, you can store a RR param about this (a cookie telling if caller 
/ callee was natted). The RR header will show up (as Route hdr) in all 
sequential requests (see the RR module for param handling functions).

2) use in onreply route the nat_uac_test("1") to test the contact and 
fix it.

Regards,
Bogdan

Daniel Goepp wrote:
> Was it really this simple, am I really that stupid?  After looking 
> into the nat_uac_test more, it's just testing for RFC 1918 the way we 
> have it configured, so I put into the reply_route:
>
>         if ($ct.fields(uri)=~"10\.*|^192\.168\.*|^172\.16\.*") {
>                 xlog ("Found a response from a private address! - 
> $ct.fields(uri)");
>                 fix_nated_contact();
>         }
>
> And my calls are now staying up past the UPDATE messages, with the 
> correct Contact information.  I'm sure this will break something 
> else.  Is this the correct / recommended way to do this?  I also took 
> out the INVITE test in the routes.  Why wouldn't you treat all 
> messages the same once it reaches that routing logic, be it an UPDATE, 
> INFO, etc...?
>
> -dg
>
>
> On Thu, Apr 22, 2010 at 6:43 PM, Daniel Goepp <dan at goepp.net 
> <mailto:dan at goepp.net>> wrote:
>
>     To further clarify this, what I could just be looking for is the
>     reverse of the nat_uac_test, which tests if the request is coming
>     from a NAT'd endpoint.  What if the call was sent _to_ a NAT'd
>     endpoint, and we need to appropriately handle the contact in the
>     response, not the request?  I have a 200 OK coming back in
>     response to an UPDATE message, but the contact is a private
>     address.  After looking deeper into the dialog module, I'm not
>     even sure it can help me with this one.  I'm sure I can't be the
>     first person dealing with responses sent to a NAT'd endpoint :) 
>     But I'm not seeing a clear way to identify these, so again any
>     thoughts are much appreciated.
>
>     Thanks
>
>     -dg
>
>
>
>     On Thu, Apr 22, 2010 at 4:20 PM, Daniel Goepp <dan at goepp.net
>     <mailto:dan at goepp.net>> wrote:
>
>         I have two questions, one specific and one general, but I have
>         a feeling the answers might be similar to both.
>
>         First, we are having an issue with a gateway that does a
>         re-INVITE.  The call scenario is like this, registered user X
>         calls out via a carrier to the PSTN, we identify that the
>         customer is behind NAT, and do the proper contact rewrite. 
>         However then the carrier then re-INVITEs at 15 minutes to make
>         sure the call is up, everything goes through fine, except we
>         are not rewriting the contact in the 200 OK back, because the
>         carrier was not behind NAT.  So my thought is that this would
>         be a situation for an AVP (of which my knowledge is limited
>         and I can't wait for the next webinar on the topic).  That
>         when the call gets setup, I set a variable to identify that I
>         should act differently for this call when I see that
>         re-INVITE.  Or would the more appropriate solution be to just
>         bit the bullet and use the dialog module?  Or perhaps there is
>         yet another better solution I'm not aware of.  I haven't
>         implemented the dialog module so far due to concerns regarding
>         resource consumption.  So I guess the bigger question is, do
>         most of the folks out there use the dialog module?
>
>         My next question is related to the fact that the default route
>         for a call that has a totag (existing transaction) is route
>         1.  However the initial call might well have been routed using
>         a different route in the first place.  Again, I was thinking
>         would I use AVP here to put into the has totag section of the
>         script to go to the same route used the first time, or should
>         I again be looking to the dialog module to just make sure I'm
>         keeping track of all calls more completely, and then can make
>         sure that a subsequent messages coming in with a totag, that
>         was let's say originally routed using route 3, again goes to
>         route 3.
>
>         I sort of feel I have answered my own question here, that
>         dialog is my only solution, but any feedback regarding other
>         people experiences is handing in call re-signaling would be
>         greatly appreciated.
>
>         Thanks
>
>         -dg
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro