devopsec left a comment (kamailio/kamailio#4500)
Hmmm, ds_xavp_dst works accessing it on failover but the other use case (the
one the ds_hres_t was created for) is accessing it on the first selected
destination, even when failover is not turned on.
Is there a better way to grab the original ds_dest_t selected in that case?
The example would be the 1st branch i linked above, showing the user the order
of destinations when using a specific algorithm with their current data, via an
rpc command.
I did not see another simple way to pull that selected hash up the call stack.
Here is an example (WIP) feature where I used the returned strcture:
https://github.com/kamailio/kamailio/compare/master...devopsec:kamailio:dispatcher_rpc_updates#diff-016b0bd9b0a333124f034e636fb1b8a75d8200bbac06149fcfeb8737c98f3f96R2668
I'll highlight that use case at a higher level for more context.
Lets say that I have a customer call in and say they were expected their
traffic to be distributed in a different manner than currently is (lets say
they have some indication they are not getting the level of service or features
they expect).
Lets say I have a NOC staffed with technicians that needs to review that
customers routing configuration or need to check if changing their routing
configuration (dispatcher data / algorithm) would/is giving them the intended
distribution.
They could test the proposed changes (or current route configuration) using the
rpc command in that branch I linked to check where the requests will be
distributed without needing to try replicating the live traffic that led to the
customer complaint.
The struct made that selected destination available, even when failover was not
enabled or the algorithm did not use failover.
I am of course willing to refactor to meet that requirement but I am unsure how
I could accomplish that use case without returning the dlist[] index selected
as well.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4500#issuecomment-3593167521
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4500/[email protected]>
_______________________________________________
Kamailio - Development Mailing List -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the
sender!
