[Users] loose_route problem with Fritz

Edoardo Serra edoardo.serra at webrainstorm.it
Tue May 22 11:24:26 CEST 2007


Hi guys,
	I have OpensER 1.1.0 in fornt of 2 Asterisks servers.
My OpenSER act as load balancer for outbound calls and for registrar 
server for inbound calls coming from Asterisks PSTN GW to Users

Some users, using AVM Fritz Fon Boxes cannot register on the proxy, they 
get a "483 Too Many Hops".
They say it happens only if they configure the Fritx using FQDN of our 
proxy, if they put its IP addess in it they are having no problems...
(it sounds very strange to me but I captured some trafic and had 
confirmation of what they're saying)

Here is a SIP dialog with the error message

Request-Line: REGISTER sip:sip.advancemedia.it SIP/2.0
Via: SIP/2.0/UDP 
192.168.1.121:5060;branch=z9hG4bKC0F2D683E6BE8AC5F1A4A260BE120
Route: <sip:sip.advancemedia.it;lr>
From: <sip:cirifax at sip.advancemedia.it>;tag=1898319928
To: <sip:cirifax at sip.advancemedia.it>
Call-ID: 9ADCCD22187BDEC93B5953DD93E0F at 192.168.1.121
CSeq: 1 REGISTER
Max-Forwards: 70
User-Agent: AVM FRITZ!Box Fon ata 1020 11.04.01 (Jan 25 2006)
Supported: 100rel, replaces
Allow-Events: telephone-event, refer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, PRACK, INFO, 
SUBSCRIBE, NOTIFY, REFER, MESSAGE
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0


Status-Line: SIP/2.0 483 Too Many Hops
Message Header
Via: SIP/2.0/UDP 
192.168.1.121:5060;received=80.67.115.96;branch=z9hG4bKC0F2D683E6BE8AC5F1A4A260BE120
From: <sip:cirifax at sip.advancemedia.it>;tag=1898319928
To: 
<sip:cirifax at sip.advancemedia.it>;tag=b36cb132c8240044969e91db40b97d00.d5d1
Call-ID: 9ADCCD22187BDEC93B5953DD93E0F at 192.168.1.121
CSeq: 1 REGISTER
Server: OpenSer (1.1.0-notls (i386/linux))
Content-Length: 0
Warning: 392 213.92.79.131:5060 "Noisy feedback tells:  pid=13326 
req_src_ip=213.92.79.131 req_src_port=5060 
in_uri=sip:sip.advancemedia.it out_uri=sip:sip.advancemedia.it via_cnt==71"

It doesn't happen if the user put the ip of the proxy server in the 
configuration of the Fritz

I guess it's a problem with loose routing but I cannot understand if 
it's a buggy implementation of SIP in the fritz or my misconfiguration

Here is my openser.cfg, tnx in advance for help.

Edoardo


# $Id: ser.cfg,v 1.21.4.1 2003/11/10 15:35:15 andrei Exp $
# ----------- global configuration parameters ------------------------

check_via=yes    # (cmd. line: -v)
dns=no	  # (cmd. line: -r)
rev_dns=no      # (cmd. line: -R)
fifo="/tmp/ser_fifo"

# ------------------ module loading ----------------------------------
loadmodule "/usr/lib/openser/modules/sl.so"
[...]

modparam("usrloc", "db_mode", 2)
modparam("usrloc", "db_url", "mysql://user:pass@192.168.252.5/openser")
modparam("usrloc", "timer_interval", 120)
modparam("auth_db", "calculate_ha1", 0)
modparam("auth_db", "db_url", "mysql://user:pass@192.168.252.5/db")
modparam("uri_db", "db_url", "mysql://user:pass@192.168.252.5/openser")
modparam("rr", "enable_full_lr", 1)
modparam("registrar", "nat_flag", 6)
modparam("registrar", "max_expires", 3600)
modparam("registrar", "min_expires", 60)
modparam("registrar", "append_branches", 0)
modparam("registrar", "desc_time_order", 1)
modparam("nathelper", "natping_interval", 20) # Ping interval 20 s
modparam("nathelper", "ping_nated_only", 1)   # Ping only clients behind NAT
modparam("dispatcher", "force_dst", 1)

# -------------------------  request routing logic -------------------
# main routing logic

route{
	if (!mf_process_maxfwd_header("10")) {
		sl_send_reply("483","Too Many Hops");
		exit;
	};
	if ( msg:len > max_len ) {
		sl_send_reply("513", "Message too big");
		exit;
	};

	if ( (method=="OPTIONS") || (method=="SUBSCRIBE") || (method=="NOTIFY") ) {
		sl_send_reply("405", "Method Not Allowed");
		exit;
	}

	# loose-route processing
	if (loose_route()) {
		# mark routing logic in request
		append_hf("P-hint: rr-enforced\r\n");
		t_relay();
		exit;
	};
	
	if (!method=="REGISTER") {
		record_route();
	};


	if ((src_ip==ip.of.asterisk.1) || (src_ip==ip.of.asterisk.1)) {
		if (!lookup("location")) {
			sl_send_reply("486", "Busy here");
			exit;
		};

		t_on_reply("1");
		if (!t_relay()) {
			sl_reply_error();
		};
		exit;
	};

	if (nat_uac_test("3")) {
		if ((method=="REGISTER") || (method=="INVITE") || (method=="OPTIONS")) {
			fix_nated_contact();
			force_rport();
			setflag(6);    # Mark as NATed
		}
	}

	if (method=="REGISTER") {
		if (!proxy_authorize("exorsa", "openser_view")) {
			proxy_challenge("exorsa", "0");
			exit;
		}
		if (!check_to()) {
			sl_send_reply("403", "Digest username and URI username do NOT match! 
Stay away!");
			exit;
		}

		save("location");

		exit;
	};


	if (method=="INVITE") {
		if (!proxy_authorize("exorsa", "openser_view")) {
			proxy_challenge("exorsa", "0");
			exit;
		}

		if (!check_from()) {
			sl_send_reply("403", "Digest username and URI username do NOT match! 
Stay away!");
			exit;
		}
	}

	if (!uri==myself) {
		# mark routing logic in request
		append_hf("P-hint: outbound\r\n");
		route(1);
		exit;
	};

	append_hf("P-hint: usrloc applied\r\n");
	route(1);
}

route[1]
{
	# !! Nathelper
	if (uri=~"[@:](192\.168\.|10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.)" && 
!search("^Route:")){
	    sl_send_reply("479", "We don't forward to private IP addresses");
	    exit;
	};

	# NAT processing of replies; apply to all transactions (for example,
	# re-INVITEs from public to private UA are hard to identify as
	# NATed at the moment of request processing); look at replies
	t_on_reply("1");

	if ((src_ip!=ip.of.asterisk.1) && (src_ip!=ip.of.asterisk.2)) {
		ds_select_dst("1", "0");
	}

	if (!t_relay()) {
		sl_reply_error();
	};
}

# !! Nathelper
onreply_route[1] {
	# NATed transaction ?
	if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") {
		fix_nated_contact();
		# otherwise, is it a transaction behind a NAT and we did not
		# know at time of request processing ? (RFC1918 contacts)
	} else if (nat_uac_test("1")) {
		fix_nated_contact();
	};
}





More information about the Users mailing list