[Users] Error parsing URI's using TLS

[Stephen Paterson]

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 at pernau.at]
Sent: 25 July 2006 12:40
To: Stephen Paterson
Cc: users at 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 at openser.org'
> Subject: Error parsing URI's using TLS
> 
> 
> Hi all,
> 
> I've just started using OpenSER to test our SIP implementation and have encountered a problem with TLS early on. I can register with the server without any problem but my calls fail. The logging from the server shows:
> 
> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: tls_init: verify_callback: preverify is good: verify return: 1
> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: tls_init: verify_callback: depth = 0
> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: tls_init: verify_callback: preverify is good: verify return: 1
> Jul 21 15:40:54 sip-fedora3 ./openser[14881]: tls_init: verify_callback: depth = 1
> Jul 21 15:40:54 sip-fedora3 ./openser[14881]: tls_init: verify_callback: preverify is good: verify return: 1
> Jul 21 15:40:54 sip-fedora3 ./openser[14881]: tls_init: verify_callback: depth = 0
> Jul 21 15:40:54 sip-fedora3 ./openser[14881]: tls_init: verify_callback: preverify is good: verify return: 1
> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: ERROR: parse_uri: uri too short: <sip:> (4)
> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: ERROR: parse_sip_msg_uri: bad uri <sip:>
> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: loose_route: Error while parsing Request URI
> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: ERROR: parse_uri: uri too short: <sip:> (4)
> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: ERROR: parse_sip_msg_uri: bad uri <sip:>
> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: WARNING: do_action:error in expression
> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: ERROR: parse_uri: uri too short: <sip:> (4)
> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: ERROR: parse_sip_msg_uri: bad uri <sip:>
> Jul 21 15:40:54 sip-fedora3 ./openser[14880]: WARNING: do_action:error in expression
> 
> This would suggest that my (for example) From header contains a URI of: <sip:>! Not overly useful you might say. Now, the same INVITE without encryption works fine with OpenSER (using either TCP or UDP) and a serialisation of the INVITE immediately before encryption (shown below) shows the correct URIs in all the right places.
> 
> INVITE sips:steve at 10.202.200.132 SIP/2.0
> From: steve <sips:steve at 10.202.200.132>;tag=ACU-6975-c47afeff
> To: steve <sips:steve at 10.202.200.132>
> Contact: <sips:10.202.200.143:5061>
> Call-ID: 42041801-00000878-44C0E778-00000001 at 192.168.6.91
> CSeq: 26984 INVITE
> Content-Length: 281
> Content-Type: application/sdp
> Allow: INVITE
> Allow: ACK
> Allow: BYE
> Allow: CANCEL
> Allow: OPTIONS
> Allow: NOTIFY
> Allow: REFER
> Allow: PRACK
> Allow: INFO
> Allow: UPDATE
> Accept: application/sdp
> Accept: application/isup
> Accept: application/qsig
> Accept: multipart/mixed
> Accept-Encoding: identity
> Accept-Language: en
> Supported: replaces
> Supported: 100rel
> Via: SIP/2.0/TLS 10.202.200.143:5061;branch=z9hG4bKeb10b5f6-18c6-11db-bff7-971e76d819bf
> Max-Forwards: 70
> Route: <sips:10.202.200.132:5061;lr>
> 
> ... SDP omitted
> 
> For the moment I am pretty much assuming that this is a problem with our implementation as it is still under development but I can't work out what. 
> 2 questions:
> 
> 1. Does anyone have any general thoughts as to what might be going wrong?
> 2. Is it possible to get more logging from OpenSER that might shed some light?
> 
> Regards
> 
> Steve
> 
> Steve Paterson
> Software Engineer
> Aculab
> Tel: +44 (0) 1908 273866
> Fax: +44 (0) 1908 273801
> Email: mailto:stephen.paterson at aculab.com
> Website: http://www.aculab.com  
> 
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users