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.<br>
<br>Thanks<br><br>-dg<br>
<br><br><div class="gmail_quote">On Thu, Apr 22, 2010 at 4:20 PM, Daniel Goepp <span dir="ltr"><<a href="mailto:dan@goepp.net">dan@goepp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I have two questions, one specific and one general, but I have a feeling the answers might be similar to both.<br><br>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?<br>
<br>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.<br>
<br>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.<br><br>Thanks<br>
<font color="#888888">
<br>-dg<br>
</font></blockquote></div><br>