Daniel-Constantin Mierla schrieb:

Hello,

On 08/28/08 04:37, toly wrote:

...

Greetings,

What would be value of children parameter for few thousands user?

depends also on the number of calls. You should be safe with 16. Beware that the number are per IP address per transport protocol.

/*klaus is nitpicking*/ with children you set the number of processes per UDP listening socket with tcp_children you set the number of processes for TCP/TLS handling

e.g. listen=udp:1.2.3.4:5060 listen=udp:1.2.3.4:5070 listen=udp:5.6.7.8:5060

listen=tcp:1.2.3.4:5060 listen=tcp:1.2.3.4:5070 listen=tcp:5.6.7.8:5060 listen=tls:1.2.3.4:5061 listen=tls:1.2.3.4:5071 listen=tls:5.6.7.8:5061

children=10 tcp_children = 10

==> 3x10 + 10 = 40 worker processes

easy to analyze using "kamctl ps"

regards klaus

toly wrote:

Thank you guys for clearing it out.

On the tcp transport question: When softphone registers, does openser opens blocking connection and keeps it up to the duration of the registration? If so would proxy run out of the connections pretty soon?

Kamailio keeps up TCP conenctions until either: - the client closes it (a client behind NAT/FW should never close the TCP connection) - the TCP connection times out. Therefore are two parameters to configure this behavior:

- the default timeout is configured with tcp_connection_lifetime http://www.kamailio.net/dokuwiki/doku.php/core-cookbook:1.4.x#tcp_connection...

- tcp_persistent_flag of registrar modul http://www.kamailio.net/docs/modules/1.4.x/registrar.html#id2453000

Kamailio opens the TCP socket "blocking". This means the writing into to socket blocks until the data is successfully sent or an error happens. In times were no data is sent via TCP, the processes are of course free to do other things. Thus, you can handle hundreds of TCP clients with 1 tcp children. But if one of the clients died, and Kamailio tries to send to this client, then thc TCP process is waiting for the tcp_send_timeout. If that happens, and there are no other TCP processes left, then Kamailio itself blocks completely. (if the message was received via UDP and then forwarded via TCP and this TCP connection fails, then the corresponding UDP process which handled the message blocks).

regards klaus