It is admirable that you are convinced it is a faulty implementation nobody observed since
August 2004 when the module was added and the hashing over call-id was implemented, so you
are going to fix it now for everyone.
Well, actually that is the wanted behaviour of the respective hashing algorithms, to go to
next one if the selected destination is unavailable. It may not meet your expectation,
therefore you can add a new hashing algorithm, as I proposed. Otherwise, your fix is
breaking existing deployments for others. It is one of the benefits of open source to be
able to accommodate most of the needs of its contributors.
Normally, a gateway/destination server should be down temporarily, otherwise it should be
removed from the list if is shut down for maintenance. Also, you should do dispatching of
the initial requests stateless and rely on record-routing for requests within dialog.
Because if you have destination servers going up and down during a call, then you do not
ensure BYE is going to same server as the INVITE, if the number if active servers is
different.
Regarding the order of the addresses in the list, to ensure the one you want, you have to
set the priority field. While with a text file you can have an order in the file, with
database is harder to predict the order of records in a select query without an explicit
order-by.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2363#issuecomment-648947440