[Users] Error parsing URI's using TLS

Cesc cesc.santa at gmail.com
Tue Jul 25 15:34:54 CEST 2006


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
> >
>




More information about the Users mailing list