[Asterisk-Users] using round-robin dns for sip registrations

[Greg Hill]

I finally decided to get a little source code dirt under my fingernails
tonight and dig through chan_sip.c to understand how registrations are
currently implemented. The hope is to perhaps at least seed some ideas
about how to make registrations to a server name, which resolves to
multiple IPs, either attempt each IP in the order they're returned by dns,
or, simply attempt to register with them all. This would be a good place
for somebody to chime in: which approach would be better? If the servers
communicate among themselves, a successful registration at one server
might cause another server to forget the registration previously made
there. In such a scenario, registering to all the servers would be a waste
of time. I'm leaning toward attempting to register with each server in
sequence until we are successful.

In reading chan_sip.c, I found the function sip_register(..) which reads
register=> lines from sip.conf and copies settings from there to a
sip_registry struct. The function does a gethostbyname() to look up the
hostname immediately. The IP returned, as well as the hostname, are stored
in the struct.

Later on, in transmit_register(..), is where the data stored in the
sip_registry struct gets pulled out and a registration attempt is made. It
looks like the function exits after transmitting the registration, and
some other function must get called to either 1: notice that the
registration was successful or 2: notice that it timed out. I haven't
found a function that does this yet.

Anyway, my proposed solution would be that when we handle a timed-out
registration, we should do another dns lookup on the hostname. The first
idea I hit was that if the IP that comes back differs from the one we
already had, then try re-registering at that IP. But with a round-robining
dns, we could possibly get the same IP back a second time. We'll probably
need to find all the IPs, ala dig, and keep them in a list so that we can
cycle through them.

But then there's the problem of when to flush the list and regenerate it
(so that we don't cache out-of-date IP numbers). I guess this could happen
everywhere that a gethostbyname() is now found..

Okay, it's late (here); I'll try to give this some more attention
tomorrow.

Greg