[SR-Users] Re: What is the expected behavior for dispatcher's ds_next_dst?

Hello Geoff, thanks for the debug output, it's as I suspected and also described earlier from Daniel. As already mentioned, the common way of working with dispatcher is to call the ds_select_dst() in the request route, and then in the failure route just iterate over this set of destinations. If you are interested in a more powerful way of doing this kind of failure routing, maybe one of the other routing modules (like carrierroute and others) offer something more suitable to your use-case. Arguable, the module could clear the content of the XAVP on a new invocation of the ds_select_dst() function. It would certainly helpful if its documented, you are right. I can have a look in the next days to it, if you have a good idea about an extension, just create a pull request of course. Cheers, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com<https://gilawa.com/> From: Geoff Goas &lt;Geoff.Goas(a)interoptechnologies.com&gt; Sent: Donnerstag, 28. September 2023 07:13 To: Henning Westerholt &lt;hw(a)gilawa.com&gt;om>; Kamailio (SER) - Users Mailing List &lt;sr-users(a)lists.kamailio.org&gt;rg>; Patrick Karton &lt;patrickarton(a)hotmail.com&gt; Subject: Re: [SR-Users] Re: What is the expected behavior for dispatcher's ds_next_dst? pv_xavp_print() has enlightened me to the fact that ds_select_dst() does not reset the dispatcher destination set XAVP. It only adds the selected destinations to the top of the XAVP stack. There are some ds_select_dst() calls for group 1 and group 2 earlier on in request_route, and those destinations remain in the XAVP stack even after selecting the destination set for group 3. To resolve, I added a loop to nullify the XAVP before the call to load the group 3 destination set: while ($xavp(_dsdst_) != null) { pv_unset($xavp(_dsdst_)); } I wonder, though - Is there a "dispatcher-native" way of clearing out the XAVP? And should I also clear out the XAVP holding the routing contexts "$xavp(_dsctx_)" ? If this is behaving as designed, then I think others might benefit from the documentation explaining how the destination set XAVP contents are managed by dispatcher, particularly how the XAVP is not cleared on subsequent ds_select_dst() calls. Thanks all! ________________________________ From: Geoff Goas <Geoff.Goas@interoptechnologies.com<mailto:Geoff.Goas@interoptechnologies.com>> Sent: Wednesday, September 27, 2023 14:19 To: Henning Westerholt <hw@gilawa.com<mailto:hw@gilawa.com>>; Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>; Patrick Karton <patrickarton@hotmail.com<mailto:patrickarton@hotmail.com>> Subject: Re: [SR-Users] Re: What is the expected behavior for dispatcher's ds_next_dst? Hi Henning, I used xavp_params_implode() and xlog() to log the contents of the XAVP You can see the contents of the XAVP in the previously provided log lines (showing the contents before and after the ds_next_dst() call): FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [grp=3;uri=sip:127.0.0.1:7012;transport=udp;] FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:7011;transport=udp] from [grp=3;uri=sip:127.0.0.1:7011;transport=udp;] FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [grp=3;uri=sip:127.0.0.1:7011;transport=udp;] FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:7010;transport=udp] from [grp=3;uri=sip:127.0.0.1:7010;transport=udp;] FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [grp=3;uri=sip:127.0.0.1:7010;transport=udp;] FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:5072;transport=udp] from [grp=2;uri=sip:127.0.0.1:5072;transport=udp;] FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [grp=2;uri=sip:127.0.0.1:5072;transport=udp;] FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:5072;transport=udp] from [grp=2;uri=sip:127.0.0.1:5072;transport=udp;] FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [grp=2;uri=sip:127.0.0.1:5072;transport=udp;] FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:5071;transport=udp] from [grp=1;uri=sip:127.0.0.1:5071;transport=udp;] Thanks, [cid:image001.png@01D9F1EF.51F308A0] GEOFF GOAS Manager Application Engineering T: +1 239-425-9132 (Florida) F: +1 239-425-6845 Skype: GeoffGoas Confidentiality Notice: The information in this e-mail and in any attachment may contain information which is legally privileged. It is intended only for the attention and use of the named recipient. If you are not the intended recipient, you are not authorized to retain, disclose, copy or distribute the message and/or any of its attachments. If you received this e-mail in error, please notify me and delete this message. ________________________________ From: Henning Westerholt <hw@gilawa.com<mailto:hw@gilawa.com>> Sent: Wednesday, September 27, 2023 13:51 To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>; Patrick Karton <patrickarton@hotmail.com<mailto:patrickarton@hotmail.com>> Cc: Geoff Goas <Geoff.Goas@interoptechnologies.com<mailto:Geoff.Goas@interoptechnologies.com>> Subject: RE: [SR-Users] Re: What is the expected behavior for dispatcher's ds_next_dst? Hello, have not checked the code, but the ds_next_dst() should just get the next destination from the configured XAVP. Have you tried to print it e.g. with pv_xavp_print() to see if there is maybe too much or wrong content inside? Cheers, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com<https://gilawa.com/> From: Geoff Goas via sr-users <sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Sent: Mittwoch, 27. September 2023 19:03 To: Patrick Karton <patrickarton@hotmail.com<mailto:patrickarton@hotmail.com>>; sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> Cc: Geoff Goas <Geoff.Goas@interoptechnologies.com<mailto:Geoff.Goas@interoptechnologies.com>> Subject: [SR-Users] Re: What is the expected behavior for dispatcher's ds_next_dst? Hi Patrick, That's exactly the workaround that I have in my back pocket - I tested it and it works well. I am still interested in getting some clarification, though. Thanks ________________________________ From: Patrick Karton <patrickarton@hotmail.com<mailto:patrickarton@hotmail.com>> Sent: Wednesday, September 27, 2023 12:37 To: sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> <sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Cc: Geoff Goas <Geoff.Goas@interoptechnologies.com<mailto:Geoff.Goas@interoptechnologies.com>> Subject: RE: [SR-Users] What is the expected behavior for dispatcher's ds_next_dst? Hi, before using t_relay you can probably check if next hop uri is still in the target group with ds_is_from_list([groupid [, mode [, uri] ] ]) for example ds_is_from_list("3","3","$du"); all parameters can be variables too. you can check on documentation the mode parameter to see how comparison is done. ________________________________ De : geoff.goas--- via sr-users <sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Envoyé : mardi 26 septembre 2023 21:02 À : sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> <sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Cc : geoff.goas@interoptechnologies.com<mailto:geoff.goas@interoptechnologies.com> <geoff.goas@interoptechnologies.com<mailto:geoff.goas@interoptechnologies.com>> Objet : [SR-Users] What is the expected behavior for dispatcher's ds_next_dst? Hello, I have some questions about dispatcher's behavior. I noticed that when I first ds_select_dst() a specific dispatcher group ID, ds_next_dst() will cycle through the active destinations in that group. When it reaches the end of the destinations in the group, it does not return "false", instead it starts to return destinations that are not a part of that group, ie. those destinations which are listed prior to the selected group in the dispatcher.list file. Is this the expected behavior? I've observed it on kamailio 5.3 and 5.5 releases. My dispatcher.list: # Group 1 1 sip:127.0.0.1:5071;transport=udp 8 0 # Group 2 2 sip:127.0.0.1:5072;transport=udp 8 0 # Group 3 3 sip:127.0.0.1:7010;transport=udp 8 0 3 sip:127.0.0.1:7011;transport=udp 8 0 3 sip:127.0.0.1:7012;transport=udp 8 0 # Group 4 4 sip:127.0.0.1:5071;transport=udp 8 0 4 sip:127.0.0.1:5072;transport=udp 8 0 I have the following in failure_route (excerpt): $var(dsFoundDestination) = 0; if (t_any_replied()) { xavp_params_implode("_dsdst_", "$var(dsDestinations)"); xlog("L_INFO", "FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [$var(dsDestinations)]"); if (ds_next_dst()) { xavp_params_implode("_dsdst_", "$var(dsDestinations)"); xlog("L_INFO", "FAILURE ROUTE: Next destination selected: [$du] from [$var(dsDestinations)]"); $var(dsFoundDestination) = 1; } } else if (ds_select_dst("3", "8")) // Dispatcher Group 3 { xlog("L_INFO", "FAILURE ROUTE: Did not find any replies on this transaction. Selected destination: [$du]"); $var(dsFoundDestination) = 1; } if ($var(dsFoundDestination)) { $var(logString) = "FAILURE ROUTE: Relayed to [" + $du + "]"; if (t_relay()) { xlog("L_INFO", "$var(logString)"); } } Produces the following logs: FAILURE ROUTE: Did not find any replies on this transaction. Selected destination: [sip:127.0.0.1:7012;transport=udp] FAILURE ROUTE: Relayed to [sip:127.0.0.1:7012;transport=udp] FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [grp=3;uri=sip:127.0.0.1:7012;transport=udp;] FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:7011;transport=udp] from [grp=3;uri=sip:127.0.0.1:7011;transport=udp;] FAILURE ROUTE: Relayed to [sip:127.0.0.1:7011;transport=udp] FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [grp=3;uri=sip:127.0.0.1:7011;transport=udp;] FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:7010;transport=udp] from [grp=3;uri=sip:127.0.0.1:7010;transport=udp;] FAILURE ROUTE: Relayed to [sip:127.0.0.1:7010;transport=udp] FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [grp=3;uri=sip:127.0.0.1:7010;transport=udp;] FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:5072;transport=udp] from [grp=2;uri=sip:127.0.0.1:5072;transport=udp;] FAILURE ROUTE: Relayed to [sip:127.0.0.1:5072;transport=udp] FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [grp=2;uri=sip:127.0.0.1:5072;transport=udp;] FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:5072;transport=udp] from [grp=2;uri=sip:127.0.0.1:5072;transport=udp;] FAILURE ROUTE: Relayed to [sip:127.0.0.1:5072;transport=udp] FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [grp=2;uri=sip:127.0.0.1:5072;transport=udp;] FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:5071;transport=udp] from [grp=1;uri=sip:127.0.0.1:5071;transport=udp;] FAILURE ROUTE: Relayed to [sip:127.0.0.1:5071;transport=udp] I want to stop the loop once there are no more active destinations in group 3. Is the solution simply to check that the selected destination is part of the desired group and stop processing if it is not? Thanks for your time. __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org<mailto:sr-users-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.