[OpenSIPS-Users] re-INVITE from external gateway
Daniel Goepp
dan at goepp.net
Fri Apr 23 22:38:29 CEST 2010
Well, only messages that have Contact headers, of which a BYE does not. So
for example we get UPDATE and INFO messages that might be changing video,
etc...that is one situation, the other of course as you note is the
re-INVITE. Problem is, if the carrier doesn't get it, they will take down
the call. It was part of our interop to support session timers. I think my
fix is working now, I'm just hoping it didn't break something else.
-dg
On Fri, Apr 23, 2010 at 5:14 AM, Jeff Pyle <jpyle at fidelityvoice.com> wrote:
> 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> 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> 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
>
>
>
> _______________________________________________
> 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/20100423/3306700a/attachment.htm
More information about the Users
mailing list