[Serusers] LOOSE routing problem : helppppppppp

Martin Koenig martin.koenig at toplink-plannet.de
Tue Sep 7 15:49:52 CEST 2004


Hi there,

What exactly is the problem? Everything is as it should be.

See RFC3261 section 12.2.1.1 for further information:

ACK 0156395148 at 80.118.128.1
Route 0156395148 at 80.118.128.5

Is what you should see. Verify with ngrep or something similar.

The Loose Route processing of the proxy removes the route header field and
forwards then to the Request-URI.

Regards,
Martin


________________________________

	From: serusers-bounces at iptel.org [mailto:serusers-bounces at lists.iptel.org]
On Behalf Of Nicolas RUIZ
	Sent: Tuesday, September 07, 2004 11:52 AM
	To: serusers at lists.iptel.org
	Subject: [Serusers] LOOSE routing problem : helppppppppp
	
	

	Hi,

	 

	I have a problem with loose routing and strict routing.

	 

	-          I have a proxy-registrar SER 0.8.12, it says that Iptel
is compliant RFC 3261

	-          I have a CISCO ATA with code 3.1.0 and its work.

	-          I have a CISCO ATA with code 3.1.1 and when the ACK is
send to Iptel the request line is ACK : 0156395148 at 80.118.128.1

	 

	And 80.118.128.1 is my gateway Cisco AS5300 to the PSTN,

	 

	-          With the ATA 3.1.0, the ACK is : 0156395148 at 80.118.128.5.

	 

	And 80.118.128.5 is IPTEL ser.

	 

	In Cisco Web pages, he says that the new version on ATA 3.1.1 is
compliant RFC 3261with loose routing.

	
http://www.cisco.com/en/US/products/hw/gatecont/ps514/prod_release_note09186
a0080238c0a.html

	 

	Is someone can explain what is not good?

	 

	Thanks in advance for your help.

	 

	NICOLAS RUIZ

	VIVVACTION
	FRANCE, PARIS

	 

	THAT'S my conf of SER:

	 

	# main routing logic

	 

	route{

	        # initial sanity checks -- messages with

	        # max_forwards==0, or excessively long requests

	        if (!mf_process_maxfwd_header("10")) {

	                sl_send_reply("483","Too Many Hops");

	                break;

	        };

	        if ( msg:len > max_len ) {

	                sl_send_reply("513", "Message too big");

	                break;

	        };

	 

	        # we record-route all messages -- to make sure that

	        # subsequent messages will go through our proxy; that's

	        # particularly good if upstream and downstream entities

	        # use different transport protocol

	        record_route();

	        loose-route processing

	        if (loose_route()) {

	                t_relay();

	                break;

	        };

	 

	 

	        /* grant Route routing if route headers present */

	        if (loose_route()) { t_relay(); break; };

	 

	        /* record-route INVITEs -- all subsequent requests must
visit us */

	        if (method=="INVITE") {

	                record_route();

	        };

	 

	        # now check if it really is a PSTN destination which should
be handled

	        # by our gateway; if not, and the request is an invitation,
drop it --

	        # we cannot terminate it in PSTN; relay non-INVITE requests
-- it may

	        # be for example BYEs sent by gateway to call originator

	 

	        if (uri=~"sip.vivaction.net"){

	 

	                if (method=="REGISTER") {

	 

	                        # Uncomment this if you want to use digest
authentication

	                        if (!www_authorize("sip.vivaction.net",
"subscriber")) {

	                                www_challenge("sip.vivaction.net",
"0");

	                                break;

	                        };

	 

	                        save("location");

	                        break;

	                };

	 

	                # native SIP destinations are handled using our
USRLOC DB

	                if (!lookup("location")) {

	 

	 

	if (!proxy_authorize("sip.vivaction.net", "subscriber")) {

	                                proxy_challenge("sip.vivaction.net",
"1");

	                                break;

	                        };

	 

	 

	                rewritehostport("80.118.128.6:5060");

	 

	                };

	 

	               # forward the request now

	                if (!t_relay()) {

	                        sl_reply_error();

	                        break;

	                };

	        };

	}

	 





More information about the sr-users mailing list