21 Dec
2010
21 Dec
'10
8:30 a.m.
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
21 Dec
21 Dec
10:46 a.m.
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_n…
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2:13 p.m.
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(a)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_n…
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
4:48 p.m.
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(a)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_n…
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
6:46 p.m.
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(a)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(a)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_n…
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
8:03 p.m.
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
7:59 p.m.
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
8:34 p.m.
Am 21.12.2010 19:59, schrieb Juha Heinanen:
Klaus Darilion writes:
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
- 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"?
22 Dec
22 Dec
8:58 a.m.
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#asynchronou…
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(a)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
9:44 a.m.
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
5092
days inactive
5093
days old
9 comments
3 participants
participants (3)
-
Dominguez Jover, Ricardo -
Juha Heinanen -
Klaus Darilion