[OpenSIPS-Users] re-INVITE from external gateway

[Jeff Pyle]

Dan,

Wouldn't you experience the problem with any in-dialog request coming from the PSTN gateway?  Most commonly, a BYE?

I have a strong personal bias against SIP Session Timers in Opensips.  I strip advertised support for them as the messages pass through my proxy with this:

route[21] {     # Suppresses SST announcements
        if (is_present_hf("Session-Expires")) remove_hf("Session-Expires");
        if (is_present_hf("Min-SE")) remove_hf("Min-SE");

        if (is_present_hf("Supported")) {
                if (subst('/^(Supported:.*)timer\s*,(.*)$/\1\2/i')) {
                        #xlog("L_INFO", "Removed timer support (1)\n");
                } else if (subst('/^(Supported:.*),\s*timer(.*)$/\1\2/i')) {
                        #xlog("L_INFO", "Removed timer support (2)\n");
                } else if (search('^Supported:.*timer.*$')) {
                        remove_hf("Supported");
                        #xlog("L_INFO", "Removed timer support (3)\n");
                }
        }
}

I cannot take credit for this code; I found it linked on the Opensips site somewhere.  Anyway, it would likely prevent your reinvites from happening in the first place.  But that does nothing to address the NAT issue.  My config contains the following:

some module parameters:
  modparam("registrar", "received_avp", "$avp(s:received_uri)")
  modparam("usrloc", "nat_bflag", 7)

Very close to the top of the request route script, I have:
        if (client_nat_test("3")) {
                force_rport();
                $avp(s:received_uri) = $source_uri;
                if (!is_method("REGISTER"))
                        fix_contact();
                setbflag(7);
        }

And that's it, really.  I thought I had more in the loose_route section but I do not.  I don't have any problems with in-dialog requests from either side during a call where one side is behind NAT.


- Jeff



On Apr 22, 2010, at 11:07 PM, 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<mailto: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/20100423/bc45a102/attachment.htm