[SR-Users] kamailio restart and TLS ( relay_to_tls() )

Dominguez Jover, Ricardo djover at umh.es
Tue Dec 21 18:46:56 CET 2010


Hi again Klaus,
 
I understand (now better) what you mean with timing parameters, I was just testing to close the first connection. The reason is because when I restart kamailio the clients I use reopen a second connection, as you said to me. So the solution to this issue could be not to open newer connection. I tested, as you said,  "set_forward_no_connect();" but may be not well enough. I imagine the solution goes by using it.
 
About the question on making TLS connection to the clients, I'm only relaying TLS connections to the gateway,  who has a certificate. I set TCP ASYNC=NO, because I had an error running TLS, as documentation says if I use TLS I have to disable asynch TCP.
 
I'm going to test in depth "set_forward_no_connect();" and feeback again.
 
Regards,
 
Ricardo Dominguez
 
 

________________________________

De: Klaus Darilion [mailto:klaus.mailinglists at pernau.at]
Enviado el: mar 21/12/2010 16:48
Para: Dominguez Jover, Ricardo
CC: sr-users at lists.sip-router.org
Asunto: Re: [SR-Users] kamailio restart and TLS ( relay_to_tls() )



Not sure what exactly happens in your scenario, but some generic tips:

- Regardless if the client is behind NAT or not, IMO the TCP connection
should be openend by the client and kept open for the whole lifetime of
the client. Thus, the TCP connection should not be closed, not by the
client and not by the proxy. Thus, set your TCP connection lifetime to a
value which is bigger the maximum registration expiration.

I also would enable keep-alive in the client.

Is there any specific reason why you close the TCP connection?

When using TLS there is one more problem: The party that receives the
TLS connection needs to present a certificate. This means, if the proxy
setups a TLS connection to the SIP client, the SIP client would need a
TLS client certificate.

Conclusion:
- the client should create a TCP/TLS connection and it should be kept
open for the whole lifetime.
- the proxy should use async mode (why don't you use it?)
- the proxy should not event try to make a TLS connection to the client
as the client probably can not provide TLS certificate

regards
klaus

Am 21.12.2010 14:13, schrieb Dominguez Jover, Ricardo:
> Klaus, it happens exactly what you said, duplicated TCP connection. Now I tell you about what I've found and timing variables. First to say there is no NAT in this scenario.
>
> About the timing variables there is a re-register time in the client (by default 3600s) and a "minimum time" (20s). Every time I restart Kamailio, after the minimum time the client re-opens a session. The client is not sending any SIP keepalive (I've switched it OFF), and in Kamailio "tcp_connection_lifetime=120", so after this time the first TCP connection is closed.
>
> But this happens only if I don't try to register again. If I do so, having the duplicated connection, then the first TCP connection only closes after the re-register timer finishes, and the second TCP connection closes every 120 seconds and then is re-opened after the 20s period.
>
> In my config TCP ASYNC is set to NO and set_forward_no_connect() doesn't seem to do anything since there is no NAT.
>
> I can reduce re-register time in the client side for a faster expiring time of the first TCP connection. But, how could I close the "corrupted" TCP connection from the server side? As I said since the second TCP connection is opened " tcp_connection_lifetime" doesn't affect the first one.
>
> Kind regards,
>
> Ricardo Dominguez
>
> -----Mensaje original-----
> De: Klaus Darilion [mailto:klaus.mailinglists at pernau.at]
> Enviado el: martes, 21 de diciembre de 2010 10:47
> Para: Dominguez Jover, Ricardo
> CC: sr-users at lists.sip-router.org
> Asunto: Re: [SR-Users] kamailio restart and TLS ( relay_to_tls() )
>
>
>
> Am 21.12.2010 08:30, schrieb Dominguez Jover, Ricardo:
>> Hi everybody,
>>
>> Since I implemented Kamailio 3.1 with TLS I've found a strange behavior.
>> That is, with some clients (Bria and Blink) registered, if I restart
>> Kamailio, then when the clients re-register the strange behaivour
>> happens. This behavior consist on receiving calls, it took about 15
>> seconds to receive the first tone since the call was made.
>
> This sounds like some timeout.
>
> Just think about what may happen: you restart Kamailio - thus the TCP
> connection is terminated and probably the client will create a new
> registration using a new TCP connection.
>
> As the old registration was not deREGISTERed, you will have 2 entries in
> your location table: one for the new registration (if the client already
> registered) and one for the old one (pointing to a non-existing TCP
> connection).
>
> No on incoming call, Kamailio will try to estblish a TCP connection to
> the old contact - which for sure will fail of the client is behind NAT
> or a firewall.
>
> There are several TCP parameters to tweak, e.g:
>
> make sure TCP is non-blocking:
> http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:3.1.x#tcp_async
>
> do not try to open TCP connections to SIP clients when they are known to
> be behind NAT/FW.
> http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:3.1.x#set_forward_no_connect
>
> There are also some more TCP functions which can be used to change the
> behavior, just look around set_forward_no_connect() function in core
> cookbook.
>
> regards
> klaus
>
> regards
> Klaus
>
>
>>
>> I made the following modification in the "route[Relay]" config. The
>> reason is I wanted my gateway and Kamailio to make signaling by TLS.
>> Without this modification the signaling was unencrypted (SIP):
>>
>> route[RELAY] {
>>
>> #!ifdef WITH_NAT
>>
>>           if (check_route_param("nat=yes")) {
>>
>>                   setbflag(FLB_NATB);
>>
>>           }
>>
>>           if (isflagset(FLT_NATS) || isbflagset(FLB_NATB)) {
>>
>>                   route(RTPPROXY);
>>
>>           }
>>
>> #!endif
>>
>>           /* example how to enable some additional event routes */
>>
>>           if (is_method("INVITE")) {
>>
>>                   #t_on_branch("BRANCH_ONE");
>>
>>                   t_on_reply("REPLY_ONE");
>>
>>                   t_on_failure("FAIL_ONE");
>>
>> }
>>
>> *# Se comunica con el GWa traves de TLS *
>>
>> ***if(!( ($od=~"mydomain.com")&&  ( ($rU=~"[a-z]{3,20}$") ||
>> ($rU=~"^xx[0-9][0-9]$") ) ) ) {    ### If I'm calling a PBX extension do
>> the signaling by TLS with the gateway (Cisco 2811)*
>>
>> **
>>
>> *                if (!t_relay_to_tls()) {*
>>
>> *                        sl_reply_error();*
>>
>> *                }*
>>
>>           } else if {
>>
>>                   if (!t_relay()) {
>>
>>                           sl_reply_error();
>>
>>                   }
>>
>>           }
>>
>>           exit;
>>
>> }
>>
>> The rest of functionalities are working really fine. Any idea about what
>> is happening?
>>
>> Cheers!
>>
>> *Ricardo Domínguez*
>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20101221/fdb8bdb3/attachment-0001.htm>


More information about the sr-users mailing list