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(a)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(a)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(a)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
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users