[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