<div dir="ltr"><div dir="ltr">On Sun, Oct 30, 2022 at 6:19 AM Kevin Kennedy <<a href="mailto:kennedy4260@gmail.com">kennedy4260@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">I have set the ds_select_dst used in the mid_registrar part of the script to hash the To URI<div><br></div><div>$ru = (ds_select_dst(1, <b>2</b>, , "default", 1));</div><div><br></div><div>but I am not seeing exactly how to do this for the INVITE. If I use ds_select_dst for the INVITE, it just chooses a random destination, not performing a match on the Registration destination.</div><div><br></div></div></div></blockquote><div><br></div><div>You cannot use ds_select to send INVITE to where the REGISTER was<br>You can make the kv-store visible to MI, and then ul_dump the AOR complete of kv-store</div><div><br></div><div>Also, you can simply write in a memory hash or in a db table to which destination was the REGISTER going</div><div><br></div><div>btw, I believe this architecture is fragile, you don't want INVITEs going to a destination related to the one REGISTER was, a lot of bad things can happen if you have such constraints. <br>If you really really really want that, then just go for sharding based on domains or on users ranges, with some fallback schema</div><div><br></div><div>-giovanni</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature">Sincerely,<br><br>Giovanni Maruzzelli<br>OpenTelecom.IT<br>cell: +39 347 266 56 18<br><br></div></div>