Thanks, it was actually xlog I used, just a lazy cut and paste into the email. I
didn't load the xlog module though. When I do I get:
Jul 25 13:35:41 sip-fedora3 ./openser[3916]: received request uri is
[sips:steve@10.202.200.132]
Jul 25 13:35:41 sip-fedora3 ./openser[3916]: tls_init: verify_callback: depth = 1
Jul 25 13:35:41 sip-fedora3 ./openser[3916]: tls_init: verify_callback: preverify is good:
verify return: 1
Jul 25 13:35:41 sip-fedora3 ./openser[3916]: tls_init: verify_callback: depth = 0
Jul 25 13:35:41 sip-fedora3 ./openser[3916]: tls_init: verify_callback: preverify is good:
verify return: 1
Jul 25 13:35:41 sip-fedora3 ./openser[3917]: tls_init: verify_callback: depth = 1
Jul 25 13:35:41 sip-fedora3 ./openser[3917]: tls_init: verify_callback: preverify is good:
verify return: 1
Jul 25 13:35:41 sip-fedora3 ./openser[3917]: tls_init: verify_callback: depth = 0
Jul 25 13:35:41 sip-fedora3 ./openser[3917]: tls_init: verify_callback: preverify is good:
verify return: 1
Jul 25 13:35:41 sip-fedora3 ./openser[3917]: received request uri is
[sips:steve@10.202.200.132]
Jul 25 13:35:41 sip-fedora3 last message repeated 10 times
Jul 25 13:35:41 sip-fedora3 ./openser[3916]: ERROR: parse_uri: uri too short: <sip:>
(4)
Jul 25 13:35:41 sip-fedora3 ./openser[3916]: ERROR: parse_sip_msg_uri: bad uri
<sip:>
Jul 25 13:35:41 sip-fedora3 ./openser[3916]: xl_get_ruri: ERROR while parsing the R-URI
Jul 25 13:35:41 sip-fedora3 ./openser[3916]: received request uri is [<null>]
Jul 25 13:35:41 sip-fedora3 ./openser[3916]: ERROR: parse_uri: uri too short: <sip:>
(4)
Jul 25 13:35:41 sip-fedora3 ./openser[3916]: ERROR: parse_sip_msg_uri: bad uri
<sip:>
Jul 25 13:35:41 sip-fedora3 ./openser[3916]: loose_route: Error while parsing Request URI
Jul 25 13:35:41 sip-fedora3 ./openser[3916]: ERROR: parse_uri: uri too short: <sip:>
(4)
Jul 25 13:35:41 sip-fedora3 ./openser[3916]: ERROR: parse_sip_msg_uri: bad uri
<sip:>
Jul 25 13:35:41 sip-fedora3 ./openser[3916]: WARNING: do_action:error in expression
Jul 25 13:35:41 sip-fedora3 ./openser[3916]: ERROR: parse_uri: uri too short: <sip:>
(4)
Jul 25 13:35:41 sip-fedora3 ./openser[3916]: ERROR: parse_sip_msg_uri: bad uri
<sip:>
Jul 25 13:35:41 sip-fedora3 ./openser[3916]: WARNING: do_action:error in expression
This look to me like the URI is correct on receipt but is somehow lost during the
parsing.
Would the developer's forum be a more appropriate place for this? It looks like a bug.
I've also had a suggestion from Cesc that openser is possibly not yet that stable when
it comes to the sips scheme (I guess it was implemented using transport=tls).
Cheers
Steve
-----Original Message-----
From: users-bounces(a)openser.org [mailto:users-bounces@openser.org]On
Behalf Of Daniel-Constantin Mierla
Sent: 25 July 2006 13:24
To: Stephen Paterson
Cc: users(a)openser.org
Subject: Re: [Users] Error parsing URI's using TLS
Hello Stephen,
On 07/25/06 15:17, Stephen Paterson wrote:
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
it must be xlog("...") instead of log("...").
And you must load xlog module to have the function available in script.
You can print the incoming message to the syslog via:
xlog("received message [[$mb]]\n\n");
Watch the logs to see what you receive from the net.
Cheers,
Daniel
# 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(a)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(a)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(a)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@aculab.com
Website:
http://www.aculab.com
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users