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]> 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] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
