[Users] Error parsing URI's using TLS

Tue Jul 25 14:17:39 CEST 2006

Hi Daniel,

If I add this line (xlog("received request uri is [$ru]\n");) to the beginning of route (shown below) openser won't start complaining about a bad config file, is there a typo maybe? A shame as it would be nice to see that in the log - I'm finding it difficult to be confident that what we are sending is correct as it is encrypted! I didn't notice before but I am also receiving a 513 as the final response but the check in the following bit of code is before loose_route (the message is also only a little over 1KB).

Is this the config snippet you meant?

route{
	# log("received request uri is [$ru]\n"); -- openser will not start with this line uncommented

	# 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");
		exit;
	};

	if (msg:len >=  2048 ) {
		sl_send_reply("513", "Message too big");
		exit;
	};

	# 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
	if (!method=="REGISTER")
		record_route();

	# subsequent messages withing a dialog should take the
	# path determined by record-routing
	if (loose_route()) {
		# mark routing logic in request
		append_hf("P-hint: rr-enforced\r\n"); 
		route(1);
	};

> Did some other method changed the r-uri before?
I guess you mean in the config file but just in case, I have not altered the source so it should be exactly as is in openser-1.1.0-tls.src.tar.gz. 

Cheers

Steve

-----Original Message-----
From: Daniel-Constantin Mierla [mailto:daniel at voice-system.ro]
Sent: 25 July 2006 12:57
To: Klaus Darilion; Stephen Paterson
Cc: users at openser.org
Subject: Re: [Users] Error parsing URI's using TLS

Seeing the error messages stack I see that the error occurs first during 
the loose_route() processing. Did some other method changed the r-uri 
before? Maybe the config file will help to see what could be wrong - the 
snippet from main route till loose_route() should do it.

To be sure that the r-uri as it comes from upstream is valid or not, add 
the following at the beginning of the main route block:

xlog("received request uri is [$ru]\n");

The xlog function parses the r-uri to be sure it is valid.

Cheers,
Daniel

On 07/25/06 14:39, Klaus Darilion wrote:
> That lok sindeed very strange. HAve you tried other TLS clients (SNOM, 
> eyebeam, minisip)?
>
> regards
> klaus
>
> Stephen Paterson wrote:
>> Hi all,
>>
>> I'm posting this again due to lack of response. If this is the wrong 
>> forum for this kind of query, please could someone let me know of a 
>> list that would be more appropriate. After further investigation and 
>> successful testing against other UAs I am less inclined to believe 
>> that the problem lies with our TLS implementation, rather that the 
>> problem lies with OpenSER.
>>
>> Regards
>>
>> Steve
>>
>> -----Original Message-----
>> From: Stephen Paterson Sent: 21 July 2006 15:52
>> To: 'users at openser.org'
>> Subject: Error parsing URI's using TLS
>>
>>
>> Hi all,
>>
>> I've just started using OpenSER to test our SIP implementation and 
>> have encountered a problem with TLS early on. I can register with the 
>> server without any problem but my calls fail. The logging from the 
>> server shows:
>>
>> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: tls_init: 
>> verify_callback: preverify is good: verify return: 1
>> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: tls_init: 
>> verify_callback: depth = 0
>> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: tls_init: 
>> verify_callback: preverify is good: verify return: 1
>> Jul 21 15:40:54 sip-fedora3 ./openser[14881]: tls_init: 
>> verify_callback: depth = 1
>> Jul 21 15:40:54 sip-fedora3 ./openser[14881]: tls_init: 
>> verify_callback: preverify is good: verify return: 1
>> Jul 21 15:40:54 sip-fedora3 ./openser[14881]: tls_init: 
>> verify_callback: depth = 0
>> Jul 21 15:40:54 sip-fedora3 ./openser[14881]: tls_init: 
>> verify_callback: preverify is good: verify return: 1
>> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: ERROR: parse_uri: uri 
>> too short: <sip:> (4)
>> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: ERROR: 
>> parse_sip_msg_uri: bad uri <sip:>
>> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: loose_route: Error 
>> while parsing Request URI
>> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: ERROR: parse_uri: uri 
>> too short: <sip:> (4)
>> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: ERROR: 
>> parse_sip_msg_uri: bad uri <sip:>
>> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: WARNING: 
>> do_action:error in expression
>> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: ERROR: parse_uri: uri 
>> too short: <sip:> (4)
>> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: ERROR: 
>> parse_sip_msg_uri: bad uri <sip:>
>> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: WARNING: 
>> do_action:error in expression
>>
>> This would suggest that my (for example) From header contains a URI 
>> of: <sip:>! Not overly useful you might say. Now, the same INVITE 
>> without encryption works fine with OpenSER (using either TCP or UDP) 
>> and a serialisation of the INVITE immediately before encryption 
>> (shown below) shows the correct URIs in all the right places.
>>
>> INVITE sips:steve at 10.202.200.132 SIP/2.0
>> From: steve <sips:steve at 10.202.200.132>;tag=ACU-6975-c47afeff
>> To: steve <sips:steve at 10.202.200.132>
>> Contact: <sips:10.202.200.143:5061>
>> Call-ID: 42041801-00000878-44C0E778-00000001 at 192.168.6.91
>> CSeq: 26984 INVITE
>> Content-Length: 281
>> Content-Type: application/sdp
>> Allow: INVITE
>> Allow: ACK
>> Allow: BYE
>> Allow: CANCEL
>> Allow: OPTIONS
>> Allow: NOTIFY
>> Allow: REFER
>> Allow: PRACK
>> Allow: INFO
>> Allow: UPDATE
>> Accept: application/sdp
>> Accept: application/isup
>> Accept: application/qsig
>> Accept: multipart/mixed
>> Accept-Encoding: identity
>> Accept-Language: en
>> Supported: replaces
>> Supported: 100rel
>> Via: SIP/2.0/TLS 
>> 10.202.200.143:5061;branch=z9hG4bKeb10b5f6-18c6-11db-bff7-971e76d819bf
>> Max-Forwards: 70
>> Route: <sips:10.202.200.132:5061;lr>
>>
>> ... SDP omitted
>>
>> For the moment I am pretty much assuming that this is a problem with 
>> our implementation as it is still under development but I can't work 
>> out what. 2 questions:
>>
>> 1. Does anyone have any general thoughts as to what might be going 
>> wrong?
>> 2. Is it possible to get more logging from OpenSER that might shed 
>> some light?
>>
>> Regards
>>
>> Steve
>>
>> Steve Paterson
>> Software Engineer
>> Aculab
>> Tel: +44 (0) 1908 273866
>> Fax: +44 (0) 1908 273801
>> Email: mailto:stephen.paterson at aculab.com
>> Website: http://www.aculab.com 
>> _______________________________________________
>> Users mailing list
>> Users at openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>