<div dir="ltr"><div>Hi Klaus,</div>
<div> </div>
<div>In my setup, there is not any FW or NAT device between the eyeBeam and the proxy.</div>
<div> </div>
<div>The source IP:port of the TCP/TLS connection for which OpenSIPs does a search before establishing new connection is same as in the Contact header of the eyeBeamREGISTER .</div>
<div> </div>
<div>Also I tried with setting the tcp_persistent_flag parameter of the registrar module:</div>
<div> </div>
<div> modparam("registrar", "tcp_persistent_flag", 7)</div>
<div> </div>
<div>But this didn't work. </div>
<div> </div>
<div>So I guess the eyeBeam is closing the connection.</div>
<div> </div>
<div>Anyway thanks for your help!<br> </div>
<div>Regards,</div>
<div>NT</div>
<div><br> </div>
<div class="gmail_quote">On Wed, Sep 3, 2008 at 12:42 AM, Klaus Darilion <span dir="ltr"><<a href="mailto:klaus.mailinglists@pernau.at">klaus.mailinglists@pernau.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi!<br><br>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.<br>
<br>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:<br>
<br>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<br>
<br>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).<br>
<br><br>regards<br>klaus<br><br>Nachiket Tarate wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="Ih2E3d">Hi Klaus,<br><br>Thanks for your reply!<br><br>If you move slightly upward in my log file, you will find following lines:<br><br>Aug 20 17:00:42 [22847] DBG:core:tcp_send: no open tcp connection found, opening new one<br>
</div>Aug 20 17:00:42 [22847] DBG:core:print_ip: tcpconn_new: new tcp connection to: <a href="http://172.25.0.113/" target="_blank">172.25.0.113</a> <<a href="http://172.25.0.113/" target="_blank">http://172.25.0.113</a>>
<div class="Ih2E3d"><br>Aug 20 17:00:42 [22847] DBG:core:tcpconn_new: on port 28785, type 3<br>Aug 20 17:00:42 [22847] DBG:core:tls_tcpconn_init: entered: Creating a whole new ssl connection<br>Aug 20 17:00:42 [22847] DBG:core:tls_tcpconn_init: name based TLS client domains are disabled<br>
Aug 20 17:00:42 [22847] DBG:core:tls_tcpconn_init: no TLS client doman AVP set, looking for socket based TLS client domain<br>Aug 20 17:00:42 [22847] DBG:core:tls_find_client_domain: virtual TLS client domain not found, Using default TLS client domain settings<br>
</div>Aug 20 17:00:42 [22847] DBG:core:tls_tcpconn_init: found socket based TLS client domain [<a href="http://0.0.0.0:0/" target="_blank">0.0.0.0:0</a> <<a href="http://0.0.0.0:0/" target="_blank">http://0.0.0.0:0</a>>]
<div class="Ih2E3d"><br>Aug 20 17:00:42 [22847] DBG:core:tls_tcpconn_init: Setting in CONNECT mode (client)<br>Aug 20 17:00:42 [22847] DBG:core:tcp_send: sending...<br>Aug 20 17:00:42 [22847] DBG:core:tls_update_fd: New fd is 25<br>
Aug 20 17:00:42 [22847] ERROR:core:tls_connect: something wrong in SSL:<br><br>This shows that there is not any existing TCP connection with eyeBeam available and it is obvious as the "INVITE" message is outbound message.<br>
<br>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.<br><br><br>Thanks agian,<br>NT<br><br><br>
</div>
<div>
<div></div>
<div class="Wj3C7c">On Mon, Sep 1, 2008 at 8:06 PM, Klaus Darilion <<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a> <mailto:<a href="mailto:klaus.mailinglists@pernau.at" target="_blank">klaus.mailinglists@pernau.at</a>>> wrote:<br>
<br> Aug 20 17:00:42 [22847] DBG:core:tcp_send: sending...<br> Aug 20 17:00:42 [22847] DBG:core:tls_update_fd: New fd is 25<br> Aug 20 17:00:42 [22847] ERROR:core:tls_connect: something wrong in SSL:<br> Aug 20 17:00:42 [22847] DBG:core:tcp_send: after write: c=<br>
0xb60f4d78 n=-1 fd=25<br> Aug 20 17:00:42 [22847] DBG:core:tcp_send: buf=<br><br> Unfortunately the log file does not tell us what the problem was.<br><br> Sniff the TLS connection to find out the problem:<br> 1. Does openser establish TCP connection with eyebeam - usually<br>
there should be an existing TCP/TLS connection - if this is not the<br> case you will problems anyway.)<br><br> So watch out if there is existing TCP/TLS connection of if a new one<br> is setup<br><br> If a new one is setup, take a look if the ssl ahdnshak is fine (e.g.<br>
use ssldump utility)<br><br> regards<br> klaus<br><br> Nachiket Tarate schrieb:<br><br> Hi,<br><br> I am currently trying to make Secure RTP calls between my SIP<br> client and the eyeBeam. When eyeBeam is configured for encrypted<br>
calls, it uses Secure RTP for media and TLS for SIP signalling.<br><br> I have configured the OpenSIPs server with TLS support.<br><br> The scenario is as shown below:<br><br><br> ---------------- UDP ------------------ TLS -------------<br>
| My SIP Client | <-----> | OpenSIPs Server | <-----> |<br> eyeBeam 1.5 |<br> ---------------- ------------------ -------------<br> Linux Machine Linux Machine Widows<br>
XP machine<br><br> When a call is made from eyeBeam to My SIP client the call gets<br> established properly and the OpenSIPs server acts as a gateway.<br><br> But when a call is made from My SIP client to eyeBeam the<br>
OpenSIPs returns the *477 Send failed* response to My SIP client.<br><br> By enabling the debug informaiton on OpenSIPs server, I found<br> that it couldn't do TLS handshake with the eyeBeam and so<br>
couldn't send the SIP Request from My SIP client to the eyeBeam.<br><br> In brief the OpenSIPs server can accept the inbound messages via<br> TLS but *it can't send outbound messages via TLS*.<br>
<br> Can anybody help me to resolve this problem? Please see my<br> opensips.cfg file and OpenSIPs server logs attached with this mail.<br><br> Thanks,<br> NT<br> <br> ------------------------------------------------------------------------<br>
<br> _______________________________________________<br> Users mailing list<br></div></div> <a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a> <mailto:<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>>
<div class="Ih2E3d"><br> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br><br><br></div></blockquote><br></blockquote>
</div><br></div>