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@voice-system.ro] Sent: 25 July 2006 12:57 To: Klaus Darilion; Stephen Paterson Cc: users@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@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@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061 Call-ID: 42041801-00000878-44C0E778-00000001@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:
- 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@aculab.com Website: http://www.aculab.com _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users