Alex Balashov schrieb: > Klaus Darilion wrote: > >> Actually I would nat=yes always, even if clients are not behind NAT os >> otherwise the clietn can put some garbage into the contact header (e.g. >> IP address of an upstream provider) and influence routing. > > No. There is a specific reason RFC 3261 says: > > "Registration creates bindings in a location service for a particular > domain that associates an address-of-record URI with one or more > contact addresses. Thus, when a proxy for that domain receives a > request whose Request-URI matches the address-of-record, the proxy > will forward the request to the contact addresses registered to that > address-of-record." > > This gives the UAC the necessary level of control to determine how it is > to be contacted. > > Imagine, for a example, a scenario in which incoming registrations are > proxied further upstream for whatever reason - load balancer/distributor > perhaps? - by an intermediate element. Do you really want to use that > proximate hop's received IP address in place of the ultimate sending > UAC's domain?
This is a different scenario. In this case of course I want the public IP of the client, not of the load balancer. So, yes - in this case nat=no is useful for Asterisk. Nevertheless I ignore the IP provided by the client in the contact header completely - I always use the public IP of the client. Thus, in a loadbalancer setup I would configure the load balancer to ignore the advertised IP but use the "received" IP (implementation depends on the actual setup and used components). But as a basic rule - never ever trust the client. Storing and using the Contact provided by the client without any screening is dangerous. klaus _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users