[Users] Error parsing URI's using TLS
Stephen Paterson
Stephen.Paterson at ACULAB.COM
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
>
More information about the Users
mailing list