El Sábado, 26 de Septiembre de 2009, Daniel-Constantin Mierla escribió:
On 26.09.2009 21:48 Uhr, Iñaki Baz Castillo wrote:
El Sábado, 26 de Septiembre de 2009, Daniel-Constantin Mierla escribió:
it was about possibility to consider "register" as dialog and try to route next registrations without doing dns.
Ok. Then she would do better by doing fixed routing of REGISTER requests (based on From for example). She could use LCR module to add failover (if the "primary" Asterisk-registrar is down, next REGISTER's are routed to the "secondary" one.
the problem was that the registrars are owned by someone else. The routing is done by DNS and the owner of registrars does dns load balancing, so returns different ip for DNS queries. So, using hash table to cache the relation user-ip came as proposal later in the discussion.
Really an exotic scenario... why to use registration based on DNS if the DNS is "dynamic" (DNS load balancing)?
I understand that she has various Asterisk and a Kamailio doing dispatching for registrations, but she wants that an already registered user is routed to the same Asterisk-registrar for refresh registrations. Using DNS load balancing is a bad solution (IMHO).
A better approach (IMHO too) would be using the dispatcher module (based on From) to route the REGISTER without using DNS load balancing. This is, all the clients sends a REGISTER with RURI "sip:mydomain.org", Kamailio receives them and routes to some Asterisk after performing dispatching based on From URI.
In this way, all the registers from the same user would be routed to the same Asterisk. And also, using dispatcher module (or LCR) we also get failover (in the current solution, if an Asterisk crashes but the DNS returns its address, then the registration would fail).
Regards.