[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 at gmail.com>:

> Wouldn’t dispatching based on user hash solve all these problems?
>
> On Fri, 10 Sep 2021 at 17:32, Тимур Ситдиков <sitdikovt at 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 at 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 at 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 at 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
> email: david.villasmil.work at gmail.com
> phone: +34669448337
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20210911/84553b17/attachment.htm>