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, view it on GitHub, or unsubscribe.