Hello,

 

dispatcher algorithms can’t be combined like this, you need to pick one in the command.

 

Cheers,

 


Henning

 

--

Henning Westerholt – https://skalatan.de/blog/

Kamailio services – https://gilawa.com

 

From: sr-users <sr-users-bounces@lists.kamailio.org> On Behalf Of ????? ????????
Sent: Saturday, September 11, 2021 6:29 AM
To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org>
Subject: Re: [SR-Users] Kamailio dispatcher -> FreeSWITCH transfers handling.

 

I'm using round-robin for now. Will try hash on URIs and come back. Thanks, David!
One question - algorithms can be bitwise combined (like in nat_uac_test)? Or need to do separate ds test for from-URI and R-URI?

Thank you!
Regards, Tim

 

сб, 11 сент. 2021 г. в 03:16, David Villasmil <david.villasmil.work@gmail.com>:

Wouldn’t dispatching based on user hash solve all these problems? 

 

On Fri, 10 Sep 2021 at 17:32, Тимур Ситдиков <sitdikovt@gmail.com> wrote:

Thanks Fred!
The dialog module is really helpful.
Got rid of that ugly "BYE" construction.
Also no need to write a special ht entry for blind transfer.

For now I'm saving to htable on event_route(dialog:start), and removing on 'end' or 'failure' event.
Much cleaner :-D Thanks a lot for the tip.

For "Htable key identify" problem:
I've managed to find corresponding keys with 'sht_iterator' in while loop. Matches found with ($(shtitkey(i1){s.select,-1,:} == $rU || $fU). Key values =  $shtitval(i1).
Not the most elegant solution, imo, but best I can do for now :-D

Haven't got hands on the problem with attended transfer yet. But it's already clear that I've got a huge lack of SIP knowledge.
Can't get how custom headers with original call-id and from/to tags can help me with this.

Would be very grateful for clarify, if it's possible :-D
For now my best idea is to catch indialog 'REFER' with 'Replaces' in 'Refer-to' and write to htable according to its contents (eg, set $fU from RURI and $rU from 'Refer-to').

 

 Anyway, Thanks a lot for your help!   

 

Regards, Tim

 

чт, 9 сент. 2021 г. в 20:05, Fred Posner <fred@palner.com>:

There's a lot to go through on this example... and many ways to handle
such scenarios.

Personally, I very much like the HTABLE approach for "remembering"
destinations. Instead of using a BYE to remove the entries, you might
see if using DIALOG for this use case to be beneficial (removing the
HTABLE entry when all calls are ended).

Depending on how the endpoints are linking attended transfers, you may
need to consider adding SIP headers (like X-ORIG-CI) to add a call-id,
from tag, or other info to identify original calls.

Again, many different ways that you could approach this, but sounds like
you're on the right track for sure.

Fred Posner | palner.com
Matrix: @fred:matrix.lod.com
o: +1 (212) 937-7844

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

--

Regards,

 

David Villasmil

phone: +34669448337

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users