[Users] Error parsing URI's using TLS
Daniel-Constantin Mierla
daniel at voice-system.ro
Tue Jul 25 14:24:08 CEST 2006
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 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 sr-users
mailing list