[Users] Error parsing URI's using TLS

Klaus Darilion klaus.mailinglists at pernau.at
Tue Jul 25 17:38:19 CEST 2006


Stephen Paterson wrote:
> 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

No, sending to itself is not necessarily a loop, e.g. if the request URI 
changes. Then this is a spiral which is allowed. Maybe there could be 
better loop detection alogrithm, but openser only uses the Max-forwards 
count.

> for 70 until Max-Forwards = 0. I can't work out why it would be doing
> this.

If you want to see the looped messages sniff on the loopback device too.

ngrep -d any ...
tcpdump -i any ...

The problem must be in your openser.cfg. Somewhere in the routing logic 
you have to change the request URI - manually or by lookup() (if the 
client is registered).

In-dialog should then be forwarded correctly in loose_route block.

regards
klaus






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





More information about the Users mailing list