Hi Daniel, I've actually been spending a lot of time with the dispatcher readme to try to figure this out. If there are restrictions in usage as you indicate, then it is not documented. From the dispatcher readme: ds_next_dst Takes the next destination address from the corresponding XAVPs and sets the dst_uri (outbound proxy address). This function can be used from REQUEST_ROUTE, FAILURE_ROUTE. ds_select_dst If the bit 2 in 'flags' parameter is set, the rest of the addresses from the destination set are stored in XAVP list (limited with an optional 'limit' parameter). You can use 'ds_next_dst()' to use next address in order to achieve serial forking to all possible destinations. This function can be used from REQUEST_ROUTE, FAILURE_ROUTE. My issue is that I want to select from a new group of destinations only when a particular failure status has been received, so I can't simply only call ds_next_dst() in failure_route. Anyways, the problem is not in the initial group selection, but rather in the subsequent calls to ds_next_dst(). I changed the logic to how you recommended, with ds_select_dst() being called only in request_route, and ds_next_dst() only called by failure_route. The problem is exactly the same: ds_next_dst() starts selecting destinations that are not in the group that was initially selected with ds_select_dst(). You can see it happening here: dispatcher [dispatch.c:2097]: ds_manage_routes(): set [2] dispatcher [dispatch.c:2213]: ds_manage_routes(): using alg [8] hash [0] dispatcher [dispatch.c:2260]: ds_manage_routes(): selected [8-2-0/0] <sip:127.0.0.1:5072;transport=udp> dispatcher [dispatch.c:2281]: ds_manage_routes(): using first entry [2/0] dispatcher [dispatch.c:2057]: ds_select_dst_limit(): selected target destinations: 1 <script>: REQUEST ROUTE: Relayed to [sip:127.0.0.1:5072;transport=udp] via forced socket [udp:127.0.0.1:5074] <script>: FAILURE ROUTE: 400 Bad Request, trying next available gateway... <script>: FAILURE ROUTE: Selecting next destination from: [grp=2;uri=sip:127.0.0.1:5072;transport=udp;] dispatcher [dispatch.c:2357]: ds_update_dst(): updating dst dispatcher [dispatch.c:2373]: ds_update_dst(): updating dst with next record dispatcher [dispatch.c:2403]: ds_update_dst(): using next dst uri [sip:127.0.0.1:5072;transport=udp] <script>: 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;] <script>: FAILURE ROUTE: 400 Bad Request, trying next available gateway... <script>: FAILURE ROUTE: Selecting next destination from: [grp=2;uri=sip:127.0.0.1:5072;transport=udp;] dispatcher [dispatch.c:2357]: ds_update_dst(): updating dst dispatcher [dispatch.c:2373]: ds_update_dst(): updating dst with next record dispatcher [dispatch.c:2403]: ds_update_dst(): using next dst uri [sip:127.0.0.1:5071;transport=udp] <script>: 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;] It happens in this order: 1. Request_route ds_select_dst() selects group=2 destination=sip:127.0.0.1:5072;transport=udp 2. Failure_route ds_next_dst() selects group=2 destination=sip:127.0.0.1:5072;transport=udp (again?) 3. Failure_route ds_next_dst() selects group=1 destination=sip:127.0.0.1:5071;transport=udp I don't understand what I'm doing incorrectly for it to select a destination from group 1. One thing that is standing out to me is the log line showing "ds_select_dst_limit(): selected target destinations: 1" when ds_select_dst() is called. Based on the readme for ds_select_dst(), all addresses from the group are stored in the XAVP if bit 2 of the 'flags' parameter is set (which it is) unless otherwise limited by the 'limit' parameter (it is not). However, when I print out the XAVP with xavp_params_implode, the XAVP only ever contains a single destination. Thanks, ________________________________ From: Daniel-Constantin Mierla &lt;miconda(a)gmail.com&gt; Sent: Wednesday, September 27, 2023 01:58 To: Kamailio (SER) - Users Mailing List &lt;sr-users(a)lists.kamailio.org&gt; Cc: Geoff Goas &lt;Geoff.Goas(a)interoptechnologies.com&gt; Subject: Re: [SR-Users] What is the expected behavior for dispatcher's ds_next_dst? Hello, normally ds_select_dst() should be used inside request_route and ds_next_dst() in the failure_route. As you do the former also in the failure_route, you keep selecting the destination from the group and add them to the list of possible next hops. Look at the readme of dispatcher module, it has a complete sample config how to use the two functions. Cheers, Daniel On 26.09.23 22:02, geoff.goas--- via sr-users wrote: -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy - Training Services -- asipto.com Kamailio World Conference - kamailioworld.com 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.

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 &lt;patrickarton(a)hotmail.com&gt; Sent: Wednesday, September 27, 2023 12:37 To: sr-users(a)lists.kamailio.org &lt;sr-users(a)lists.kamailio.org&gt; Cc: Geoff Goas &lt;Geoff.Goas(a)interoptechnologies.com&gt; 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 &lt;sr-users(a)lists.kamailio.org&gt; Envoyé : mardi 26 septembre 2023 21:02 À : sr-users(a)lists.kamailio.org &lt;sr-users(a)lists.kamailio.org&gt; Cc : geoff.goas(a)interoptechnologies.com &lt;geoff.goas(a)interoptechnologies.com&gt; 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(a)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.

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:62e08ed3-e3cd-43ae-8893-dbd99ef3587b] GEOFF GOAS Manager Application Engineering T: +1 239-425-9132 (Florida) F: +1 239-425-6845 Skype: GeoffGoas<skype:GeoffGoas?add> 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 &lt;hw(a)gilawa.com&gt; Sent: Wednesday, September 27, 2023 13:51 To: Kamailio (SER) - Users Mailing List &lt;sr-users(a)lists.kamailio.org&gt;rg>; Patrick Karton &lt;patrickarton(a)hotmail.com&gt; Cc: Geoff Goas &lt;Geoff.Goas(a)interoptechnologies.com&gt; 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 &lt;sr-users(a)lists.kamailio.org&gt; Sent: Mittwoch, 27. September 2023 19:03 To: Patrick Karton &lt;patrickarton(a)hotmail.com&gt;om>; sr-users(a)lists.kamailio.org Cc: Geoff Goas &lt;Geoff.Goas(a)interoptechnologies.com&gt; 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.

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.