[OpenSIPS-Users] Problem in sending outbound SIP messages via TLS

[Klaus Darilion]

Hi!

One point. It might work that in this scenario the SIP proxy can 
establish a TCP/TLS connection to the eyebeam client. Except if you have 
a setup were there is never a FW or NAT device between the client and 
the proxy, this will not work - FW/NAT will break TCP/TLS connection 
setup from proxy to the client.

Of course it would be interesting what cause your problem - but I would 
avoid it in first place by keep the TCP/TLS connection open. The 
connection will be established by the client during REGISTER and should 
be kept open. Thus, if like in your case the SIP proxy opens a new 
connection, this might have 2 reasons:

1. There is still a connection open but the sip proxy does not use it 
and opens a new one. This might happen if the address announced in the 
Contact header of the REGISTER does not match the source IP:port of the 
TCP/TLS connection. This can be fixed by applying NAT traversal: 
fix_nated_register() during REGISTER processing

2. The TCP connection is closed. I never have seen eyebeam/xlite closing 
the connection, thus I suspect that your proxy closes the connection. 
You can configure the timeout with the tcp_connection_lifetime - makes 
this bigger than the reregistration intervall should help. But, the more 
elegant solution is using to tcp_persistent_flag parameter of the 
registrar module (sets the lifetime to the expire value of the 
registration).


regards
klaus

Nachiket Tarate wrote:
> Hi Klaus,
> 
> Thanks for your reply!
> 
> If you move slightly upward in my log file, you will find following lines:
> 
> Aug 20 17:00:42 [22847] DBG:core:tcp_send: no open tcp connection found, 
> opening new one
> Aug 20 17:00:42 [22847] DBG:core:print_ip: tcpconn_new: new tcp 
> connection to: 172.25.0.113 <http://172.25.0.113>
> Aug 20 17:00:42 [22847] DBG:core:tcpconn_new: on port 28785, type 3
> Aug 20 17:00:42 [22847] DBG:core:tls_tcpconn_init: entered: Creating a 
> whole new ssl connection
> Aug 20 17:00:42 [22847] DBG:core:tls_tcpconn_init: name based TLS client 
> domains are disabled
> Aug 20 17:00:42 [22847] DBG:core:tls_tcpconn_init: no TLS client doman 
> AVP set, looking for socket based TLS client domain
> Aug 20 17:00:42 [22847] DBG:core:tls_find_client_domain: virtual TLS 
> client domain not found, Using default TLS client domain settings
> Aug 20 17:00:42 [22847] DBG:core:tls_tcpconn_init: found socket based 
> TLS client domain [0.0.0.0:0 <http://0.0.0.0:0>]
> Aug 20 17:00:42 [22847] DBG:core:tls_tcpconn_init: Setting in CONNECT 
> mode (client)
> Aug 20 17:00:42 [22847] DBG:core:tcp_send: sending...
> Aug 20 17:00:42 [22847] DBG:core:tls_update_fd: New fd is 25
> Aug 20 17:00:42 [22847] ERROR:core:tls_connect: something wrong in SSL:
> 
> This shows that there is not any existing TCP connection with eyeBeam 
> available and it is obvious as the "INVITE" message is outbound message.
> 
> OpenSIPs server successfully establishes TCP connection with eyeBeam but 
> the TLS handshake fails. So as suggested by you I need to go in more 
> dtails by using ssldump utility.
> 
> 
> Thanks agian,
> NT
> 
> 
> On Mon, Sep 1, 2008 at 8:06 PM, Klaus Darilion 
> <klaus.mailinglists at pernau.at <mailto:klaus.mailinglists at pernau.at>> wrote:
> 
>     Aug 20 17:00:42 [22847] DBG:core:tcp_send: sending...
>     Aug 20 17:00:42 [22847] DBG:core:tls_update_fd: New fd is 25
>     Aug 20 17:00:42 [22847] ERROR:core:tls_connect: something wrong in SSL:
>     Aug 20 17:00:42 [22847] DBG:core:tcp_send: after write: c=
>     0xb60f4d78 n=-1 fd=25
>     Aug 20 17:00:42 [22847] DBG:core:tcp_send: buf=
> 
>     Unfortunately the log file does not tell us what the problem was.
> 
>     Sniff the TLS connection to find out the problem:
>     1. Does openser establish TCP connection with eyebeam - usually
>     there should be an existing TCP/TLS connection - if this is not the
>     case you will problems anyway.)
> 
>     So watch out if there is existing TCP/TLS connection of if a new one
>     is setup
> 
>     If a new one is setup, take a look if the ssl ahdnshak is fine (e.g.
>     use ssldump utility)
> 
>     regards
>     klaus
> 
>     Nachiket Tarate schrieb:
> 
>         Hi,
> 
>         I am currently trying to make Secure RTP calls between my SIP
>         client and the eyeBeam. When eyeBeam is configured for encrypted
>         calls, it uses Secure RTP for media and TLS for SIP signalling.
> 
>         I have configured the OpenSIPs server with TLS support.
> 
>         The scenario is as shown below:
> 
> 
>          ----------------    UDP      ------------------    TLS  
>          -------------
>         |  My SIP Client |  <----->  |  OpenSIPs Server | <-----> |
>         eyeBeam 1.5 |
>          ----------------             ------------------          
>         -------------
>          Linux Machine                Linux Machine             Widows
>         XP machine
> 
>         When a call is made from eyeBeam to My SIP client the call gets
>         established properly and the OpenSIPs server acts as a gateway.
> 
>         But when a call is made from My SIP client to eyeBeam the
>         OpenSIPs returns the *477 Send failed* response to My SIP client.
> 
>         By enabling the debug informaiton on OpenSIPs server, I found
>         that it couldn't do TLS handshake with the eyeBeam and so
>         couldn't send the SIP Request from My SIP client to the eyeBeam.
> 
>         In brief the OpenSIPs server can accept the inbound messages via
>         TLS but *it can't send outbound messages via TLS*.
> 
>         Can anybody help me to resolve this problem? Please see my
>         opensips.cfg file and OpenSIPs server logs attached with this mail.
> 
>         Thanks,
>         NT
>          
> 
>         ------------------------------------------------------------------------
> 
>         _______________________________________________
>         Users mailing list
>         Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
>