[Serusers] rport processing bug
Jan Janak
jan at iptel.org
Sun Oct 17 16:34:09 CEST 2004
On 17-10 16:27, Jakob Schlyter wrote:
> On Sun, 17 Oct 2004, Jan Janak wrote:
>
> >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.
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.
> >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?
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.
> 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.
More information about the sr-users
mailing list