[SR-Users] tcpconn_main_timeout

[Daniel Tryba]

On Mon, Mar 19, 2018 at 04:23:01PM +0100, Kjeld Flarup wrote:
> Interesting
> 
> Just to be sure that I understand You correctly.
> When a Register is done, then an Invite, must create a new TCP connection.

That is not what I tried to say. All I wanted to say was:

uac ipA:portX -> syn     -> server ipB:5060
uac ipA:portX <- syn-ack <- server ipB:5060
uac ipA:portX -> ack     -> server ipB:5060
uac ipA:portX     <->       server ipB:5060

Whether the uac is behind NAT or not, it is impossible to recreate the
connection between ipA:portX and ipB:5060 if there is ever a network
interruption.

Atleast that used to be true before SO_REUSEPORT support in kernels so
maybe the uac may be capable to reconnect with the same port, but it is
definitly impossible for the server to do this since there is simply no
listener to connect to.
 
> I agree, that a perfect implementetion would be to keep the TCP stream up
> while the client is connected, and use that connection for all
> communication between the two stacks.
> 
> How about reregisters can they reuse the connection? Or should the
> connection be closed once the packet is consumed?

This is all up to the endpoint, but having a DNS based loadbalancing
setup (SRV records, round robin A records) may have an influence.

Most clients I have seen sofar will simply reuse an existing TCP
connection for both INVITEs and re-REGISTERs. Clients with decend
NAPTR/SRV implementation will probably query DNS and iterate over the
available servers (with hopefuly 1 per server).

Kamailio will just reuse an existing connection as far as I have seen.