28 Sep
2009
28 Sep
'09
4:27 a.m.
Florian Meister schrieb:
btw: many providers (and me) choose to apply NAT handling (fixing
contact) in all cases - to simplify the config and security.
regards
klaus
How do you
route in-dialog messages? LB and proxy/registrar should
use record-route on initial request to stay in the proxy-chain. LB
and proxy/registrar should route in-dialog requests with
loose_route() and t_relay().
Also, on the LB you have to do the NAT traversal for the clients:
i.e. fix_nated_contact() on messages from the client. If the LB is
multihomed and uses double-record-routing I think you could the
same mechanism like path (adding "received" to the record-route
header) too.
I already found my problem. It was as you mentioned a NAT problem. In
the preloaded-route (which is added by the proxy for path support)
the nat-flag is not set. In the response I check for the existence of
the nat flag for diciding to do fix_nated_contact. Since it does not
exist, I have the wrong contact in the response.
I am checking now for both ";nat=yes" and "received=", because if
there is a received header it is a natted device.