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, bran...@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).
--
Alex Balashov - Principal
Evariste Systems LLC
Tel : +1 678-954-0670
Direct : +1 678-954-0671
Web : http://www.evaristesys.com/
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
