17 Oct
2004
17 Oct
'04
4:34 p.m.
On 17-10 16:27, Jakob Schlyter wrote:
Then you probably have an error in your configuration file.
fix_nated_contact should be only called when one of the conditions
above is true.
On Sun, 17 Oct 2004, Jan Janak wrote:
Do you know any other way how to get INVITE messages to the phones
behind NAT without port forwarding or similar magic ? If so please
share it with me.
This is necessary for phones behind NAT. They
often put IP and port
which is not accessible from the public internet -- the phone is
typically reachable only through the NAT-binding that was created during
the registration process, that's the reason why SER rewrites the contact
with the IP and port assigned by the NAT device.
according to rfc 3581, rport is specified per transaction. I understand
that this magic might be useful sometimes, but in this case it actually
breaks stuff since the phone doesn't receive a response on this port after
the transacation has ended. You can
fine-tune this behaviour in the configuration file. SER will
rewrite the Contact header field only if it detects that the phone is
behind NAT (either src IP and IP in via do not match or there is a
RFC1918-style IP address).
so why did it rewrite the contact header? the via and the contact was the
same and no addresses used was rfc1918. can this feature be turned off? when reading the docs, one might get the impression
that this is what
fix_contact() is used for but it seems (from your description above) it is
performed anyway.
No, this is what fix_nated_contact does. Contact will not be rewritten
unless you call that function.
Jan.