6 Nov
2009
6 Nov
'09
8:25 p.m.
Klaus Darilion schrieb:
Juha Heinanen schrieb:
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
Klaus Darilion writes:
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.* 2. 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?
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev