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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
