Hi Ferianto,
As I see, the error is at line 27. I see that it contain "tls_verify=1" and "tls_require_certificate=0". I don't know what is wrong with this line because As I see from all mailinglist`s messages, they didn`t change this line and if they change it, they just change the value, for example : tls_verify = on tls_require_certificate = on
I've just started using OpenSER today as well and had the same problem. After a little guess work I got it to work using:
tls_verify_client, tls_verify_server & tls_require_client_certificate
instead of
tls_verify & tls_require_certificate
I couldn't find this documented anywhere but it may be, I don't know my way around the docs yet.
Regards
Steve
Steve Paterson Software Engineer Aculab Tel: +44 (0) 1908 273866 Fax: +44 (0) 1908 273801 Email: mailto:stephen.paterson@aculab.com Website: http://www.aculab.com
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@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061 Call-ID: 42041801-00000878-44C0E778-00000001@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@aculab.com Website: http://www.aculab.com
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@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@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061 Call-ID: 42041801-00000878-44C0E778-00000001@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@aculab.com Website: http://www.aculab.com
mmm ... not sure, but i see u are trying to use sips: ... it is just a gut feeling, but i don't think ser/openser has full support of it ... and you probably just stumbled against a proof.
Cesc
On 7/25/06, Stephen Paterson Stephen.Paterson@aculab.com 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@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@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061 Call-ID: 42041801-00000878-44C0E778-00000001@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:
- Does anyone have any general thoughts as to what might be going wrong?
- 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@aculab.com Website: http://www.aculab.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Thanks Cesc, that would explain things. I'll ask the developers list about known issues in this area before I carry on. Regards Steve
-----Original Message----- From: Cesc [mailto:cesc.santa@gmail.com] Sent: 25 July 2006 12:23 To: Stephen Paterson Cc: users@openser.org Subject: Re: [Users] Error parsing URI's using TLS
mmm ... not sure, but i see u are trying to use sips: ... it is just a gut feeling, but i don't think ser/openser has full support of it ... and you probably just stumbled against a proof.
Cesc
On 7/25/06, Stephen Paterson Stephen.Paterson@aculab.com 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@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@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061 Call-ID: 42041801-00000878-44C0E778-00000001@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:
- Does anyone have any general thoughts as to what might be going wrong?
- 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@aculab.com Website: http://www.aculab.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061 Call-ID: 42041801-00000878-44C0E778-00000001@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:
- Does anyone have any general thoughts as to what might be going wrong?
- 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@aculab.com Website: http://www.aculab.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061 Call-ID: 42041801-00000878-44C0E778-00000001@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:
- 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@aculab.com Website: http://www.aculab.com _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@voice-system.ro] Sent: 25 July 2006 12:57 To: Klaus Darilion; Stephen Paterson Cc: users@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@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@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061 Call-ID: 42041801-00000878-44C0E778-00000001@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:
- 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@aculab.com Website: http://www.aculab.com _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
it should be xlog ... not log
cesc
On 7/25/06, Stephen Paterson Stephen.Paterson@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@voice-system.ro] Sent: 25 July 2006 12:57 To: Klaus Darilion; Stephen Paterson Cc: users@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@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@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061 Call-ID: 42041801-00000878-44C0E778-00000001@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:
- 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@aculab.com Website: http://www.aculab.com _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@voice-system.ro] Sent: 25 July 2006 12:57 To: Klaus Darilion; Stephen Paterson Cc: users@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@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@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061 Call-ID: 42041801-00000878-44C0E778-00000001@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:
- 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@aculab.com Website: http://www.aculab.com _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@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@openser.org [mailto:users-bounces@openser.org]On Behalf Of Daniel-Constantin Mierla Sent: 25 July 2006 13:24 To: Stephen Paterson Cc: users@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@voice-system.ro] Sent: 25 July 2006 12:57 To: Klaus Darilion; Stephen Paterson Cc: users@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@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@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061 Call-ID: 42041801-00000878-44C0E778-00000001@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:
- 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@aculab.com Website: http://www.aculab.com _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Actually ... it already struck me when you posted your message ...
INVITE sips:steve@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061 Call-ID: 42041801-00000878-44C0E778-00000001@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@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@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@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@openser.org [mailto:users-bounces@openser.org]On Behalf Of Daniel-Constantin Mierla Sent: 25 July 2006 13:24 To: Stephen Paterson Cc: users@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@voice-system.ro] Sent: 25 July 2006 12:57 To: Klaus Darilion; Stephen Paterson Cc: users@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@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@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061 Call-ID: 42041801-00000878-44C0E778-00000001@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:
- 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@aculab.com Website: http://www.aculab.com _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@blah) and call steve@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@gmail.com] Sent: 25 July 2006 13:59 To: Stephen Paterson Cc: daniel@voice-system.ro; users@openser.org Subject: Re: [Users] Error parsing URI's using TLS
Actually ... it already struck me when you posted your message ...
INVITE sips:steve@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061
Call-ID: 42041801-00000878-44C0E778-00000001@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@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@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@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@openser.org [mailto:users-bounces@openser.org]On Behalf Of Daniel-Constantin Mierla Sent: 25 July 2006 13:24 To: Stephen Paterson Cc: users@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@voice-system.ro] Sent: 25 July 2006 12:57 To: Klaus Darilion; Stephen Paterson Cc: users@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@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@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061 Call-ID: 42041801-00000878-44C0E778-00000001@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:
- 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@aculab.com Website: http://www.aculab.com _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@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@blah) and call steve@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@gmail.com] Sent: 25 July 2006 13:59 To: Stephen Paterson Cc: daniel@voice-system.ro; users@openser.org Subject: Re: [Users] Error parsing URI's using TLS
Actually ... it already struck me when you posted your message ...
INVITE sips:steve@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061
Call-ID: 42041801-00000878-44C0E778-00000001@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@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@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@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@openser.org [mailto:users-bounces@openser.org]On Behalf Of Daniel-Constantin Mierla Sent: 25 July 2006 13:24 To: Stephen Paterson Cc: users@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@voice-system.ro] Sent: 25 July 2006 12:57 To: Klaus Darilion; Stephen Paterson Cc: users@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@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@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061 Call-ID: 42041801-00000878-44C0E778-00000001@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:
- 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@aculab.com Website: http://www.aculab.com _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@openser.org [mailto:users-bounces@openser.org]On Behalf Of Cesc Sent: 25 July 2006 14:35 To: Stephen Paterson Cc: users@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@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@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@blah) and call steve@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@gmail.com] Sent: 25 July 2006 13:59 To: Stephen Paterson Cc: daniel@voice-system.ro; users@openser.org Subject: Re: [Users] Error parsing URI's using TLS
Actually ... it already struck me when you posted your message ...
INVITE sips:steve@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061
Call-ID: 42041801-00000878-44C0E778-00000001@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@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@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@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@openser.org [mailto:users-bounces@openser.org]On Behalf Of Daniel-Constantin Mierla Sent: 25 July 2006 13:24 To: Stephen Paterson Cc: users@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@voice-system.ro] Sent: 25 July 2006 12:57 To: Klaus Darilion; Stephen Paterson Cc: users@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@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@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061 Call-ID: 42041801-00000878-44C0E778-00000001@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:
- 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@aculab.com Website: http://www.aculab.com _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@openser.org [mailto:users-bounces@openser.org]On Behalf Of Cesc Sent: 25 July 2006 14:35 To: Stephen Paterson Cc: users@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@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@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@blah) and call steve@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@gmail.com] Sent: 25 July 2006 13:59 To: Stephen Paterson Cc: daniel@voice-system.ro; users@openser.org Subject: Re: [Users] Error parsing URI's using TLS
Actually ... it already struck me when you posted your message ...
INVITE sips:steve@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061
Call-ID: 42041801-00000878-44C0E778-00000001@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@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@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@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@openser.org [mailto:users-bounces@openser.org]On Behalf Of Daniel-Constantin Mierla Sent: 25 July 2006 13:24 To: Stephen Paterson Cc: users@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@voice-system.ro] Sent: 25 July 2006 12:57 To: Klaus Darilion; Stephen Paterson Cc: users@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@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@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061 Call-ID: 42041801-00000878-44C0E778-00000001@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:
- 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@aculab.com Website: http://www.aculab.com _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
message rejected because the thread was already too big....re-sending a short version...
2006/7/25, samuel samu60@gmail.com:
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.
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@openser.org [mailto:users-bounces@openser.org]On Behalf Of Cesc Sent: 25 July 2006 14:35 To: Stephen Paterson Cc: users@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@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@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@blah) and call steve@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@gmail.com] Sent: 25 July 2006 13:59 To: Stephen Paterson Cc: daniel@voice-system.ro; users@openser.org Subject: Re: [Users] Error parsing URI's using TLS
Actually ... it already struck me when you posted your message ...
INVITE sips:steve@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061
Call-ID: 42041801-00000878-44C0E778-00000001@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@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@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@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@openser.org [mailto:users-bounces@openser.org]On Behalf Of Daniel-Constantin Mierla Sent: 25 July 2006 13:24 To: Stephen Paterson Cc: users@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@voice-system.ro] Sent: 25 July 2006 12:57 To: Klaus Darilion; Stephen Paterson Cc: users@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@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@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061 Call-ID: 42041801-00000878-44C0E778-00000001@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:
- 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@aculab.com Website: http://www.aculab.com _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
On 7/25/06, Klaus Darilion klaus.mailinglists@pernau.at wrote:
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.
I agree with you ... but i don't think he had in mind a spiral ;) ... so, he's got a loop in his config file ...
Cesc
Hi all,
Sorry for the delay, I've been away for a bit. I stumbled across the source of the problem in a eureka moment though. It was the REGISTER that was the problem after all, I was a bit lazy setting that up. I was registering sip:blah@openser instead of sips:blah@openser so when I came to make a call to sips:blah@openser it all went wrong. Having fixed that, all is good in the world.
Thanks for all your help.
Steve
-----Original Message----- From: Cesc [mailto:cesc.santa@gmail.com] Sent: 25 July 2006 17:04 To: Klaus Darilion Cc: Stephen Paterson; users@openser.org Subject: Re: [Users] Error parsing URI's using TLS
On 7/25/06, Klaus Darilion klaus.mailinglists@pernau.at wrote:
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.
I agree with you ... but i don't think he had in mind a spiral ;) ... so, he's got a loop in his config file ...
Cesc
Hi Klaus,
We work with Snom and it is essentially the same INVITE, only the actual values of the URI's are different (and those tags & parameters that need to be unique). The really strange part for me is that the same URIs are present in the REGISTER which works fine. I'm aware that INVITEs and REGISTERs are likely to follow radically different code paths but I would have thought that the URI parser would be common to both.
I'll be trying eyebeam and minisip next but I wanted to get a proxy running so I could test outbound calls to Snom 360 (which will only accept incoming calls from a proxy, not direct from a UA).
Regards
Steve
-----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Sent: 25 July 2006 12:40 To: Stephen Paterson Cc: users@openser.org Subject: Re: [Users] Error parsing URI's using TLS
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@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@10.202.200.132 SIP/2.0 From: steve sips:steve@10.202.200.132;tag=ACU-6975-c47afeff To: steve sips:steve@10.202.200.132 Contact: sips:10.202.200.143:5061 Call-ID: 42041801-00000878-44C0E778-00000001@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:
- Does anyone have any general thoughts as to what might be going wrong?
- 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@aculab.com Website: http://www.aculab.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Stephen Paterson wrote:
Hi Ferianto,
As I see, the error is at line 27. I see that it contain "tls_verify=1" and "tls_require_certificate=0". I don't know what is wrong with this line because As I see from all mailinglist`s messages, they didn`t change this line and if they change it, they just change the value, for example : tls_verify = on tls_require_certificate = on
I've just started using OpenSER today as well and had the same problem. After a little guess work I got it to work using:
tls_verify_client, tls_verify_server & tls_require_client_certificate
instead of
tls_verify & tls_require_certificate
I couldn't find this documented anywhere but it may be, I don't know my way around the docs yet.
http://openser.org/docs/tls.html
regards klaus
-
Cesc -
Daniel-Constantin Mierla -
Klaus Darilion -
samuel -
Stephen Paterson