[Serusers] rport processing bug

[Jan Janak]

Here is a snippet of the configuration file:

# Special handling for NATed clients; first, NAT test is
# executed: it looks for via!=received and RFC1918 addresses
# in Contact (may fail if line-folding is used); also,
# the received test should, if completed, should check all
# vias for rpesence of received
if (nat_uac_test("3")) {
	# Allow RR-ed requests, as these may indicate that
	# a NAT-enabled proxy takes care of it; unless it is
	# a REGISTER
	
	if (method == "REGISTER" || ! search("^Record-Route:")) {
		log("LOG: Someone trying to register from private IP, rewriting\n");
		# This will work only for user agents that support symmetric
		# communication. We tested quite many of them and majority is
		# smart enough to be symmetric. In some phones it takes a configuration
		# option. With Cisco 7960, it is called NAT_Enable=Yes, with kphone it is
		# called "symmetric media" and "symmetric signalling".
		fix_nated_contact(); # Rewrite contact with source IP of signalling
		if (method == "INVITE") {
			fix_nated_sdp("1"); # Add direction=active to SDP
		};
		force_rport(); # Add rport parameter to topmost Via
		setflag(6);    # Mark as NATed
	};
};

The snippet applies fix_nated_contact only if nat_uac_test returns true.
The parameter 3 tells nat_uac_test to do both -- RFC198 and via!=src IP
tests.

  Jan.

On 17-10 16:34, Jan Janak wrote:
> 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.
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers