[Users] Error parsing URI's using TLS

[Daniel-Constantin Mierla]

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
>