Klaus Darilion schrieb:
Juha Heinanen schrieb:
Klaus Darilion writes:
- server
I use the pragmatic, and well working UDP approach. Just call >
fix_nated_contact/register also for TCP clients. I never had any issues > with that.
even when client is not behind nat like in the example of the discussion?
In this case it can work also with client receiving responses/in-dialog requests at advertised port (as long as the client is really listening on the advertised port).
But one of my favorites statement is: "Never trust the user". As the contact and Via headers are user provided data I do not trust it. Thus I always enforce symmetric signaling, regardless if client is behind NAT or not and regardless of the used protocol.*
Of course this has some limitations too - e.g. if a local user uses a proxy between client and my proxy - I will incorrectly rewrite the contact to the socket of the other proxy. But in typical service provider deployments there should not be proxies inbetween, or the proxy should be able to recover from this.
regards klaus
The only exception is if the client is known to be asymmetric (then I have to screen the contact that at least the IP is the src_ip).
regards Klaus
- I once used the somehow "academic" approach with hyper-intelligent NAT
detection methods, but I ended up with the "pragmatic" approach which is easier, more secure and works IMO better.
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev