[OpenSIPS-Users] re-INVITE from external gateway

[Daniel Goepp]

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/7468e414/attachment.htm