[OpenSIPS-Users] re-INVITE from external gateway

[Daniel Goepp]

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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20100422/7c415b30/attachment.htm