[Users] Error parsing URI's using TLS
Cesc
cesc.santa at gmail.com
Tue Jul 25 14:20:35 CEST 2006
it should be xlog ... not log
cesc
On 7/25/06, Stephen Paterson <Stephen.Paterson at aculab.com> 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
>
> # 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
> >
>
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
More information about the Users
mailing list