[Users] Error parsing URI's using TLS

samuel samu60 at gmail.com
Tue Jul 25 17:29:23 CEST 2006


try to add an alias statement containing the domain your server is
responsible for....i recall it gave some trouble if I don't put it and only
set TLS...

alias=10.202.200.132

Hope it solves it,
samuel.

2006/7/25, Stephen Paterson <Stephen.Paterson at aculab.com>:
>
> Well, the failed parsing is something of a red herring - it has exposed a
> bug in my ACK which only manifests on receipt of a non-200 response.
>
> I've worked out how to enable lots more logging and looking at it, openser
> seems to run through several iterations of something or other and by the
> time it's finished the INVITE contains 6 Record-Route headers (all
> identical), 7 Via headers (all identical but the original) and 6 identical
> P-hint headers. It then is over 2048 bytes and the 513 is sent. Does anyone
> know why it's complaining about big messages for transports other than UDP?
>
> When I remove the message too big check from the config I start getting a
> 483 - too many hops. Looking at the logs it shows openser stuck in a loop
> adding Via, Record-Route & P-hint headers. All the while it is decrementing
> Max-Forwards so it does eventually break out of this loop.
>
> It looks like openser is forwarding the INVITE to itself. This should
> terminate with loop detected after one iteration but it carries on for 70
> until Max-Forwards = 0. I can't work out why it would be doing this.
>
> Any thoughts?
>
> Cheers
>
> Steve
>
> P.S.
> Cesc. To put your mind at rest, the contact header is configurable to have
> a user part. I'm just lazy :)
>
>
>
>
> -----Original Message-----
> From: users-bounces at openser.org [mailto:users-bounces at openser.org]On
> Behalf Of Cesc
> Sent: 25 July 2006 14:35
> To: Stephen Paterson
> Cc: users at openser.org
> Subject: Re: [Users] Error parsing URI's using TLS
>
>
> No problem in terminating to yourself ... but i mentioned the loop not
> just because that.
> In the log you sent, you mention ...
> [skipped]
> 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 at 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)
> [skipped]
>
> so ... if the same message at the beggining of your main route is
> repeated 10 times, it means that you get 10 times the same message ...
> or you pasted the same xlog 10 times along your config file?
>
> I would add this also at the beginning ...
> xlog("received message [[$mb]]\n\n");
>
> print the received message ... you may discover the "loop" ...
>
> Cesc
> PS - your application sends a contact without user part ... you may
> want to improve that ...
> On 7/25/06, Stephen Paterson <Stephen.Paterson at aculab.com> wrote:
> > It's not really a loop in the sense of 'loop detected' - both ends of
> the 'loop' terminate the messaging. So I register my UA with the proxy (
> steve at blah) and call steve at blah from the same UA - just makes it easier to
> test while in development. You need a UA that can handle multiple calls of
> course. That isn't the problem though. If openser thinks this is a loop
> detected it is wrong. A loop detection is where a request has been routed
> back to a proxy that previously forwarded the request thereby creating a
> situation where the request will be forwarded indefinitely. There is nothing
> wrong with terminating a call on the same equipment that originated the
> call.
> >
> > Cheers
> >
> > Steve
> >
> > -----Original Message-----
> > From: Cesc [mailto:cesc.santa at gmail.com]
> > Sent: 25 July 2006 13:59
> > To: Stephen Paterson
> > Cc: daniel at voice-system.ro; users at openser.org
> > Subject: Re: [Users] Error parsing URI's using TLS
> >
> >
> > Actually ... it already struck me when you posted your message ...
> >
> > 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
> > 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>
> >
> > You have a loop ... don't you? From and To are the same ... ok ...
> > contact isn't (but it is missing the user part) ... but the request
> > uri is yourself again ... what are the IPs of the UAs and Proxies
> > involved?
> > You mention that u had your "own" application? i think you are doing
> > something wrong there ... which triggers some error in openser ...
> >
> > Cesc
> >
> >
> > On 7/25/06, Stephen Paterson <Stephen.Paterson at aculab.com> wrote:
> > > 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 at 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 at 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 at openser.org [mailto:users-bounces at openser.org]On
> > > Behalf Of Daniel-Constantin Mierla
> > > Sent: 25 July 2006 13:24
> > > To: Stephen Paterson
> > > Cc: users at 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 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
> > >
> > > _______________________________________________
> > > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kamailio.org/pipermail/users/attachments/20060725/64b2529c/attachment.htm 


More information about the Users mailing list