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.
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
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
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
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
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@pernau.at] Enviado el: mar 21/12/2010 16:48 Para: Dominguez Jover, Ricardo CC: sr-users@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@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
Am 21.12.2010 18:46, schrieb Dominguez Jover, Ricardo:
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.
The TCP connection should be kept alive as long as possible. If for some reason the TCP connection is lost (client crash, network failure, kamailio restart) there are two things the should be done: - the client has to create a new registration on a new TCP connection - the proxy should ignore contacts without existing TCP connections (thus use set_forward_no_connect())
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.
That was valid with 3.0 release. Since 3.1 release this is fixed and asynch mode can be used also with TLS.
regards Klaus
Klaus Darilion writes:
- the proxy should ignore contacts without existing TCP connections
(thus use set_forward_no_connect())
how about if the proxy also has tls connections to other proxies and gateways? is there possibility to just tell "do not try to set tcp connection to registered ua"?
-- juha
Am 21.12.2010 19:59, schrieb Juha Heinanen:
Klaus Darilion writes:
- the proxy should ignore contacts without existing TCP connections
(thus use set_forward_no_connect())
how about if the proxy also has tls connections to other proxies and gateways? is there possibility to just tell "do not try to set tcp connection to registered ua"?
usually you have control over it in you routing logic. For example routing to locally registered clients involve lookup(""). Thus, I put set_forward_no_connect() just below lookup("location").
Of course this won't work if you route to the other proxies also using lookup() with permanent entries in location table. If you really have such a setup you can try to set a certain flag for this entries and then do not call set_forward_no_connect().
regards klaus
TCP ASYNC=YES fixed the problem (set_forward_no_connect() didn´t.)
I don't know if you notice that "TCP ASYNC" in Core Cook Book v3.1 is not updated with this feature with TLS: http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:3.1.x#tcp_async
although in Kamailio 3.1 New Features DOC it is: http://www.kamailio.org/dokuwiki/doku.php/features:new-in-3.1.x#asynchronous...
Thanks a lot for your help.
Best regards,
Ricardo Domínguez
-----Mensaje original----- De: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Enviado el: martes, 21 de diciembre de 2010 20:03 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 18:46, schrieb Dominguez Jover, Ricardo:
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.
The TCP connection should be kept alive as long as possible. If for some reason the TCP connection is lost (client crash, network failure, kamailio restart) there are two things the should be done: - the client has to create a new registration on a new TCP connection - the proxy should ignore contacts without existing TCP connections (thus use set_forward_no_connect())
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.
That was valid with 3.0 release. Since 3.1 release this is fixed and asynch mode can be used also with TLS.
regards Klaus
Am 22.12.2010 08:58, schrieb Dominguez Jover, Ricardo:
TCP ASYNC=YES fixed the problem (set_forward_no_connect() didn´t.)
I don't know if you notice that "TCP ASYNC" in Core Cook Book v3.1 is not updated with this feature with TLS: http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:3.1.x#tcp_async
Fixed.
Thanks klaus
-
Dominguez Jover, Ricardo -
Juha Heinanen -
Klaus Darilion