> But the issue with TCP is the same. On failover/restart (or completly
> down in your case), the TCP session is lost, and non recoverable
> assuming NAT. AFAIK there is no solution.
It's a pitty, my robust mind tells me, that there is no way to solve
it clearly, without stupid "crutches".
But I
On Thu, Sep 07, 2017 at 01:05:02PM +0300, Donat Zenichev wrote:
> > Having a similar setup with failover for the loadbalancers, I take for
> > granted that TCP/TLS will fail in case of a failover (but UDP will keep
> > working after failover due to the stateless nature of it).
>
> Well, your routi
> Having a similar setup with failover for the loadbalancers, I take for
> granted that TCP/TLS will fail in case of a failover (but UDP will keep
> working after failover due to the stateless nature of it).
Well, your routing servers use PJSIP for NAPTR resolving?
If so, how have you made it work
On Thu, Sep 07, 2017 at 11:03:49AM +0300, Donat Zenichev wrote:
[snip]
> ERROR: [tcp_main.c:4070]: handle_tcpconn_ev(): connect
> XXX.XXX.XXX.XXX:52185 failed
>
> The port that kamailio2 tries to use to relay the ACK, is port that
> endpoint used to establish the dialog with kamailio1 and actuall
Hi.
Recently I've come across with TCP connection problem.
The topology is as following:
DNS srv load balancer - two kamailio proxy servers - one routing server.
Client appeals to NAPTR record like: sip.domain.com
So dns returns one of the proxy servers to client (depending on
weight/priority).
