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.