The id and description columns are complementary in the database, they must not be loaded in the memory. The id is auto-increment and present in many tables only for provisioning purposes outside of kamailio usage and definitely not for dispatcher needs. Some database backends such as mongodb or berkleydb don't have id column, or it is a string.

I am also not convinced this addition brings any benefits. It is a lot of code for just a little purpose. If you want the status of a destination address, then you can add a functions specific for that - a function that takes an IP address as parameter and sets the value of the state in a variable.

The patch here clones the all dispatcher destinations structure, with all attributes, in xavps.

Moreover, there is an option right now to get all the destinations and their state in a json, via jsnorpcs:

* https://www.kamailio.org/docs/modules/stable/modules/jsonrpcs.html#jsonrpcs....

The you can use jansson module to access the attributes or the state field for destinations.

Ultimately, if you really need this cloning in xavps, maybe it is time to add a new module in top of dispatcher, with dispatcher exposing some inter-module api to access its structure. Otherwise I really want to keep dispatcher as lightweight as possible, its purpose is to be very slim/fast/scalable to fit well also in embedded devices .

@miconda the intent is to periodically publish an amqp payload from a timer route with information taken from dispatcher. the id and description were added so we would not query the database for each destination when creating the payload. since xavp is created on demand from `ds_list` i don't see why not, on the other hand, i do understand your point of view about embedded devices. thanks for your time reviewing this, closing this pr.

@miconda it was just to get the reflection of what's in the database with runtime information. i check jsonrpcs and it will have to work for now. thanks