Thinking about this a little more, I am not sure I understand the issue, perhaps because the original post is confusing.
Correct me if I'm wrong:
1) If initial INVITE is from NAT'd user to PSTN, when INVITE is received by proxy its Contact is fixed up and it is passed along.
So, replies and sequential requests from PSTN should go to fixed up target URI (mangled Contact URI from client-side INVITE).
2) If initial INVITE is from PSTN to NAT'd user, replies with Contact from NAT'd client are fixed up by proxy and passed along to PSTN. Sequential requests from PSTN go to new, mangled target URI, including re-INVITEs.
Contact 200 OK or other response to re-INVITE from client is fixed up as well, no?
What am I missing?
-- Alex
On 02/03/2010 04:06 PM, Iñaki Baz Castillo wrote:
El Miércoles, 3 de Febrero de 2010, brandon@cryy.com escribió:
I do see all the behavior as referenced, however the actual problem is upon receipt of the invite to the UAC, in which it responds with 200 OK and Contact of RFC1918 address, in which is not being fix natted contact because at this point kamailio is not aware of the UAC being behind nat due to the reinvite passing the nat uac test because we can not tell with the invite coming downstream from PSTN, however can only tell upon receipt of 200 ok back from client.
Let me know if this all makes sense and if there is something I am still missing.
I don't get still what you mean. With the approach I told in my previos message communication is possible for all the re-INVITE's (coming from the PSTN or from the UA behind NAT).