[SR-Users] Kamailio failover - dialog (transaction) that is available on different proxies

Sebastian Damm damm at sipgate.de
Mon Aug 28 10:50:39 CEST 2017


Hi,

I think your setup might not work as you think it should. See my
comments inline.

On Sun, Aug 27, 2017 at 11:37 AM, Donat Zenichev
<donat.zenichev at gmail.com> wrote:
> According to my actual question, I've moved further and now think following
> scheme will work fine:
> 1. NAPTR records for every transport protocol (e.g. "
> _sip._udp.domain.org").

Did you mean SRV records? UACs query for SRV records, not NAPTR (as
far as I know).

> 2. SRV records for every NAPTR record (e.g. kamailio1.domain.org,
> kamailio2.domain.org) with same priority/weight for both of them, to balance
> half invites to first one and half invites to second one.

That's part of the SRV lookup in step 1.

> 3. A records for every domain name (e.g. kamailio1.domain.org - 10.0.0.1,
> 10.0.0.2, where actually second one is kamailio2;
> and the same for fqdn kamailio2.domain.org - 10.0.0.2, 10.0.0.1).

Typically DNS servers shuffle the results for a host. This means you
will probably get 10.0.0.2 as the primary IP for your Kamailio1 for
half of the queries. This might not be a problem, but you I don't know
a way of setting up a primary/secondary setup with two A records.

> So the sequence of dialog actions will be
>
> 1. Invite from uac is balanced to kamailio1;
> 2. Dialog is established and media stream is up;

While there is a DB mode parameter for the dialog module, from
documentation I expect the dialog entries only to be written to
database when set to mode 1. I think Kamailio actually operates with
what's in memory. So you can probably write the information to a
shared database, but Kamailio2 will know nothing about the data
written by Kamailio1 (unless Kamailio2 is restarted).

> 3. Then kamailio1 goes down;
> 4. Bye message tries to achieve host that was set in rr hf (kamailio1), but
> kamailio1 (10.0.0.1) is down, so bye message will be sent to 10.0.0.2
> (kamailio2) and a cause of the behaviour is 10.0.0.2 ip assigned to
> kamailio1 fqdn as second ip.

How should the "down" get detected by the UAC? I would expect the UAC
to just retransmit the BYE 6 times and then time out.

> 5. The message will be processed by kamailio2, because of common
> dialog/usrloc db.

My guess would be that neither one of your assumptions will happen.

Best Regards,
Sebastian

P.S.:
> I will make an effort to set up it next week.
> In case of success, I will write a short report here.

Of course, if I'm totally wrong, I'd be happy to hear that, too.



More information about the sr-users mailing list