I'm trying to understand the scenario when `tcp_no_connect` should ever be set to `no`. Kamailio comes with `tcp_no_connect=no` by default which means it will try (and seemingly always fail) to create an outbound tcp connection when a UAC's tcp connection is lost. This in-turn could start building up the tcp write queue and can be disastrous at scale. So why would this setting (`tcp_no_connect=no`) ever be useful? Thanks
Hello,
do you have tcp_no_connect=no in your config? Because I think the default value is 0.
It is useful when you have client behind the nat that closed the connection, but the contact record is still valid in location table.
Cheers, Daniel
On 27.07.17 13:09, Vik Killa wrote:
I'm trying to understand the scenario when `tcp_no_connect` should ever be set to `no`. Kamailio comes with `tcp_no_connect=no` by default which means it will try (and seemingly always fail) to create an outbound tcp connection when a UAC's tcp connection is lost. This in-turn could start building up the tcp write queue and can be disastrous at scale. So why would this setting (`tcp_no_connect=no`) ever be useful? Thanks
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Ohh, misinterpreted tcp_no_connect=no is tcp_no_connect=0, which is the default.
My other remark related to user location was for the case of tcp_no_connect=yes, which I thought is what was meant initially.
Cheers, Daniel
On 27.07.17 13:30, Daniel-Constantin Mierla wrote:
Hello,
do you have tcp_no_connect=no in your config? Because I think the default value is 0.
It is useful when you have client behind the nat that closed the connection, but the contact record is still valid in location table.
Cheers, Daniel
On 27.07.17 13:09, Vik Killa wrote:
I'm trying to understand the scenario when `tcp_no_connect` should ever be set to `no`. Kamailio comes with `tcp_no_connect=no` by default which means it will try (and seemingly always fail) to create an outbound tcp connection when a UAC's tcp connection is lost. This in-turn could start building up the tcp write queue and can be disastrous at scale. So why would this setting (`tcp_no_connect=no`) ever be useful? Thanks
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - www.kamailioworld.com
does it make sense for Kamailio to create a connection if a client behind NAT has lost the connection? because It will almost always fail. It does make sense for IPv6 but not in IPv4 networks.
On Thu, Jul 27, 2017 at 7:37 AM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
Ohh, misinterpreted tcp_no_connect=no is tcp_no_connect=0, which is the default.
My other remark related to user location was for the case of tcp_no_connect=yes, which I thought is what was meant initially. Cheers, Daniel
On 27.07.17 13:30, Daniel-Constantin Mierla wrote:
Hello,
do you have tcp_no_connect=no in your config? Because I think the default value is 0.
It is useful when you have client behind the nat that closed the connection, but the contact record is still valid in location table.
Cheers, Daniel
On 27.07.17 13:09, Vik Killa wrote:
I'm trying to understand the scenario when `tcp_no_connect` should ever be set to `no`. Kamailio comes with `tcp_no_connect=no` by default which means it will try (and seemingly always fail) to create an outbound tcp connection when a UAC's tcp connection is lost. This in-turn could start building up the tcp write queue and can be disastrous at scale. So why would this setting (`tcp_no_connect=no`) ever be useful? Thanks
Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - www.kamailioworld.com
-- Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - www.kamailioworld.com
thinking more about this, the only time it makes sense (on an IPv4 network) is if kamailio is operating as a UAC (using uac module) Or am i misunderstanding something? my concern here is, it can be a dangerous setting when handling presence (over TCP) at large scale. for example if you have 10,000 subscribers and you restart kamailio (drop all the tcp connections), the tcp write queue will quickly fill up when your presence module tries sending out NOTIFYs to the UACs on broken tcp connections. when the tcp write queue fills up, it can create a huge bottleneck in kamailio and trigger more widespread issues across the system. I'm looking for clarification on why `tcp_no_connect=0` by default so i can at least update the doc/wiki on it (and the dangers of it in some setups) Thanks again!
On Thu, Jul 27, 2017 at 8:28 AM, Vik Killa vipkilla@gmail.com wrote:
does it make sense for Kamailio to create a connection if a client behind NAT has lost the connection? because It will almost always fail. It does make sense for IPv6 but not in IPv4 networks.
On Thu, Jul 27, 2017 at 7:37 AM, Daniel-Constantin Mierla < miconda@gmail.com> wrote:
Ohh, misinterpreted tcp_no_connect=no is tcp_no_connect=0, which is the default.
My other remark related to user location was for the case of tcp_no_connect=yes, which I thought is what was meant initially. Cheers, Daniel
On 27.07.17 13:30, Daniel-Constantin Mierla wrote:
Hello,
do you have tcp_no_connect=no in your config? Because I think the default value is 0.
It is useful when you have client behind the nat that closed the connection, but the contact record is still valid in location table.
Cheers, Daniel
On 27.07.17 13:09, Vik Killa wrote:
I'm trying to understand the scenario when `tcp_no_connect` should ever be set to `no`. Kamailio comes with `tcp_no_connect=no` by default which means it will try (and seemingly always fail) to create an outbound tcp connection when a UAC's tcp connection is lost. This in-turn could start building up the tcp write queue and can be disastrous at scale. So why would this setting (`tcp_no_connect=no`) ever be useful? Thanks
Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - www.kamailioworld.com
-- Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - www.kamailioworld.com
It is responsibility of SIP User Agent to keep connection open to its SIP Proxy (see outbound rfc). It thus does not make sense for SIP Proxy to try to open TCP or TLS connection to SIP UA.
I use set_forward_no_connect(); call for that purpose.
-- Juha
Hi,
On Thu, Jul 27, 2017 at 3:57 PM, Vik Killa vipkilla@gmail.com wrote:
thinking more about this, the only time it makes sense (on an IPv4 network) is if kamailio is operating as a UAC (using uac module) Or am i misunderstanding something?
There are many scenarios, where actively opening a TCP connection to a peer is desired. Carrier interconnects for example. Or TCP connections inside a (carrier) network. For those scenarios the default is suitable.
For a registrar dealing with client connections, you will probably want to turn creation of TCP sessions off.
Best Regards, Sebastian
Vik Killa writes:
I'm trying to understand the scenario when `tcp_no_connect` should ever be set to `no`. Kamailio comes with `tcp_no_connect=no` by default which means it will try (and seemingly always fail) to create an outbound tcp connection when a UAC's tcp connection is lost. This in-turn could start building up the tcp write queue and can be disastrous at scale. So why would this setting (`tcp_no_connect=no`) ever be useful?
For example, if K connects to another K over TCP and the connection does not exists, it makes sense to create one.
-- Juha