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@pernau.at] Enviado el: martes, 21 de diciembre de 2010 10:47 Para: Dominguez Jover, Ricardo CC: sr-users@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...
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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users