Thanks for your answers.

I thought I could make an example with your suggestions, for documentation (I see others are interested at the moment).

 

Using add_contact_alias, when the 200 OK for an INVITE is received, e.g. from 10.0.9.49:61756:

 

SIP/2.0 200 OK

[…]

Contact: <sip:giacomo@10.0.9.49:61750;transport=tcp>

 

add_contact_alias detects that received ip:port is different than the one in the Contact, so it appends an alias before relaying the 200 OK:

 

SIP/2.0 200 OK

[…]

Contact: <sip:giacomo@10.0.9.49:61750;alias=10.0.9.49~61756~2;transport=tcp>

 

This will then be used when generating the ACK:

 

ACK sip:giacomo@10.0.9.49:61750;alias=10.0.9.49~61756~2;transport=tcp SIP/2.0

[…]

 

which Kamailio will change with handle_uri_alias(), removing the alias and setting the received ip:port as destination:

 

ACK sip:giacomo@10.0.9.49:61750;transport=tcp SIP/2.0

 

sent correctly to 10.0.9.49:61756.

 

With fix_nated_contact, same scenario, Kamailio would modify the Contact before relaying the 200 OK:

SIP/2.0 200 OK

[…]

Contact: <sip:giacomo@10.0.9.49:61756;transport=tcp>

 

Which will then be used as R-URI for the ACK:

 

ACK sip:giacomo@10.0.9.49:61756;transport=tcp SIP/2.0

[…]

 

And sent without modifications to 10.0.9.49:61756.

 

As stated in other references, the difference is that with the add_contact_alias approach the invited client sees its published Contact in the ACK’s R-URI.

 

I hope this is useful.

Regards,

Giacomo

 

 

 

Am 09.03.2012 20:56, schrieb Giacomo Vacca:

One of the solutions I’ve found is using always add_contact_alias() in onreply_route when handling the 200 OK, and then use handle_ruri_alias() when defining the destination for the ACK.

Yes, that the pragmatic approach I always use. IMO it is also a bit of security. I do not like to blindly trust user provided data (e.g. contact header), thus I always use the IP:port from where the message was received.

regards
Klaus